在之前的 《遊戲開發經驗談（一）：遊戲架構裡隱藏的五個坑及其應對方案》，我們主要講解了遊戲架構設計當中隱藏的一些坑及其應對方案，錯過的小夥伴可以回溯之前的內容。本期內容，將會重點介紹對戰類全球服遊戲的設計思路與技術實現。
對戰類遊戲的設計思路
協議的選擇
遊戲設計之初，需要決定選擇哪種協議來進行通訊。對於對戰類遊戲來說，首先推薦的肯定是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進行關注。