以App Engine為基礎的遊戲伺服器架構

該解決方案在Google Cloud Platform上提供了高度可擴展和可靠的遊戲實施，該平台使用Google App Engine和Google Compute Engine進行即時線上玩家的互動。 該解決方案通過使用 App Engine並通過使用 Compute Engine來運行遊戲伺服器和一般的遊戲引擎，為玩家配對和玩家定制提供核心遊戲元素。

此解決方案涉及的要點包括：
• 擴大服務數百萬的玩家。
• 使用GCP構建功能齊全的遊戲體驗。
• 利用App Engine進行前端互動，並在數據存儲區(datastore)中維護遊戲狀態。
• 使用App Engine來管理(orchestrating)和自動縮放(auto-scaling)由Compute Engine所建造的遊戲伺服器。
• 通過分析包含用戶和遊戲統計資訊的大量數據集(datasets)，獲得業務洞察。

*本文翻譯自 “Game Server Reference Architecture with App Engine and Compute Engine” 一文，內容仍以原文為準*

**文末還有Github範例可以下載**

隨著玩遊戲的人數不斷增加，您需要為強大的遊戲體驗所需的計算資源量可能會增長很多。 線上遊戲已經從只有少數人在其車庫中運行到成百上千萬玩家享受網路的遊戲體驗、玩家配對、遊戲內購買和好友清單。 這些常見的遊戲元件(game components)已經導致開發複雜的分佈式系統、高性能的計算和大規模網絡實作。 在競爭激烈的環境下，開發和提供下一個重量級遊戲需要仔細管理您的資源，專注於關鍵的遊戲成份上。

配置雲端資源或忽略一些複雜的處理會大幅減少人力和支出，而專注於遊戲或圖像資源。 通過使用Google Cloud Platform，您可以專注於創造獨特的遊戲體驗，同時充分利用Google在開發分佈式系統方面的豐富經驗。

該解決方案利用App Engine的可擴展性和可靠性，使運行在Compute Engine遊戲伺服器上的玩家可以順利進行匹配，並建立一段遊戲會話(game sessions)。 App Engine是一個可擴展的平台(PaaS)提供例如使用者檔案、玩家配對、遊戲內購買、遊戲社群和手機端的互動。 理想情況下，App Engine滿足所有在線遊戲的需求，但您可能希望能進入VM中來運作一些常見的遊戲引擎和 SDK。 這時候就需要Compute Engine。儘管許多方面都可以用於純粹的App Engine實現，但主要的重點還是在Compute Engine上運行專用的遊戲伺服器。

此解決方案中使用的服務包括：
• Google App Engine
      • 提供主要的圖像化用戶界面來提供遊戲和使用設定(user settings)。
      • 提供玩家配對和伺服器瀏覽。
      • 將負載分配至各台Compute Engine。
      • 維持提供集群(cluster)來處理玩家的遊戲負載。
• Google Compute Engine
      • 運行客製化(customized)遊戲伺服器。
• Google BigQuery
      • 分析大量的遊戲和用戶數據集。
• Google Cloud Storage
      • 儲存遊戲伺服器二進位檔案文件。
      • 分配遊戲客戶端二進位資料和遊戲虛擬財產。
      • 儲存備份日誌以處理並加載到BigQuery中。

解決方案概述

參考架構圖，如圖1所示，提供了Compute Engine和App Engine如何建立可擴展和可靠的在線遊戲解決方案。

線上遊戲解決方案的關鍵架構元件

用戶通過下載本地應用程式或導航到遊戲的網站，開始玩最喜歡的遊戲。 如果是他們第一次玩，所有客戶端二進位檔案文件和遊戲虛擬財產都可以從雲端存儲下載。 雖然遊戲客戶端在行動設備和個人電腦各有不同，但仍然都會提供核心的遊戲功能。 核心功能包括更新用戶個人資料、管理玩家config和檢查朋友的成就。App Engine可以通過直接提供網站或提供RESTful API來存取所有必要的資訊，且用於所有設備。

以下部分將詳細介紹遊戲解決方案的每個關鍵元件。

選擇一個遊戲伺服器

允許玩家加入遊戲伺服器並與其他玩家互動是主界面最重要的組件之一。 玩家配對是這款遊戲解決方案的一個部分，它與玩家在同一地區和遊戲模式的用戶相匹配。 根據搜索，性能和可擴展性要求，此解決方案還可以通過利用Cloud SQL ，Google自定義搜索API或Google Cloud Datastore來擴展到包含所有功能的伺服器和搜索功能。

連接到專用遊戲伺服器

玩家選擇伺服器加入後，遊戲客戶端接收到專用伺服器的IP地址，玩家的遊戲客戶端建立和與運行在Compute Engine上的專用伺服器做連接，並加載遊戲中的虛擬財產。

Compute Engine遊戲伺服器負責通過低延遲的客戶端伺服器通信處理所有玩家的互動。 有關設計多人遊戲伺服器的相關資訊超出了本文的範圍。 設計多人遊戲伺服器時，建議利用現有的遊戲伺服器和SDK。

管理遊戲中的請求和Compute Engine運行狀況檢查

當Compute Engine上運行專用遊戲伺服器時，可能需要將遊戲中的請求發送到App Engine。 如果玩家從商店購買商品或建立了自訂的遊戲config，則App Engine可以維護此資訊。 此外，專用遊戲伺服器可以回傳到App Engine來更新玩家分數，統計數據和體驗級別。

當一整個流程完成後，玩家可以保留在遊戲伺服器上進行新一輪的循環或者重新導到器配對。 玩家的分數，比賽統計數據和遊戲中商店建議可以在輪次之間顯示。 如果專門的遊戲伺服器意外終止，則遊戲客戶端必須處理此事件，並將玩家重新導至新會話(sessions)進行伺服器配對。

自動縮放遊戲伺服器

自動縮放是第一個不會顯著影響遊戲的後台任務之一，然而對於構建可擴展的全功能遊戲至關重要。 此步驟將了解App Engine中的開發人員實施的專用遊戲伺服器自動縮放邏輯。 隨著玩家數量的增加，虛擬機將創建新的專用伺服器來處理增加的負載量。 同樣，如果白天的玩家人數減少，則可以關閉未使用的專用伺服器以降低成本。

儲存日誌(logs)進行分析

Cloud Storage是儲存文件的好選擇，例如伺服器日誌和分析pipeline輸出。 Compute Engine上的專用遊戲伺服器產生了大量有價值的數據，用於了解玩家行為和排除軟件錯誤。 為了長期儲存這些數據，文件應該使用後台進程(process)，定期從Compute Engine Instances上傳到Cloud Storage。 如果需要分析pipeline來轉換和合併數據，則可以從Cloud Storage下載相關文件，並在其他Compute Engine上進行處理。 作業的輸出可以儲存在Cloud Storage中，可以將其輸入到Google BigQuery中的其他pipeline輸入，也可以編譯成報告。 有關資訊，請參閱使用Cloud Dataflow處理日誌並使用Fluentd和BigQuery進行即時日誌分析 。

使用BigQuery分析大量用戶和遊戲數據集

集成到此解決方案中的BigQuery是一種用於實時分析大量數據集的特殊查詢工具。 當專用遊戲伺服器託管數百萬活躍玩家時，您可以獲得數十億行的有用數據。 無論是原始遊戲日誌還是分析pipeline輸出，可以使用預定義(predefined)的模式將數據加載到BigQuery中。 加載完成後，SQL類查詢在幾秒鐘內完成，可用於獲取有價值的資訊，如用戶參與和遊戲激勵的影響。

實施細節

本節提供了分配玩家負載和提供創建全功能遊戲體驗所需的核心遊戲功能的實現細節。 該解決方案的主要焦點是分發遊戲伺服器來處理玩家線上即時互動的核心場景。 該解決方案可以延伸作為全店和社區模型的附加功能，但這些功能不在本文的範圍之內。

以下架構圖顯示了可擴展的專用伺服器遊戲解決方案。

 

請求一個遊戲伺服器

玩家使用遊戲伺服器的瀏覽器根據配對標準來請求推薦的遊戲伺服器清單。 此請求是通過Google Cloud Endpoints提交的，它提供了由App Engine提供的身份驗證的RESTful API。

配對邏輯

匹配邏輯為用戶提供了推薦伺服器的清單。 根據配對要求的規模和頻率，您可以使用各種技術實現此解決方案。一種方法是使用App Engine後台來維護每個資料中心內推薦的伺服器清單，然後將該清單儲存在Memcache中以便快速檢索。 推薦伺服器的邏輯取決於遊戲的類型。 例如，一些遊戲推薦負載最低的伺服器以最小化延遲，而其他遊戲需要最少數量的人連接到每個伺服器以進行更多的配對排列。 雖然Memcache提供了高性能，分佈式快取(cache)，物件緩存系統等，但建議也必須儲存在Cloud Datastore中，以避免Memcache的突發狀況。 App Engine Cron服務可以每分鐘安排任務。 對於後台來說，維護每個區域的推薦伺服器清單非常重要，因為玩家通常希望連接到最低延遲的伺服器。 其他伺服器選擇技術可以通過可用伺服器循環，或者向客戶端提供合理大小的清單，以便它可以識別最低延遲伺服器。 更複雜的解決方案可以包括維護所有伺服器的伺服器計數，加載，延遲和狀態的任務。 解決方案也可以設計為動態查詢每個請求。

返回配對結果

匹配的結果返回給客戶端，玩家從清單中選擇或客戶端自動選擇理想的伺服器。

連接到專用伺服器

遊戲客戶端嘗試連接到所選擇的專用遊戲伺服器的IP地址。 如果連接失敗或伺服器已滿，客戶端可以嘗試連接備用建議的伺服器或將玩家重新引導到伺服器配對。

處理遊戲中的請求

在玩家建立與專用遊戲伺服器的連接之後，伺服器負責處理來自玩家的所有事件並提供關於當前在比賽中的其他玩家的資訊。 App Engine通過處理重要事件和提供玩家資訊以達到在所有專用伺服器上保持一致的遊戲體驗。 例如，如果玩家具有自訂config，則對App Engine的請求提供有關config的資訊，並允許玩家存取所有購買的項目。 隨著玩家獲得經驗並發生重要的遊戲中事件，細節將發送到App Engine，以保持所有玩家的完整視圖。 對Cloud Endpoints的認證請求和提供的RESTful API是將游戲伺服器連接到App Engine的簡單方法。

請求玩家配置(config)

當遊戲允許玩家購買物品或創建自定義字符配置時，所有資訊必須保持在可靠和可擴展的資料中。 Cloud Datastore旨在擴展為數百萬用戶提供服務的Web應用程序。 推薦雲數據儲存用於儲存所有玩家資訊，因為隨著遊戲從數百萬玩家的增長而無縫擴展。 還可以利用Memcache來儲存頻繁的Cloud Datastore查詢結果，以提高性能。 因為Memcache是​​一個有限的資源，要小心使用它。 如果您需要使用複雜的SQL查詢或者由於其他原因需要使用MySQL，Cloud SQL將提供完全管理和高可用性的關係資料庫即服務。 儘管它與App Engine緊密集成，但是Cloud SQL並沒有設計成無限擴展，強烈建議使用負載測試來查看真實資料庫的性能。 對於高性能，將成本保持在絕對最小值不是問題，請考慮使用Google Cloud BigTable來適應場景和數據類型。

儲存重要的遊戲中的事件

處理和儲存重要事件，如玩家在遊戲之後獲得經驗的玩家，是創造一個有趣的遊戲的關鍵部分。 與玩家配置請求類似，這些請求由App Engine處理，您可以在Cloud Datastore中儲存關鍵資訊。 這兩種類型的請求之間的主要區別在於，對於所有活動玩家，遊戲中的事件可能發生在更高的頻率。 例如，玩家的配置只能在比賽開始時獲得，儘管每次玩家角色獲得經驗時，遊戲中的事件都會發生。 儘管Cloud Datastore可以擴展到數百萬用戶處理數千個事件，但您應該了解實體組，NoSQL以及最終的一致性，以消除潛在的可擴展性問題。 Cloud BigTable也可以是一個很好的解決方案，這裡適用於適用的場景和數據類型。

跟踪伺服器運行狀況

保持健康的專用遊戲伺服器集群的關鍵組成部分是持續跟踪每台伺服器的統計數據和健康狀況。 再次，您可以使用雲端點提供經過身份驗證的RESTful API，每個Compute Engine上運行的進程可以提供有關使用情況的統計資訊。 與諸如CPU和RAM使用量之類的硬體相關資訊可以與遊戲特定資訊一起提供，例如平均玩家延遲和在伺服器上活動的玩家數量。

儲存伺服器運行狀況和統計資訊

在每個Compute Engine實例上運行的心跳過程可以提供有價值的資訊。 需要伺服器心跳邏輯來分析和儲存相關數據。 與自動縮放直接相關的資訊，例如在伺服器上活動的玩家數量和平均延遲，應該緩存在Memcache中，以便通過自動縮放後端進程快速檢索。 任何重要的值也應該儲存在Cloud Datastore中，以防止Memcache的驅逐。 如果此資訊與分析和維護伺服器歷史記錄相關，請將所有歷史值儲存在獨立於自動縮放功能的獨立表中。

自動縮放專用遊戲伺服器並維護一個健康的群集

雖然有許多方法可以自動縮放Compute Engine資源相對於玩家的負載，但共同的組件包括每分鐘運行App Engine Cron服務的計劃任務。 您可以按預定的時間表計算理想數量的虛擬機，或通過分析遊戲伺服器中的可用位置數量或玩家延遲。 自動縮放的其他重要輸入是通過從Memcache或Cloud Datastore中拉出最近的心跳過程數據來確定目前活躍的健康機器數量。 您可以計算遊戲伺服器的理想值和當前數量之間的差異，以決定何時以及如何創建或刪除實例。 此外，任何不健康的伺服器都應配置為從伺服器選擇中刪除它們，並在伺服器上沒有玩家之後刪除實例。 如果需要在不同Compute Engine區域之間遷移遊戲伺服器，則可以使用自動縮放邏輯在新區域中創建實例，同時終止舊區域中的空閒實例。 這是對自動縮放遊戲伺服器的非常高級的概述，強烈建議您仔細實施縮放算法。 專注於避免諸如超調和嘈雜的反應等問題。 Compute Engine伺服器每分鐘收費至少10分鐘，以減少未使用的Compute Engine實例的不必要成本，避免頻繁創建和刪除實例。

創建和刪除專用遊戲伺服器

必須刪除或創建遊戲伺服器時，會將任務添加到App Engine任務隊列中。 單獨的後台任務負責拉取伺服器維護任務並進行Compute Engine API調用。 如果所需的API調用數量超出單個後端的限制，則可以添加額外的後端。 如果幾乎沒有Compute Engine API調用，伺服器維護可以由計劃的任務來處理，以減少App Engine資源的使用。 您應該在每個伺服器維護任務中包含一個時間戳記，以便在系統中發展積壓時創建警報。 您可以使用推送隊列作為拉取隊列的替代方法。 您應該運行負載測試來評估每個自動縮放系統在大量使用情況下的響應。 儘管Google不提供負載測試服務，但是可以在Compute Engine上運行常用的開放源碼技術，也可以將第三方服務用於廣泛的負載測試。

將日誌儲存在Cloud Storage中

可以在每個遊戲伺服器上生成許多日誌文件，例如記錄每個玩家的動作和動作的遊戲中伺服器日誌，或記錄終端遊戲統計資訊的日誌。 您可以通過使用定期運行的後台進程將這些文件複製到雲儲存。 如果文件包含關鍵數據，則應將它們儲存在永久磁盤上，以防止數據丟失，例如在復製過程完成之前實例終止。 否則，將文件儲存在標準磁盤上提供了較低成本的替代方案，但在實例終止後，磁盤將被立即刪除。 無論磁盤選擇如何，您都應該有一個自動複製過程來維護雲儲存中的所有日誌和統計資訊。

轉換和處理日誌文件

從伺服器收集大量原始日誌數據後，需要清除日誌文件，增加附加數據，並將其聚合到不同的級別。 您可以使用MapReduce或提取，轉換和加載（ETL）工具（如Google Cloud Dataflow ）創建可用於面向用戶的功能（如購買建議）或加載到Google BigQuery進行分析的數據。

報告和分析

BigQuery是遊戲解決方案的重要組成部分，因為它允許對包含用戶和遊戲相關資訊的大量數據集進行臨時分析。 例如，BigQuery可用於確定遊戲激勵（如商店銷售）對用戶保留和參與的影響。 BigQuery保持一致的性能，因為數據可以擴展到數TB和數十億行。

範例應用

演示此解決方案的high-level的範例應用程式可用，可用作工作參考。 範例應用程式的核心功能包括：
• 客戶端查詢App Engine的專用遊戲伺服器的IP地址。
• 客戶端通過連接到運行在Compute Engine上的遊戲伺服器來啟動新遊戲。
• 管理員可以從App Engine管理UI創建和刪除遊戲伺服器。
• Compute Engine實例定期向App Engine報告負載水平。
• 管理員可以查看所有遊戲伺服器Compute Engine實例的負載水平。
• 如果集群超過最大負載閾值，App Engine會自動向集群添加新實例。

從 Github下載 source code。