對戰類遊戲的設計思路

協議的選擇

遊戲設計之初，需要決定選擇哪種協議來進行通訊。對於對戰類遊戲來說，首先推薦的肯定是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協議實現業務可靠傳輸；
代碼： 核心架構可能同分區的對戰遊戲沒有特別大的區別，但是在網絡設計、部署架構模式、網絡延遲等情況下需要考慮更多；
架構： 不管是集中部署還是分布式部署，架構的本地承載量、模塊化設計都要考慮應對全球玩家湧入的問題。

網絡

我國實際出口的公網主要有電信163、聯通、移動以及電信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進行關註。

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