游戲開(kāi)發(fā)經(jīng)驗(yàn)談（二）：對(duì)戰(zhàn)類全球服游戲的設(shè)計(jì)與實(shí)現(xiàn)

上篇文章《游戲開(kāi)發(fā)經(jīng)驗(yàn)談（一）：游戲架構(gòu)里隱藏的五個(gè)坑及其應(yīng)對(duì)方案》，我們主要講解了游戲架構(gòu)設(shè)計(jì)當(dāng)中隱藏的一些坑及其應(yīng)對(duì)方案，錯(cuò)過(guò)的小伙伴可以點(diǎn)擊鏈接回溯之前的內(nèi)容。本期內(nèi)容，將會(huì)重點(diǎn)介紹對(duì)戰(zhàn)類全球服游戲的設(shè)計(jì)思路與技術(shù)實(shí)現(xiàn)。

對(duì)戰(zhàn)類游戲的設(shè)計(jì)思路

協(xié)議的選擇

游戲設(shè)計(jì)之初，需要決定選擇哪種協(xié)議來(lái)進(jìn)行通訊。對(duì)于對(duì)戰(zhàn)類游戲來(lái)說(shuō)，首先推薦的肯定是UDP。

盡管UDP對(duì)開(kāi)發(fā)基礎(chǔ)有較高的要求，需要開(kāi)發(fā)者自己實(shí)現(xiàn)傳輸成功檢驗(yàn)、重傳以及可靠性保證等，但相對(duì)于低開(kāi)發(fā)成本的TCP，UDP在效率和時(shí)效性上都有極大的優(yōu)勢(shì)，它可以根據(jù)業(yè)務(wù)特性進(jìn)行短間隔重傳，或者直接發(fā)送復(fù)數(shù)包來(lái)提高弱聯(lián)網(wǎng)狀態(tài)的成功率。

此外，相比于UDP的低延時(shí)，TCP的重傳時(shí)間是秒級(jí)，對(duì)于對(duì)戰(zhàn)類游戲來(lái)說(shuō)，TCP的重傳速度無(wú)疑會(huì)造成非常糟糕的玩家體驗(yàn)，雖然有BBR一類的技術(shù)，但也僅僅只能實(shí)現(xiàn)更高效的帶寬利用，對(duì)于實(shí)際業(yè)務(wù)響應(yīng)效率沒(méi)有特別大的提升。

當(dāng)然，除了技術(shù)角度分析，公司的實(shí)際情況也是需要納入考慮的重要的一環(huán)。總體來(lái)說(shuō)，COC、KOA(阿瓦隆之王)等地圖類少交互的游戲用TCP是沒(méi)有問(wèn)題的，而CR（皇室戰(zhàn)爭(zhēng)）、自由之戰(zhàn)、全民槍?xiě)?zhàn)、槍林彈雨，這類MOBA、FPS等強(qiáng)聯(lián)網(wǎng)需求的對(duì)戰(zhàn)游戲，UDP基本是必備的。

同步機(jī)制

幀同步:快節(jié)奏、同時(shí)希望降低服務(wù)器不必要負(fù)載的對(duì)戰(zhàn)類手游，幀同步是不二的選擇。幀同步的好處是可以精減上傳信息，只是做一些簡(jiǎn)單的數(shù)據(jù)匯總上報(bào)，需要的帶寬非常少。
狀態(tài)同步:安全性很高，但狀態(tài)同步需要的帶寬量遠(yuǎn)大于幀同步，而全球服游戲本身面臨著非常嚴(yán)峻的全球網(wǎng)絡(luò)環(huán)境，甚至很多情況下需要專線來(lái)解決網(wǎng)絡(luò)問(wèn)題，這時(shí)候，網(wǎng)絡(luò)開(kāi)銷將是比較大的成本。
簡(jiǎn)而言之，一句話：如果你想做全球服游戲，請(qǐng)務(wù)必學(xué)會(huì)幀同步。

最后，簡(jiǎn)單說(shuō)一下對(duì)戰(zhàn)游戲的幾點(diǎn)特性：1）因?yàn)椴捎肬DP和幀同步，數(shù)據(jù)包交互包量巨大；2）玩家快照和幀數(shù)據(jù)保存需要高性能大容量的內(nèi)存存儲(chǔ)；3）網(wǎng)絡(luò)穩(wěn)定要求高；4）架構(gòu)主要以模塊化為主，有的甚至可以兩地三中心容災(zāi)，需要敏捷部署。

總體來(lái)說(shuō)，對(duì)戰(zhàn)類游戲?qū)ο到y(tǒng)架構(gòu)有較高的要求。而云平臺(tái)產(chǎn)品，正是為幫助用戶解決這些問(wèn)題而存在的。

網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)

那么，我們是如何為對(duì)戰(zhàn)類強(qiáng)聯(lián)網(wǎng)用戶提供網(wǎng)絡(luò)支撐的呢？首先，在網(wǎng)絡(luò)質(zhì)量方面，我們采用自建的BGP及自有AS號(hào)，直接和電信聯(lián)通移動(dòng)等運(yùn)營(yíng)商進(jìn)行路由對(duì)接。相比于找中間商，這種方式在網(wǎng)絡(luò)的覆蓋質(zhì)量、故障容災(zāi)能力以及高可用上，都有更好的保障。

此外，我們將機(jī)房和網(wǎng)絡(luò)進(jìn)行了分離，網(wǎng)絡(luò)出口各自獨(dú)立，通過(guò)不同的物理路徑走到不同的出口POP點(diǎn)，這里的POP點(diǎn)就是UCloud自建BGP和運(yùn)營(yíng)商建立連接的地方，最底層是可用區(qū)，也就是傳統(tǒng)意義上的機(jī)房。當(dāng)用戶在UCloud平臺(tái)部署的時(shí)候，就是利用了可用區(qū)的架構(gòu)。

這種方式可以將所有的機(jī)房資源池化并通過(guò)專線打通內(nèi)網(wǎng)，為用戶免費(fèi)提供相同地區(qū)不同機(jī)房間的網(wǎng)絡(luò)互通，方便用戶實(shí)現(xiàn)跨機(jī)房高可用的容災(zāi)架構(gòu)，同時(shí)多POP點(diǎn)也可以規(guī)避物理路徑問(wèn)題或者運(yùn)營(yíng)商本地城域網(wǎng)故障（比如北京本地）帶來(lái)的影響，保證機(jī)房出口的持續(xù)高可用。

基于UCloud云平臺(tái)的游戲架構(gòu)示例

下圖是一個(gè)基于UCloud云平臺(tái)的全球服游戲架構(gòu)，首先，數(shù)據(jù)存儲(chǔ)層直接使用了高可用數(shù)據(jù)庫(kù)和Redis來(lái)降低運(yùn)維成本，并保證業(yè)務(wù)可用性；后端在原生產(chǎn)品的邏輯上，對(duì)諸如半同步等功能進(jìn)行了自研強(qiáng)化，在不改變?nèi)魏斡脩羰褂昧?xí)慣的情況下，強(qiáng)化數(shù)據(jù)一致性、安全性、以及查詢性能。

此外，服務(wù)器區(qū)域采用整體框架集群+高性能負(fù)載均衡的接入模式，TCP四層報(bào)文轉(zhuǎn)發(fā)，保證大并發(fā)下的性能可靠；而對(duì)戰(zhàn)服務(wù)器采用了注冊(cè)機(jī)制，房間管理服務(wù)器為主從高可用，由于對(duì)戰(zhàn)采用了UDP+幀同步的模式，包量可能會(huì)達(dá)到5W-8W甚至更多，因此直接采用了網(wǎng)絡(luò)增強(qiáng)云主機(jī)來(lái)承載。

在全局層面，數(shù)據(jù)庫(kù)和負(fù)載均衡器都采用了UCloud跨可用區(qū)容災(zāi)的高可用產(chǎn)品和集群，業(yè)務(wù)服務(wù)器在我們的D/E兩個(gè)可用區(qū)對(duì)半部署，保證業(yè)務(wù)的機(jī)房級(jí)容災(zāi)能力。

根據(jù)對(duì)戰(zhàn)游戲的特性，簡(jiǎn)單總結(jié)下對(duì)戰(zhàn)游戲架構(gòu)設(shè)計(jì)需要注意的幾個(gè)點(diǎn)：1）服務(wù)集群化。如果要做全球化對(duì)戰(zhàn)游戲，服務(wù)器需要集群高可用，如果是滾服模式，運(yùn)維成本以及玩家跨服對(duì)戰(zhàn)成本將會(huì)非常高；2）服務(wù)模塊化。功能拆分時(shí)便于管理擴(kuò)容，并且最大化利用效率節(jié)省成本；3）業(yè)務(wù)自動(dòng)化。幫助降低運(yùn)維成本，在業(yè)務(wù)突發(fā)的情況下能夠快速擴(kuò)容提升敏捷性。

全球服技術(shù)實(shí)現(xiàn)

全球服游戲?qū)⑴c人斗的主旨放大化，隨著國(guó)戰(zhàn)以及其他國(guó)別特性玩法的加入，基于全球服的對(duì)戰(zhàn)游戲能夠很好地激發(fā)玩家的歸屬感，提升玩家對(duì)游戲的黏著度和對(duì)戰(zhàn)積極度。落實(shí)到技術(shù)層面，相比于分區(qū)對(duì)戰(zhàn)游戲，全球服對(duì)戰(zhàn)游戲的實(shí)現(xiàn)難度要高上許多，主要在于以下三點(diǎn)：

網(wǎng)絡(luò)： 對(duì)戰(zhàn)類游戲模式不同對(duì)于網(wǎng)絡(luò)性能的要求不同，但為了保證傳輸性能，普遍會(huì)選用UDP協(xié)議實(shí)現(xiàn)業(yè)務(wù)可靠傳輸；
代碼： 核心架構(gòu)可能同分區(qū)的對(duì)戰(zhàn)游戲沒(méi)有特別大的區(qū)別，但是在網(wǎng)絡(luò)設(shè)計(jì)、部署架構(gòu)模式、網(wǎng)絡(luò)延遲等情況下需要考慮更多；
架構(gòu)： 不管是集中部署還是分布式部署，架構(gòu)的本地承載量、模塊化設(shè)計(jì)都要考慮應(yīng)對(duì)全球玩家涌入的問(wèn)題。

網(wǎng)絡(luò)

我國(guó)實(shí)際出口的公網(wǎng)主要有電信163、聯(lián)通、移動(dòng)以及電信CN2四大類，總帶寬方面電信是最大的，聯(lián)通次之，移動(dòng)最小。就實(shí)際利用率來(lái)說(shuō)，電信163出口常年擁堵，可用率不足80%，聯(lián)通移動(dòng)情況稍好，但是由于本身出口量較小，應(yīng)對(duì)網(wǎng)絡(luò)波動(dòng)的能力不容樂(lè)觀。

CN2是電信專門(mén)為企業(yè)級(jí)客戶開(kāi)通的國(guó)際出口，這也是中國(guó)當(dāng)前最優(yōu)的國(guó)際出口網(wǎng)絡(luò)，但即便是CN2也并非完全穩(wěn)定，根據(jù)監(jiān)控記錄顯示，CN2鏈路每月仍然會(huì)有幾次較長(zhǎng)時(shí)間的抖動(dòng)，如果正好趕上游戲大推依然會(huì)有風(fēng)險(xiǎn)。

最保險(xiǎn)的方案就是使用專線，專線具有SLA和可用性保證，并具有高穩(wěn)定、低延遲、零丟包等特性，但是成本相對(duì)公網(wǎng)會(huì)高上許多。

UCloud在海外采用的同樣是自有BGP技術(shù)，并且基于BGP+海外專線，保證最優(yōu)的訪問(wèn)質(zhì)量，其基于路由的定位準(zhǔn)確度遠(yuǎn)高于CDN的智能DNS。

此外，在運(yùn)維和產(chǎn)品保障方面，我們將國(guó)內(nèi)的模式復(fù)制到了海外，并且根據(jù)不同的機(jī)房情況和地區(qū)特性進(jìn)行了優(yōu)化，將海外的機(jī)房架構(gòu)和云產(chǎn)品架構(gòu)在全局上和國(guó)內(nèi)同步，以保證客戶體驗(yàn)的一致性和服務(wù)的標(biāo)準(zhǔn)性。

代碼

此前，我們接觸過(guò)一個(gè)用戶，他們希望獲得一個(gè)有保障的網(wǎng)絡(luò)優(yōu)化加速方案來(lái)實(shí)現(xiàn)全球服，并且要求整個(gè)加速過(guò)程對(duì)業(yè)務(wù)無(wú)感知無(wú)侵入。簡(jiǎn)而言之，就是在不更改任何的代碼的前提下，實(shí)現(xiàn)網(wǎng)絡(luò)加速。為此我們進(jìn)行了系列技術(shù)調(diào)研和方案設(shè)計(jì)，PathX方案由此誕生。

前期的設(shè)計(jì)實(shí)現(xiàn)上，我們針對(duì)三四層網(wǎng)絡(luò)轉(zhuǎn)發(fā)以及基層代理這兩種方式進(jìn)行了深入調(diào)研，調(diào)研過(guò)程中發(fā)現(xiàn)，采用基層代理的方式會(huì)中斷TCP連接，同時(shí)，在使用的過(guò)程中還會(huì)出現(xiàn)業(yè)務(wù)無(wú)法轉(zhuǎn)發(fā)的情況，也就是所謂的“假死”。通過(guò)對(duì)比，最終我們選擇了三四層網(wǎng)絡(luò)轉(zhuǎn)發(fā)的方案，并且做一個(gè)比較廣的協(xié)議支持架構(gòu)。

后續(xù)，我們也針對(duì)CR的UDP對(duì)戰(zhàn)需求進(jìn)行了迭代，在原有的基礎(chǔ)上融合DPDK和高包量技術(shù)，設(shè)計(jì)了UDP+幀同步高包量業(yè)務(wù)的承載轉(zhuǎn)發(fā)模式。隨著全球服時(shí)代的到來(lái)，我們將這些特性迭代進(jìn)PathX產(chǎn)品，如今已經(jīng)是2.0的版本了。

架構(gòu)

全球服情況下，海量用戶數(shù)據(jù)需要集中的接入、處理和分析，而在大數(shù)據(jù)領(lǐng)域，Hadoop是當(dāng)仁不讓、最經(jīng)濟(jì)的大數(shù)據(jù)解決方案，但是Hadoop的使用門(mén)檻非常高，需要至少7-8人的維護(hù)團(tuán)隊(duì)。而相對(duì)使用簡(jiǎn)單的的普通數(shù)據(jù)庫(kù)如MySQL集群等，在性能和性價(jià)比上都不是非常理想。

為了解決用戶的高性能大數(shù)據(jù)分析需求，我們研發(fā)了數(shù)據(jù)倉(cāng)庫(kù)解決方案UDW，UDW基于PostgreSQL研發(fā)，具有PB級(jí)別的高性能數(shù)據(jù)存儲(chǔ)能力，此外，我們根據(jù)用戶的不同需求區(qū)分了存儲(chǔ)密集型和計(jì)算密集型，可分別用于數(shù)據(jù)量大或者對(duì)計(jì)算實(shí)時(shí)性要求較高的場(chǎng)景。

下圖是一個(gè)比較標(biāo)準(zhǔn)的全球服游戲架構(gòu)圖。首先，用戶在美國(guó)部署核心業(yè)務(wù)服務(wù)器，包括數(shù)據(jù)庫(kù)、玩家節(jié)點(diǎn)、大數(shù)據(jù)、登錄服等。然后通過(guò)全球加速方案，為玩家提供一個(gè)質(zhì)量穩(wěn)定的游戲服務(wù)。有的用戶如FPS類的游戲廠商，會(huì)在海外額外部署一個(gè)小的微型節(jié)點(diǎn)，用來(lái)保證對(duì)玩家的最小延遲和穩(wěn)定性。

架構(gòu)設(shè)計(jì)中，還有一個(gè)比較重要的點(diǎn)是關(guān)鍵幀的使用限制，關(guān)鍵幀和游戲預(yù)判會(huì)嚴(yán)重影響用戶對(duì)游戲的要求。比如用戶要求延遲控制在60毫秒以內(nèi)，那么對(duì)于60毫秒以上延遲的地區(qū)，游戲是無(wú)法覆蓋的，超過(guò)60毫秒的玩家就會(huì)直接掉線。

在部署全球服游戲的時(shí)候，除了要考慮網(wǎng)絡(luò)延遲對(duì)玩家的影響，玩家集中涌入對(duì)對(duì)戰(zhàn)的影響等問(wèn)題之外，還要測(cè)算出符合游戲要求的核心節(jié)點(diǎn)、不同區(qū)域玩家的最佳訪問(wèn)路徑、哪個(gè)區(qū)的玩家可以連接到哪里的服務(wù)器等等，這是問(wèn)題都需要在游戲設(shè)計(jì)前期就規(guī)劃好。

全球服游戲設(shè)計(jì)的一些想法和建議

云商、研發(fā)、運(yùn)維這三者雖然分工不同，但都是項(xiàng)目組不可或缺的重要組成。以我過(guò)往的經(jīng)驗(yàn)，運(yùn)維和研發(fā)之間在項(xiàng)目前期的交流通常都非常少，這樣就會(huì)導(dǎo)致出現(xiàn)故障時(shí)，大家經(jīng)常相互“甩鍋”，運(yùn)維工程師覺(jué)得是代碼的問(wèn)題，而開(kāi)發(fā)則認(rèn)為是運(yùn)維做得不夠好，這對(duì)于游戲項(xiàng)目來(lái)說(shuō)是百害而無(wú)一利的。

從項(xiàng)目的角度，建議云商、研發(fā)、運(yùn)維這三者能夠做到互相深入合作，云商能夠針對(duì)游戲用戶的訴求，提供最合適的產(chǎn)品和解決方案；運(yùn)維是保證整個(gè)游戲長(zhǎng)遠(yuǎn)穩(wěn)定運(yùn)行的核心人員，業(yè)務(wù)如何做到高可用、如何能夠在后期便捷的進(jìn)行維護(hù)，這些都是運(yùn)維非常擅長(zhǎng)的領(lǐng)域；而研發(fā)是整個(gè)項(xiàng)目能夠?qū)崿F(xiàn)的基石，代碼的實(shí)現(xiàn)思路會(huì)很大程度上固化一個(gè)游戲的運(yùn)維方式。

在項(xiàng)目建設(shè)前期，三方都不應(yīng)局限于自己的領(lǐng)域，互相協(xié)作開(kāi)放。在項(xiàng)目允許的情況下，研發(fā)設(shè)計(jì)框架時(shí)可以聯(lián)合運(yùn)維、公有云的架構(gòu)人員一同評(píng)估游戲的實(shí)現(xiàn)方式，盡量在前期考慮到系統(tǒng)的可用性、穩(wěn)定性以及抗壓性等問(wèn)題，這樣才能從技術(shù)角度避免很多不必要的彎路或者錯(cuò)漏，比如上篇文章所說(shuō)的中心服單點(diǎn)問(wèn)題，實(shí)現(xiàn)業(yè)務(wù)的長(zhǎng)遠(yuǎn)發(fā)展。

想要獲取更多技術(shù)和活動(dòng)資訊，可掃關(guān)注“UCloud技術(shù)公告牌”微信公眾號(hào)；或搜索微信ID：ucloud_tech進(jìn)行關(guān)注。