Verwalten eines Buildalias und dessen Zuordnung

Ein Buildalias ist eine Verwaltungsebene über Builds, mit der Aufrufe RequestMultiplayerServer kontrolliert auf mehrere Builds verteilt werden können. Dies kann die Einfachheit und Zuverlässigkeit von Build-to-Build-Upgrades und mehreren anderen unten aufgeführten Szenarien verbessern. Aliase erreichen dies, indem sie eine Liste von Build-IDs zusammen mit der Gewichtung der einzelnen Aliase angeben. Die Gewichtung eines Builds legt fest, wie wahrscheinlich es ist, dass dieser Build für jede Zuordnungsanforderung zuerst ausprobiert wird. Wenn z. B. Build 1 eine Gewichtung von 8 und Build 2 eine Gewichtung von 2 hat, wird Build 1 zuerst für etwa 80 % der Anforderungen versucht, sodass es etwa 80 % davon bedient, während es über StandingBy-Server verfügt. Wenn Build 1 keine StandingBy-Server in einer Region mehr haben, werden diese Anforderungen stattdessen an Build 2 weitergeleitet, sodass Build 2 mehr als 20 % der Anforderungen in dieser Region verarbeiten kann. Die Regionen in jeder Anforderung stehen jedoch an erster Stelle, und die Gewichtungen entscheiden nur, welcher Build eine Anforderung innerhalb einer Region bedient. Weitere Informationen finden Sie unter Fallback auf andere Builds und Regionen.

Sichere Bereitstellung, die abwärtskompatibel ist

Dies ist das gängigste Szenario für ein Build-to-Build-Upgrade, bei dem Sie den Spielserver aktualisieren und Einzelhandelsclients mit beiden Servern kompatibel sind.

Clients verweisen auf Alias 1, der die folgende Konfiguration hätte:

  • Build 1: Gewichtung = 1

Sobald Build 2 erstellt wurde, wird Alias 1 geändert in:

  • Build 1: Gewicht = 8
  • Build 2: Gewichtung = 2

Sie können die Gewichtungen schrittweise ändern, bis alle neuen Serveranforderungen von Build 2 erfüllt sind. An diesem Punkt ist die Gewichtung für Build 1 0 und kann aus dem Alias entfernt werden.

Ein typischer Anwendungsfall für einen Alias ist die Zuordnung zu einer Clientkompatibilitätsversion und einem Spielmodus. Zum Beispiel: "DeathMatch-Client 2.2 RETAIL." Aliase ermöglichen es Ihnen, diese übergeordnete Abstraktion zu verwalten und gleichzeitig die Builds, die diese Erfahrung unterstützen, kontinuierlich zu aktualisieren. Aliase erleichtern Ihnen auch das Rollback von Builds bei Bedarf.

Nicht abwärtskompatible Bereitstellung

In diesem Fall möchten Sie den Spielserver gleichzeitig mit der Aktualisierung von Spielclients aktualisieren, da Ihre aktuellen Spielclients nicht mit dem alten Serverbuild kompatibel sind. Der Übergang von einem Build zu einem anderen würde wie folgt erfolgen:

Alte Clients verweisen auf Alias 1. Dies würde Folgendes beinhalten:

  • Build 1: Gewichtung = 1

Sobald Build 2 erstellt wurde, verweisen neue Clients auf Alias 2, was Folgendes aufweisen würde:

  • Build 2: Gewichtung = 1

In diesem Szenario werden Aliase ähnlich wie Builds verwendet, und ihre Multiplexingfunktionen werden nicht verwendet.

Abwärtskompatible Blast-Bereitstellung

Dies ähnelt dem abwärtskompatiblen Build-to-Build-Upgradeszenario, jedoch mit einem plötzlicheren Wechsel des Nachfrageverhaltens. Der Übergang von einem Build zu einem anderen würde wie folgt erfolgen:

Clients verweisen auf Alias 1. Dies würde Folgendes beinhalten:

  • Build 1: Gewichtung = 1

Sobald Build 2 erstellt wurde, wird Alias 1 geändert in:

  • Build 1: Gewichtung = 0
  • Build 2: Gewichtung = 1

Testen einer abwärtskompatiblen Bereitstellung

Wenn Sie den Spielserver aktualisieren möchten und die Clientversion mit beiden Servern kompatibel ist, Sie aber die zweite Version testen möchten, bevor Sie sie im großen Maßstab für alle Spieler bereitstellen. Das Testen und Wechseln von einem Build zu einem anderen kann wie folgt erfolgen:

Clients verweisen auf Alias 1. Dies würde Folgendes beinhalten:

  • Build 1: Gewichtung = 1

Nachdem Build 2 erstellt wurde. Testclients würden auf Alias 2 verweisen, was Folgendes enthalten würde:

  • Build 2: Gewichtung = 1

Nachdem Build 2 überprüft wurde. Alias 1 wird geändert in:

  • Build 1: Gewicht = 8
  • Build 2: Gewichtung = 2

Allmählich würde Build 2 stärker gewichtet werden und den gesamten Verkehr absorbieren.

Fallback auf andere Builds und Regionen

Aliase können Ihre Multiplayer-Serverbereitstellungen widerstandsfähiger machen, indem sie Fallbacks über mehrere Builds hinweg ermöglichen. Wenn du einen Server von einem Alias anforderst, liste alle Regionen, die deinen Spielern ein akzeptables Erlebnis bieten, in PreferredRegionsder Reihenfolge ihrer Präferenz auf. PlayFab Multiplayer Servers (MPS) behandelt jede Anforderung wie folgt:

  1. MPS verwendet die Buildgewichtungen, um die Builds des Alias für die Anforderung in eine Reihenfolge zu bringen. Ein Build mit einer höheren Gewichtung steht mit größerer Wahrscheinlichkeit an erster Stelle.
  2. MPS durchläuft Ihre Regionen in der Reihenfolge, in der Sie sie aufgelistet haben. In jeder Region werden alle Builds in dieser Reihenfolge getestet. Es überspringt Builds, die nicht in der Region bereitgestellt werden.
  3. MPS weist einen Server aus dem ersten Build zu, der über einen StandingBy-Server verfügt. Wenn in der Region kein Build vorhanden ist, wechselt MPS zur nächsten Region. Wenn keine Region über eine Region verfügt, schlägt die Anforderung mit dem Fehler MultiplayerServerTooManyRequests fehl.

Die Reihenfolge der Regionen kommt immer vor den Buildgewichtungen. Die Spieler erhalten einen Server in der bevorzugten Region, die über Kapazität verfügt, und die Gewichtung entscheidet nur, welcher Build ihnen in dieser Region dient. Verwenden Sie die Gewichtungen, um Ihre Kosten- und Leistungspräferenzen zwischen Builds auszudrücken, z. B. zwischen VM-Größen. Das Hinzufügen von Builds, die mehr Regionen abdecken, zu einem Alias kann nur die Kapazität erhöhen.

Ein Build mit einer Gewichtung von 0 wird nie für Zuordnungen verwendet, auch nicht als Fallback. Um einen Build als Fallback beizubehalten, geben Sie ihm stattdessen eine kleine Gewichtung ungleich null, z. B. 1 gegenüber 999 für Ihren Hauptbuild.

Wenn keiner der Builds des Alias in einer der angeforderten Regionen bereitgestellt wird, schlägt die Anforderung mit dem MultiplayerServerNotFound Fehler fehl. Möglichkeiten zum Vermeiden beider Fehler finden Sie unter "Bewährte Methoden und Startcheckliste".

Nehmen wir beispielsweise an, eine Zuordnungsanforderung, die auf einen Buildalias abzielt, stuft "USA, Osten" als Region #1 und USA, Westen, als Region #2 ein. Dieser Buildalias bietet ähnliche Gewichtungen wie zwei Builds, Build 1 und Build 2.

Angenommen, Build 1 steht in der Reihenfolge für eine gegebene Zuordnung an erster Stelle.

  1. Es wird versucht, die Zuordnung in USA, Osten für Build 1 vorzunehmen.
  2. Wenn #1 fehlschlägt, wird versucht, die Zuordnung in "USA, Osten" für Build 2 vorzunehmen.
  3. Wenn #2 fehlschlägt, wird versucht, Build 1 in USA, Westen, zuzuordnen.
  4. Wenn #3 fehlschlägt, wird versucht, die Zuordnung in WestUs für Build 2 vorzunehmen.

Insbesondere wenn Sie schrittweise von einem Build auf einen anderen upgraden, wird dieses Fallbackverhalten optimiert, sodass Spieler den Server mit der niedrigsten Latenz erhalten, selbst wenn bei einem der Builds Probleme auftreten.

Verwalten eines Buildalias mit PlayFab-REST-APIs

Notiz

Sie können jetzt Build-Aliase in Game Manager verwalten. Informationen zu den ersten Schritten finden Sie auf der Seite "Builds-Übersicht"

  1. Erstellen Sie einen Buildalias mithilfe der API.

    API:

    POST https://titleId.playfabapi.com/MultiplayerServer/CreateBuildAlias

    Beispieltext:

    {
    "AliasName":"TestingAlias",
    "BuildSelectionCriteria":
    [{
        "BuildWeightDistribution":{"9a8a4584-c81a-479c-9ef9-16d3743f7ca7":"1"}
    }]
}

    Beispielantwort:

    {
    "AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6",
    "AliasName":"TestingAlias",
    "BuildSelectionCriteria":
    [{
        "BuildWeightDistribution":{"9a8a4584-c81a-479c-9ef9-16d3743f7ca7":"1"}
    }]
}

    Die Buildalias-ID wird als Teil der Antwort bereitgestellt.

  2. Aktualisieren Sie einen beliebigen Parameter des Buildalias.

    API:

    POST https://titleId.playfabapi.com/MultiplayerServer/UpdateBuildAlias

    Beispieltext:

    {
    "AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6",
    "AliasName":"TestingAliasRenamed",
    "BuildSelectionCriteria":
    [{
        "BuildWeightDistribution":{"9a8a4584-c81a-479c-9ef9-16d3743f7ca7":"1",
        "7ac7f347-3d61-9fe9-c974-a18c4854a8a9":"1"}
    }]
}

    Beispielantwort:

    {
    "AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6",
    "AliasName":"TestingAliasRenamed",
    "BuildSelectionCriteria":
    [{
        "BuildWeightDistribution":{"9a8a4584-c81a-479c-9ef9-16d3743f7ca7":"1",
        "7ac7f347-3d61-9fe9-c974-a18c4854a8a9":"1"}
    }]
}

  3. Löschen Sie einen Buildalias.

    API:

    POST https://titleId.playfabapi.com/MultiplayerServer/DeleteBuildAlias

    Beispieltext:

    {
    "AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6"
}

  4. Listen Sie Buildaliase auf.

    API:

    GET https://titleId.playfabapi.com/MultiplayerServer/ListBuildAliases

    Beispielantwort:

    [{
    "AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6",
    "AliasName":"TestingAliasRenamed",
    "BuildSelectionCriteria":
    [{
        "BuildWeightDistribution":{"9a8a4584-c81a-479c-9ef9-16d3743f7ca7":"1",
        "7ac7f347-3d61-9fe9-c974-a18c4854a8a9":"1"}
    }]
}]

Zuordnen mithilfe eines Buildalias

Für die Zuweisung mit einem Buildalias muss man einfach die Buildalias-ID im RequestMultiplayerServer Aufruf angeben.

API:

POST https://titleId.playfabapi.com/MultiplayerServer/RequestMultiplayerServer

Beispieltext:

{
    "SessionId":"6a07440c-7bcc-4e23-8b81-4934543ff966",
    "PreferredRegions":["SouthCentralUs"],
    "BuildAliasParams":
        {"AliasId":"97d2b0a5-7c04-4593-8451-66bbb97f94b6"}
}
  • Zuletzt aktualisiert um