遊戲開發經驗談（二）：對戰類全球服遊戲的設計與實現

上篇文章《遊戲開發經驗談（一）：遊戲架構裏隱藏的五個坑及其應對方案》，咱們主要講解了遊戲架構設計當中隱藏的一些坑及其應對方案，錯過的小夥伴能夠回溯以前的內容。本期內容，將會重點介紹對戰類全球服遊戲的設計思路與技術實現。

對戰類遊戲的設計思路

協議的選擇

遊戲設計之初，須要決定選擇哪一種協議來進行通信。對於對戰類遊戲來講，首先推薦的確定是UDP。

儘管UDP對開發基礎有較高的要求，須要開發者本身實現傳輸成功檢驗、重傳以及可靠性保證等，但相對於低開發成本的TCP，UDP在效率和時效性上都有極大的優點，它能夠根據業務特性進行短間隔重傳，或者直接發送複數包來提升弱聯網狀態的成功率。

此外，相比於UDP的低延時，TCP的重傳時間是秒級，對於對戰類遊戲來講，TCP的重傳速度無疑會形成很是糟糕的玩家體驗，雖然有BBR一類的技術，但也僅僅只能實現更高效的帶寬利用，對於實際業務響應效率沒有特別大的提高。

固然，除了技術角度分析，公司的實際狀況也是須要歸入考慮的重要的一環。整體來講，COC、KOA(阿瓦隆之王)等地圖類少交互的遊戲用TCP是沒有問題的，而CR（皇室戰爭）、自由之戰、全民槍戰、槍林彈雨，這類MOBA、FPS等強聯網需求的對戰遊戲，UDP基本是必備的。

同步機制

幀同步: 快節奏、同時但願下降服務器沒必要要負載的對戰類手遊，幀同步是不二的選擇。幀同步的好處是能夠精減上傳信息，只是作一些簡單的數據彙總上報，須要的帶寬很是少。 狀態同步: 安全性很高，但狀態同步須要的帶寬量遠大於幀同步，而全球服遊戲自己面臨着很是嚴峻的全球網絡環境，甚至不少狀況下須要專線來解決網絡問題，這時候，網絡開銷將是比較大的成本。 簡而言之，一句話：若是你想作全球服遊戲，請務必學會幀同步。

最後，簡單說一下對戰遊戲的幾點特性：1）由於採用UDP和幀同步，數據包交互包量巨大；2）玩家快照和幀數據保存須要高性能大容量的內存存儲；3）網絡穩定要求高；4）架構主要以模塊化爲主，有的甚至能夠兩地三中心容災，須要敏捷部署。

整體來講，對戰類遊戲對系統架構有較高的要求。而云平臺產品，正是爲幫助用戶解決這些問題而存在的。

網絡架構設計

那麼，咱們是如何爲對戰類強聯網用戶提供網絡支撐的呢？首先，在網絡質量方面，咱們採用自建的BGP及自有AS號，直接和電信聯通移動等運營商進行路由對接。相比於找中間商，這種方式在網絡的覆蓋質量、故障容災能力以及高可用上，都有更好的保障。

此外，咱們將機房和網絡進行了分離，網絡出口各自獨立，經過不一樣的物理路徑走到不一樣的出口POP點，這裏的POP點就是UCloud自建BGP和運營商創建鏈接的地方，最底層是可用區，也就是傳統意義上的機房。當用戶在UCloud平臺部署的時候，就是利用了可用區的架構。

這種方式能夠將全部的機房資源池化並經過專線打通內網，爲用戶免費提供相同地區不一樣機房間的網絡互通，方便用戶實現跨機房高可用的容災架構，同時多POP點也能夠規避物理路徑問題或者運營商本地城域網故障（好比北京本地）帶來的影響，保證機房出口的持續高可用。

基於UCloud雲平臺的遊戲架構示例

下圖是一個基於UCloud雲平臺的全球服遊戲架構，首先，數據存儲層直接使用了高可用數據庫和Redis來下降運維成本，並保證業務可用性；後端在原生產品的邏輯上，對諸如半同步等功能進行了自研強化，在不改變任何用戶使用習慣的狀況下，強化數據一致性、安全性、以及查詢性能。

此外，服務器區域採用總體框架集羣+高性能負載均衡的接入模式，TCP四層報文轉發，保證大併發下的性能可靠；而對戰服務器採用了註冊機制，房間管理服務器爲主從高可用，因爲對戰採用了UDP+幀同步的模式，包量可能會達到5W-8W甚至更多，所以直接採用了網絡加強雲主機來承載。

在全局層面，數據庫和負載均衡器都採用了UCloud跨可用區容災的高可用產品和集羣，業務服務器在咱們的D/E兩個可用區對半部署，保證業務的機房級容災能力。

根據對戰遊戲的特性，簡單總結下對戰遊戲架構設計須要注意的幾個點：1）服務集羣化。若是要作全球化對戰遊戲，服務器須要集羣高可用，若是是滾服模式，運維成本以及玩家跨服對戰成本將會很是高；2）服務模塊化。功能拆分時便於管理擴容，而且最大化利用效率節省成本；3）業務自動化。幫助下降運維成本，在業務突發的狀況下可以快速擴容提高敏捷性。

全球服技術實現

全球服遊戲將與人斗的主旨放大化，隨着國戰以及其餘國別特性玩法的加入，基於全球服的對戰遊戲可以很好地激發玩家的歸屬感，提高玩家對遊戲的黏着度和對戰積極度。落實到技術層面，相比於分區對戰遊戲，全球服對戰遊戲的實現難度要高上許多，主要在於如下三點：

網絡： 對戰類遊戲模式不一樣對於網絡性能的要求不一樣，但爲了保證傳輸性能，廣泛會選用UDP協議實現業務可靠傳輸； 代碼： 核心架構可能同分區的對戰遊戲沒有特別大的區別，可是在網絡設計、部署架構模式、網絡延遲等狀況下須要考慮更多； 架構： 無論是集中部署仍是分佈式部署，架構的本地承載量、模塊化設計都要考慮應對全球玩家涌入的問題。

網絡

我國實際出口的公網主要有電信16三、聯通、移動以及電信CN2四大類，總帶寬方面電信是最大的，聯通次之，移動最小。就實際利用率來講，電信163出口常年擁堵，可用率不足80%，聯通移動狀況稍好，可是因爲自己出口量較小，應對網絡波動的能力不容樂觀。

CN2是電信專門爲企業級客戶開通的國際出口，這也是中國當前最優的國際出口網絡，但即使是CN2也並不是徹底穩定，根據監控記錄顯示，CN2鏈路每個月仍然會有幾回較長時間的抖動，若是正好遇上游戲大推依然會有風險。

最保險的方案就是使用專線，專線具備SLA和可用性保證，並具備高穩定、低延遲、零丟包等特性，可是成本相對公網會高上許多。

UCloud在海外採用的一樣是自有BGP技術，而且基於BGP+海外專線，保證最優的訪問質量，其基於路由的定位準確度遠高於CDN的智能DNS。

此外，在運維和產品保障方面，咱們將國內的模式複製到了海外，而且根據不一樣的機房狀況和地區特性進行了優化，將海外的機房架構和雲產品架構在全局上和國內同步，以保證客戶體驗的一致性和服務的標準性。

代碼

此前，咱們接觸過一個用戶，他們但願得到一個有保障的網絡優化加速方案來實現全球服，而且要求整個加速過程對業務無感知無侵入。簡而言之，就是在不更改任何的代碼的前提下，實現網絡加速。爲此咱們進行了系列技術調研和方案設計，PathX方案由此誕生。

前期的設計實現上，咱們針對三四層網絡轉發以及基層代理這兩種方式進行了深刻調研，調研過程當中發現，採用基層代理的方式會中斷TCP鏈接，同時，在使用的過程當中還會出現業務沒法轉發的狀況，也就是所謂的「假死」。經過對比，最終咱們選擇了三四層網絡轉發的方案，而且作一個比較廣的協議支持架構。

後續，咱們也針對CR的UDP對戰需求進行了迭代，在原有的基礎上融合DPDK和高包量技術，設計了UDP+幀同步高包量業務的承載轉發模式。隨着全球服時代的到來，咱們將這些特性迭代進PathX產品，現在已是2.0的版本了。

架構

全球服狀況下，海量用戶數據須要集中的接入、處理和分析，而在大數據領域，Hadoop是當仁不讓、最經濟的大數據解決方案，可是Hadoop的使用門檻很是高，須要至少7-8人的維護團隊。而相對使用簡單的的普通數據庫如MySQL集羣等，在性能和性價比上都不是很是理想。

爲了解決用戶的高性能大數據分析需求，咱們研發了數據倉庫解決方案UDW，UDW基於PostgreSQL研發，具備PB級別的高性能數據存儲能力，此外，咱們根據用戶的不一樣需求區分了存儲密集型和計算密集型，可分別用於數據量大或者對計算實時性要求較高的場景。

下圖是一個比較標準的全球服遊戲架構圖。首先，用戶在美國部署核心業務服務器，包括數據庫、玩家節點、大數據、登陸服等。而後經過全球加速方案，爲玩家提供一個質量穩定的遊戲服務。有的用戶如FPS類的遊戲廠商，會在海外額外部署一個小的微型節點，用來保證對玩家的最小延遲和穩定性。

架構設計中，還有一個比較重要的點是關鍵幀的使用限制，關鍵幀和遊戲預判會嚴重影響用戶對遊戲的要求。好比用戶要求延遲控制在60毫秒之內，那麼對於60毫秒以上延遲的地區，遊戲是沒法覆蓋的，超過60毫秒的玩家就會直接掉線。

在部署全球服遊戲的時候，除了要考慮網絡延遲對玩家的影響，玩家集中涌入對對戰的影響等問題以外，還要測算出符合遊戲要求的核心節點、不一樣區域玩家的最佳訪問路徑、哪一個區的玩家能夠鏈接到哪裏的服務器等等，這是問題都須要在遊戲設計前期就規劃好。

全球服遊戲設計的一些想法和建議

雲商、研發、運維這三者雖然分工不一樣，但都是項目組不可或缺的重要組成。以我過往的經驗，運維和研發之間在項目前期的交流一般都很是少，這樣就會致使出現故障時，你們常常相互「甩鍋」，運維工程師以爲是代碼的問題，而開發則認爲是運維作得不夠好，這對於遊戲項目來講是百害而無一利的。

從項目的角度，建議雲商、研發、運維這三者可以作到互相深刻合做，雲商可以針對遊戲用戶的訴求，提供最合適的產品和解決方案；運維是保證整個遊戲長遠穩定運行的核心人員，業務如何作到高可用、如何可以在後期便捷的進行維護，這些都是運維很是擅長的領域；而研發是整個項目可以實現的基石，代碼的實現思路會很大程度上固化一個遊戲的運維方式。

在項目建設前期，三方都不該侷限於本身的領域，互相協做開放。在項目容許的狀況下，研發設計框架時能夠聯合運維、公有云的架構人員一同評估遊戲的實現方式，儘可能在前期考慮到系統的可用性、穩定性以及抗壓性等問題，這樣才能從技術角度避免不少沒必要要的彎路或者錯漏，好比上篇文章所說的中心服單點問題，實現業務的長遠發展。

想要獲取更多技術和活動資訊，可關注「UCloud技術公告牌」；或搜索微信ID：ucloud_tech進行關注。