本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 無伺服器型遊戲後端架構
<a name="serverless-based-game-backend-architecture"></a>

 許多遊戲開發人員不想管理基礎設施，而是偏好使用允許他們專注於軟體的技術來建置遊戲。在此案例中，建議使用無伺服器架構，因為它可讓您更快速地建置和發行功能，並降低營運開銷。無伺服器架構的設計使用雲端服務，可根據需求動態擴展，而不需要設定、管理和擴展伺服器。下列參考架構說明如何使用無伺服器架構建置遊戲。

![無伺服器型遊戲後端參考架構](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/games-industry-lens/images/image5.png)


 此參考架構說明提供單一玩家和多玩家功能的 Web 型三角遊戲。
+  **玩家身分**驗證：玩家使用 Amazon Cognito 進行身分驗證，其提供安全身分驗證與玩家身分管理的使用者目錄。
+  **遊戲邏輯作為無伺服器函數**：遊戲功能和後端商業邏輯作為回應事件而啟動的 AWS Lambda 函數執行，這會降低成本，因為您只在函數執行時付費。Lambda 可讓您靈活地使用您選擇的程式設計語言，將每個遊戲功能寫入為單獨的微服務。例如，如果您有使用 C\# 建置 Unity 遊戲的經驗，您可以選擇開發 .NET Lambda 函數，或者如果您想要在 JavaScript 中編寫 Web 遊戲的前端和後端程式，可以選擇開發 Node.js Lambda 函數。
+  **遊戲和玩家資料的 NoSQL Data Store：**使用 DynamoDB 來存放您的玩家和遊戲資料，因為它專為從微服務存放大量資料而打造。如此架構所示，最佳實務是針對每個遊戲功能的資料儲存需求使用個別的資料儲存，這可讓您直接獨立監控和管理功能。如果團隊中的功能或服務擁有權發生變更，這也會建立分離界限。在此參考架構中，DynamoDB 資料表用於存放連線狀態、遊戲詳細資訊、玩家進度和排行榜資訊等資料。
+  **單一玩家遊戲：**單一玩家功能可讓玩家執行動作，例如選取和玩遊戲，以及檢視排行榜。這些功能會實作為使用 Amazon API Gateway HTTP API 託管的 RESTful 後端服務，該 API 會叫用適當的 Lambda 函數，以取得和設定 DynamoDB 資料表中的資料。遊戲完成時，後端也會將通知傳送至 Amazon SNS 主題，以非同步方式啟動 Lambda 函數來儲存玩家的進度和統計資料。
+  **多玩家遊戲：**多玩家遊戲功能需要玩家能夠與遊戲互動以進行point-to-point通訊，以及廣播和接收來自其他連線玩家的更新。WebSockets 實作適用於輕量型遊戲中的point-to-point通訊，例如 trivia。玩家可以建立與 Amazon API Gateway WebSockets 的 WebSockets 連線，以管理連線，並只在有要為玩家傳送或接收的訊息時叫用 Lambda 函數。 WebSockets 對於玩家之間需要one-to-many通訊的使用案例， AWS IoT Core 支援透過 MQTT 使用 WebSockets 傳送訊息，這允許用戶端訂閱主題並對收到的訊息採取行動。在此架構中，透過 MQTT 的 WebSockets用於支援使用案例，例如廣播即時遊戲內更新，以及向連線的玩家提出問題。或者 AWS IoT，如果您需要訊息保留，您可以選擇 Redis Pub/Sub 進行訊息傳遞，或選擇 Redis Streams。
+  **使用啟用 VPC 的 Lambda 函數來存取私有子網路中的資源：**設定啟用 VPC 的 Lambda 函數來存取 VPC 私有子網路中的資源，例如 Amazon ElastiCache，用於縮短即時排行榜等低延遲資料集的查詢時間。

 如需詳細資訊，請參閱 [上的自訂遊戲後端託管指南 AWS](https://aws.amazon.com/solutions/guidance/custom-game-backend-hosting-on-aws/)。