Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Sitzungsbasiertes Gameserver-Hosting mit serverlosem Backend
<a name="session-based-game-server-hosting-with-serverless-backend"></a>

 Berücksichtigen Sie bei der Entwicklung einer Architektur für Ihr Spiel die Funktionen und Fähigkeiten, die Sie benötigen, und den Umfang des betrieblichen Verwaltungsaufwands, den Sie bereit sind, zu übernehmen. Um das beste Gleichgewicht zwischen einfacher Bedienung und Flexibilität zu erreichen, können Sie Ihr Spiel mithilfe von Managed Services von Cloud-Anbietern entwickeln. Mit Managed Services haben Sie die Kontrolle über die Entwicklung und Anpassung Ihrer eigenen Spielfunktionen und reduzieren gleichzeitig Ihren Aufwand für die Bereitstellung und Verwaltung der Infrastruktur. 

 Das Hosten eines sitzungsbasierten Multiplayer-Spiels erfordert eine Serverinfrastruktur zum Hosten der Spielserverprozesse sowie ein skalierbares Backend für Spielersuche und Sitzungsmanagement. Die folgende Referenzarchitektur zeigt, wie Amazon GameLift Managed Hosting und ein serverloses Backend zur Verwaltung Ihrer sitzungsbasierten Spiele verwendet werden können. 

![Amazon GameLift verwaltetes Hosting für sitzungsbasierte Spiele](http://docs.aws.amazon.com/de_de/wellarchitected/latest/games-industry-lens/images/image2.png)


 Das Diagramm beschreibt den Prozess, Spieler für Spiele zu gewinnen, die auf GameLift verwaltetem Spiele-Hosting laufen. Es umfasst die folgenden Schritte: 

1.  Der Spielclient fordert eine Amazon Cognito Cognito-Identität aus einem Amazon Cognito Cognito-Identitätspool an. Dieser kann optional mit externen Identitätsanbietern verbunden werden. 

1.  Der Spielclient erhält temporäre Zugangsdaten und fordert eine Spielsitzung über ein Amazon API Gateway an, indem er die Anfrage mit den Amazon Cognito Cognito-Anmeldeinformationen signiert. 

1.  API Gateway ruft eine AWS Lambda Funktion auf. 

1.  Die Lambda-Funktion fordert Spielerdaten aus einer Amazon DynamoDB-Tabelle an. Die Amazon Cognito Cognito-Identität wird verwendet, um sicher die richtigen Spielerdaten anzufordern, da die authentifizierte Identität in den Anforderungskontextdaten bereitgestellt wird. 

1.  Die Lambda-Funktion verwendet die richtigen Spielerdaten für zusätzliche Informationen (wie den Skill-Level des Spielers) und fordert über GameLift FlexMatch Matchmaking ein Match an. Sie können eine FlexMatch Matchmaking-Konfiguration mit JSON-basierten Konfigurationsdokumenten definieren. Der Spielclient kann Latenzmetriken generieren, indem er Serverendpunkte in verschiedenen Regionen anpingt, und die Latenzdaten können verwendet werden, um latenzbasiertes Matchmaking zu unterstützen. 

1.  Nach FlexMatch Matches mit einer geeigneten Gruppe von Spielern mit geeigneter Latenz in einer Region wird über eine Warteschlange eine Platzierung für eine Spielsitzung angefordert. GameLift Die Warteschlange enthält Flotten mit einem oder mehreren registrierten Standorten in der Region. 

1.  Wenn die Sitzung an einem der Standorte der Flotte stattfindet, wird eine Ereignisbenachrichtigung an ein Amazon SNS SNS-Thema gesendet. 

1.  Eine Lambda-Funktion empfängt das Amazon SNS SNS-Ereignis und verarbeitet es. 

1.  Wenn es sich bei der Amazon SNS-Nachricht um ein MatchmakingSucceeded Ereignis handelt, schreibt die Lambda-Funktion das Ergebnis mit dem Server-Port und der IP-Adresse in DynamoDB. Ein time-to-live (TTL) -Wert wird verwendet, um sicherzustellen, dass Matchmaking-Tickets aus DynamoDB gelöscht werden, wenn sie nicht mehr benötigt werden. 

1.  Der Spielclient sendet eine signierte Anfrage an API Gateway, um den Status des Matchmaking-Tickets in einem bestimmten Intervall zu überprüfen. 

1.  API Gateway ruft eine Lambda-Funktion auf, die den Status des Matchmaking-Tickets überprüft. 

1.  Die Lambda-Funktion überprüft DynamoDB, um festzustellen, ob das Ticket erfolgreich war. Wenn dies erfolgreich war, sendet die Lambda-Funktion die IP-Adresse, den Port und die Player-Sitzungs-ID zurück an den Client. Wenn das Ticket fehlgeschlagen ist, sendet die Lambda-Funktion eine Antwort, in der erklärt wird, dass das Spiel nicht bereit ist. 

1.  Der Spielclient stellt über TCP oder UDP eine Verbindung zum Spieleserver her, indem er den Port und die IP-Adresse verwendet, die vom Backend bereitgestellt werden. Es sendet die Spielersitzungs-ID an den Spieleserver, und der Spieleserver validiert sie mithilfe des Amazon GameLift Server SDK. 

 Alternativ können Sie die vorherige Architektur ändern, um API Gateway WebSockets mit Amazon zu verwenden GameLift. Bei diesem Ansatz erfolgt die Kommunikation zwischen dem Spielclient und Ihrem Spiel-Backend-Service mithilfe einer [WebSocketbasierten Implementierung](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift_quickstart_customservers_designbackend_arch_websockets.html). Diese Implementierung kann verwendet werden, sodass die Lambda-Funktion des Spiele-Backends eine serverseitige Nachricht an den Spielclient über ein initiiert, WebSocket anstatt ein Abfragemodell zu implementieren.