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

來自專欄大U的技術課堂7 人贊了文章

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

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

本文主要觀點：

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

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

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

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

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

為什麼要微服務和自動化？

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

原因二：全球服遊戲要求承載全球玩家的湧入，及時發現負載瓶頸並擴容是一個必然的要求，模塊化拆分架構之後可以靈活的針對不同活動、玩家特性增加對應的業務伺服器，並通過自動註冊機制實現快速擴容。

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

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

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

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

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

而選擇使用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案例視圖

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

雜談拓展：區塊鏈遊戲

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

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

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

一般來說區塊鏈遊戲和鏈本身是相互依存的，如果鏈自身出現問題也會影響到遊戲，可以說鏈是基礎支撐，這個在選擇的時候建議慎重考慮。我們也在探索相關的技術方向實踐，並同公有雲進行結合。7月21號UCan下午茶成都站——「遊戲出海，那些彎和那些坑」主題沙龍上，沈皓也會在現場深入分享出海遊戲全球服架構及解決方案，感興趣的讀者可以關注沙龍後續技術內容。

作者介紹

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

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