一款成功的全球服遊戲該如何進行架構選型與設計？

全球服遊戲現在正在成爲出海遊戲的主要考慮模式，跨國對戰、全球通服打破國界的限制，將不一樣地區不一樣語言的玩家放在一塊兒合做/競技，成功吸引了大量玩家的關注，並逐漸成爲主流的遊戲玩法。

遊戲廠商們也在嘗試採用一地部署多地覆蓋、全球逐步宣發的模式進行第一款全球服遊戲的發行試點及成本控制。文章主要針對全球服和出海遊戲的特性優點、架構佈局、網絡規劃、實用技術等幾個方面進行探討。

本文主要觀點：

(1) 微服務是主流，模塊化架構易於擴容以及維護，微服務+自動化的業務架構對於全球服遊戲來講幾乎是必然的選擇；

(2) 架構高度自動化，自動註冊/剔除保證可用性；

(3) 幀同步+UDP特性，高性能傳輸和帶寬成本控制（對戰類遊戲要求較爲突出）；

(4) 核心架構集中部署爲主，全球網絡優化覆蓋玩家；

(5) 遊戲代碼的關鍵幀及預判設計關係到遊戲對網絡延遲的兼容性。

爲何要微服務和自動化？

緣由一：全球服遊戲多爲邏輯服或無區服概念的通服、對戰類遊戲。爲了保證遊戲性和全球化的特色，保證匹配和遊戲世界玩家的多元化，傳統意義上的區服架構和跨服對戰模式並不適配，以皇室戰爭、列王紛爭等爲例的一衆匹配對戰遊戲即是其中的表明。

緣由二：全球服遊戲要求承載全球玩家的涌入，及時發現負載瓶頸並擴容是一個必然的要求，模塊化拆分架構以後能夠靈活的針對不一樣活動、玩家特性增長對應的業務服務器，並經過自動註冊機制實現快速擴容。

整個架構採用註冊管理+自動化以後，能夠經過研發腳本或者通行的管理工具，甚至Docker的K8S來實現業務宕機的自動恢復和容災、負載突發的自動擴容，這能夠極大的下降運維成本，並對於業務健壯性進行極大的提高。

對於遊戲服務的自動註冊機制，在項目早期，受限於研發實力或者工期，開發者通常會選擇ZooKeeper進行管理維護，可是在實際運行中因爲ZooKeeper自身較重的功能實現、二次開發及bug處理的複雜度，不少用戶會將其替換爲自主研發實現的輕量級RPC自動註冊服務。實際狀況要具體視研發能力而定，此外GRPC也有很多的支持者。

幀同步技術和UDP傳輸協議的使用

關於幀同步主要針對對戰類遊戲，對於RPG世界或者卡牌類遊戲也有必定參考意義，用戶使用幀同步主要在於三點：一、全球同步效率；二、服務端壓力緩解；三、全球化大流量的成本控制。

以往有過這樣的狀況，用戶在全球服遊戲逐步宣發、對應國家客戶端上線的過程當中，遇到跨國專線成本問題沒法承擔的問題，最終無奈選擇降級服務採用特殊優化過的外網出口覆蓋的案例。

而選擇使用UDP傳輸而非TCP傳輸主要考慮到對戰要求的實時性，TCP自身的重傳邏輯已經沒法知足全球化（對戰）遊戲的網絡保障要求，經過自主實現UDP重傳，甚至是報文同時重複發送的邏輯，來保證遊戲數據包最終的抵達成功率。

關於最核心的全球服模式上，個人總結是：先集中再分佈。

以當前大部分遊戲的框架，如卡牌對戰、RPG世界等徹底能夠經過集中部署+網絡調優的方式實現，當前全球雙向延遲通常在300ms之內，而通常人的反應時間通常在300ms左右，故網絡延遲對於玩家的感知很是微小，大部分遊戲均可以集中部署而且不犧牲玩家遊戲體驗。同時集中部署的另外一個優點是對於架構複雜度的下降，維護便捷度的提高，對於成本控制及玩家數據統計也會方便不少。

圖一：集中部署全球服架構

什麼狀況下考慮「再分佈」呢？首先，遊戲是房間類的對戰遊戲，其次遊戲對於網絡延遲極敏感（FPS類），最後重要的點是，遊戲架構採起的是對戰前緩存預熱數據、對戰結束後寫入的異步模式。

圖二：分佈式部署全球服架構

下圖爲對戰遊戲的基礎架構，經過該部署模式要點爲：

（1）平臺操做仍然集中化部署玩家統一訪問，如平常操做、裝備購買等延遲不敏感操做；（2）對戰房間分佈於全球各個數據中心，而當玩家須要對戰、進行匹配分房時，經過算法調度到相對大多數用戶最近的節點；

（3）節點提早預取相關用戶數據，對戰產生的所有數據統計由本地進行交互處理，並在對戰結束後集中上傳至中心數據節點。

圖三：對戰遊戲基礎架構

該方案在對戰網絡延遲和數據一致性上進行了保證，可是相對架構會更爲複雜，實際落地過程當中須要較好的配合和較深的維護經驗。

那麼，當前的分佈式數據庫解決方案是否可以解決全球服數據一致性的問題？實際上，爲了保證數據一致性，這裏以TiDB爲例，暫不支持超過30ms的集羣內部延遲。並且即便強行部署，集羣內部的高延遲會嚴重影響QPS性能。在當前的技術環境下，全球分佈式數據庫最好的表明者應該是區塊鏈技術，不過性能是絕對沒法知足大部分遊戲使用的，即便是僅有21個核心節點的EOS，其極限QPS也遠遜於普通配置的集中數據庫。

遊戲設計和網絡延遲的關係

遊戲設計初期必然要對當前全球網絡環境有一個初步瞭解，這點以前也有提到，基本上當前物理鏈路的雙向延遲爲300ms內，可是考慮到無線信號不穩定、傳統3G網絡性能等緣由，極端狀況可能達500-1000ms甚至更高的狀況，遊戲必須爲此進行必定取捨，早期幀同步遊戲會由於網絡最差的玩家形成整個戰局的卡頓，而隨着技術的發展，樂觀鎖已經經過捨棄低網絡質量玩家的部分數據包來保證全球的遊戲體驗。

圖四：簡單全球網絡數據

這邊先不說延遲自己，聊下限制網絡延遲的客觀因素和數據：地球周長是40076公里 (赤道)，光速恆定299792458米／秒（真空），而網絡當前主要是光纖傳輸，在物理速度和傳輸介質沒有突破性進展的狀況下繞地球一週須要近150ms，而實際網絡光纜不必定徹底直線，中間設備轉發也會形成延遲開銷，按照實際網絡質量評估的話，中國全國覆蓋通常在100ms（包括偏遠地區）。

咱們以前遇到一位用戶，研發要求全球服在60ms的延遲之內。按照正常狀況，60ms通常能夠勉強覆蓋北上廣三地熱門地區。可是要全球服的狀況下會比較捉襟見肘，這種狀況下，建議作成跨國區域服的模式。

另外關於國際出口的狀況，以中國爲例，從咱們的監控狀況看，常規出口的可用率並不樂觀，而咱們亞太數據中心接入的電信CN2精品網能夠作到不錯的穩定性保證（也的確有全球服遊戲經過此出口傳輸），可是並不能作到很是完美的SLA，不按期也會發生擁塞和抖動。並且這個問題並非中國特例，臺灣地區、俄羅斯、印尼、印度部分邦都存在有必定的跨國出口問題，須要經過外網接入點選擇或者產品解決方案如UCloud PathX解決方案進行網絡優化。

圖五：PathX案例視圖

因此在作一個全球服的項目以前，能夠先作調研、和雲廠商或者同行多聊聊，基於這些信息，在關鍵幀和樂觀鎖的時間制定、遊戲內部預判及同步機制的設計上會更有把握。

雜談拓展：區塊鏈遊戲

區塊鏈遊戲是一種新興的遊戲模式，可是本質上是依託於以太坊或者其餘共識模式的鏈實現的玩法，當前市場上的遊戲主要分兩類：一、純區塊鏈遊戲；二、裝備或蒐集元素上鍊。

前者主要以以太貓爲表明，核心是收集、養成類遊戲，隨着部分市場關注賦予了部分商業屬性。後者則是融合了區塊鏈元素在其內部，附加了不少其餘玩法，諸如集換式卡牌等等。

區塊鏈行業還在摸索階段，共識算法、共同監督、不能否認性是其核心特質，但性能較低、須要支付GAS等也是其短板，如今做相關評論還比較早，若是有興趣的話，能夠鑽研下相關共識技術，對於各類鏈、共識技術有一個認知後，再根據本身的遊戲模式選擇一個適合的場景。

通常來講區塊鏈遊戲和鏈自己是相互依存的，若是鏈自身出現問題也會影響到遊戲，能夠說鏈是基礎支撐，這個在選擇的時候建議慎重考慮。咱們也在探索相關的技術方向實踐，並同公有云進行結合。

做者介紹

沈皓：UCloud PathX產品早期方案設計者之一，深耕全球服遊戲領域，曾全面負責多個知名遊戲出海項目的全球/跨國業務對接、部署及落地。對於MOBA、RTS、FPS等各種遊戲的出海全球化的需求、難點、架構實現等深刻分析並有獨到看法。

更多內容，歡迎微信關注「UCloud技術公告牌」查看。