建站
咨詢
售后
建站咨詢
新聞中心
近日的游戲圈只有一個主題——「吃雞」。長期被 MOBA 多人在線戰(zhàn)術(shù)競技游戲，如《英雄聯(lián)盟》、《王者榮耀》游戲把持的國內(nèi)游戲市場在“吃雞”的刺激下出現(xiàn)了松動。作為技術(shù)人讓我們一起看看目前游戲服務(wù)器的演化進程。
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名申請、雅安服務(wù)器托管、營銷軟件、網(wǎng)站建設(shè)、無極網(wǎng)站維護、網(wǎng)站推廣。
本文閱讀預(yù)計需要 10 分鐘，主要技術(shù)點如下：
- 游戲服務(wù)器特征。
- 短連接游戲服務(wù)器架構(gòu)。
- 長連接游戲服務(wù)器架構(gòu)。
- 分區(qū)分服服務(wù)器架構(gòu)。
- MMOARPG 服務(wù)器架構(gòu)。
- 房間服務(wù)器架構(gòu)。
游戲服務(wù)器特征
游戲服務(wù)器端，是一個會長期運行的程序，并且它還要服務(wù)于多個不定時，不定點的網(wǎng)絡(luò)請求，所以這類軟件的特點是要非常關(guān)注穩(wěn)定性和性能。
這類程序如果需要多個協(xié)作來提高承載能力，則還要關(guān)注部署和擴容的便利性；同時，還需要考慮如何實現(xiàn)某種程度的容災(zāi)需求。由于多進程協(xié)同工作，也帶來了開發(fā)的復(fù)雜度，這也是需要關(guān)注的問題。
功能約束，是架構(gòu)設(shè)計的決定性因素?；谟螒蝾I(lǐng)域的功能特征，服務(wù)器端系統(tǒng)有以下幾個特殊的需求：
- 對于游戲數(shù)據(jù)和玩家數(shù)據(jù)的存儲。
- 對玩家數(shù)據(jù)進行數(shù)據(jù)廣播和同步。
- 把一部分游戲邏輯在服務(wù)器上運算，做好驗證，防止外掛。
針對以上的需求特征，在服務(wù)器端，我們往往會關(guān)注對電腦內(nèi)存和 CPU 的使用，以求在特定業(yè)務(wù)代碼下，能盡量滿足承載量和響應(yīng)延遲的需求。
最基本的做法就是“空間換時間”，用各種緩存的方式求得 CPU 和內(nèi)存空間上的平衡。
在 CPU 和內(nèi)存之上，是另外一個約束因素：網(wǎng)卡。網(wǎng)絡(luò)帶寬直接限制了服務(wù)器的處理能力，所以游戲服務(wù)器架構(gòu)也必定要考慮這個因素。
游戲服務(wù)器架構(gòu)要素
對于游戲服務(wù)端架構(gòu)，最重要的三個部分就是，如何使用 CPU、內(nèi)存、網(wǎng)卡的設(shè)計。
內(nèi)存架構(gòu)：主要決定服務(wù)器如何使用內(nèi)存，以***化利用服務(wù)器端內(nèi)存來提高承載量，降低服務(wù)延遲。
邏輯架構(gòu)：設(shè)計如何使用進程、線程、協(xié)程這些進行 CPU 調(diào)度的方案。選擇同步、異步等不同的編程模型，以提高服務(wù)器的穩(wěn)定性和承載量。
可以分區(qū)分服，也可以采用世界服的方式，將相同功能模塊劃分到不同的服務(wù)器來處理。
通信模式：決定使用何種方式通訊?；谟螒蝾愋筒煌捎貌煌耐ㄐ拍Ｊ剑热?http、tcp、udp 等。
服務(wù)器演化進程
卡牌等休閑游戲弱交互游戲
服務(wù)器基于游戲類型不同，所采用的架構(gòu)也有所不同，我們先講一下簡單的模型，采用 http 通信模式架構(gòu)的服務(wù)器：
這種服務(wù)器架構(gòu)和我們常用的 Web 服務(wù)器架構(gòu)差不多，也是采用 Nginx 負載集群支持服務(wù)器的水平擴展，memcache 做緩存。
唯一不同的點在于通信層需要對協(xié)議再加工和加密，一般每個公司都有自己的一套基于 http 的協(xié)議層框架，很少采用開源框架。
長連接游戲服務(wù)器
長連接游戲和弱聯(lián)網(wǎng)游戲不同的地方在于，長連接中，玩家是有狀態(tài)的，服務(wù)器可以時時和 client 交互；數(shù)據(jù)的傳送，不像弱聯(lián)網(wǎng)一般每次都需要重新創(chuàng)建一個連接，消息傳送的頻率以及速度上都快于弱聯(lián)網(wǎng)游戲。
***代網(wǎng)游服務(wù)器（單線程無阻塞）
最早的游戲服務(wù)器是 1978 年，英國著名的財經(jīng)學(xué)校 University of Essex 的學(xué)生 Roy Trubshaw 編寫了世界上***個 MUD 程序，叫做《MUD1》。
《MUD1》程序的源代碼在 ARPANET 共享之后，在全世界廣泛流行起來。不斷完善 MUD1 的基礎(chǔ)上產(chǎn)生了開源的 MudOS（1991），成為眾多網(wǎng)游的鼻祖。
MUD1 是一款純文字的世界，沒有任何圖片，但是不同計算機前的玩家可以在游戲里共同冒險、交流。
與以往具有網(wǎng)絡(luò)聯(lián)機功能的游戲相比，MUD1 是***款真正意義上的實時多人交互的網(wǎng)絡(luò)游戲，它***的特色是能夠保證整個虛擬世界和玩家角色的持續(xù)發(fā)展。
無論是玩家退出后重新登錄還是服務(wù)器重啟，游戲中的場景、寶箱、怪物和謎題仍保持不變，玩家的角色也依然是上次的狀態(tài)。
MUDOS 使用單線程無阻塞套接字來服務(wù)所有玩家，所有玩家的請求都發(fā)到同一個線程去處理，主線程每隔 1 秒鐘更新一次所有對象（網(wǎng)絡(luò)收發(fā)，對象狀態(tài)，刷新地圖，刷新 NPC）。
用戶使用 Telnet 之類的客戶端用 TCP 協(xié)議連接到 MUDOS 上，使用純文字進行游戲，每條指令用回車進行分割。
這樣的系統(tǒng)在當(dāng)時每臺服務(wù)器承載過 4000 人同時游戲。從1991 年的 MUDOS 發(fā)布后，全球各地都在為它改進、擴充、推出新版本。
MUDOS 中游戲內(nèi)容通過 LPC 腳本進行定制，邏輯處理采用單線程 tick 輪詢，這也是***款服務(wù)端架構(gòu)模型，后來被應(yīng)用到不同游戲上。
后續(xù)很多游戲都是跟《UO》一樣，直接在 MUDOS 上進行二次開發(fā)，直到如今，一些回合制游戲，以及對運算量要求小的游戲，依然采用這種服務(wù)器架構(gòu)。
***代服務(wù)器架構(gòu)圖：
線程模型：
第二代網(wǎng)游服務(wù)器（分區(qū)分服）
2000 年左右，隨著圖形界面的出現(xiàn)，游戲更多的采用圖形界面與用戶交互。此時隨著在線人數(shù)的增加和游戲數(shù)據(jù)的增加，服務(wù)器變得不堪重負。于是，服務(wù)器就有了分服模型。
分服模型結(jié)構(gòu)如下：
分服模型是游戲服務(wù)器中最典型，也是歷史最悠久的模型。在早期服務(wù)器的承載量達到上限的時候，游戲開發(fā)者就通過架設(shè)更多的服務(wù)器來解決。
這樣提供了很多個游戲的“平行世界”，讓游戲中的人與人之間的比較，產(chǎn)生了更多的空間。
其特征是游戲服務(wù)器是一個個單獨的世界，每個服務(wù)器的帳號是獨立的，每臺服務(wù)器用戶的狀態(tài)都是不一樣的，一個服就是一個世界，大家各不牽扯。
后來游戲玩家呼吁要跨服打架，于是出現(xiàn)了跨服戰(zhàn)，再加上隨著游戲的運行，單個服務(wù)器的游戲活躍玩家越來越少。
所以后期就有了服務(wù)器的合并以及遷移，慢慢隨著服務(wù)器的開放、合并形成了一套成熟的運營手段。
目前多數(shù)游戲還采用分服的結(jié)構(gòu)來架設(shè)服務(wù)器，比如多數(shù)頁游。
線程調(diào)度
分服雖然可以解決服務(wù)器擴展的瓶頸，但單臺服務(wù)器在以前單線程的方式來運行，沒辦法充分利用服務(wù)器資源。
于是又演變出了以下 2 種線程模型：
- 異步-多線程，基于每個場景（或者房間），分配一個線程。每個場景的玩家同屬于一個線程。游戲的場景是固定的，不會很多，如此保證線程的數(shù)量不會不斷增大。
每個場景線程，同樣采用 tick 輪詢的方式，來定時更新該場景內(nèi)的（對象狀態(tài)，刷新地圖，刷新 NPC）數(shù)據(jù)狀態(tài)。玩家如果跨場景的話，就采用投遞和通知的方式，告知兩個場景線程，以此更新兩個場景的玩家數(shù)據(jù)。
- 多進程，由于單進程架構(gòu)下，總會存在承載量的極限，越是復(fù)雜的游戲，其單進程承載量就越低，因此一定要突破進程的限制，才能支撐更復(fù)雜的游戲。多進程系統(tǒng)的其他一些好處：能夠利用上多核 CPU 能力、更容易進行容災(zāi)處理。
多進程系統(tǒng)比較經(jīng)典的模型是“三層架構(gòu)”，比如基于之前的場景線程再做改進，把網(wǎng)絡(luò)部分和數(shù)據(jù)庫部分分離為單獨的進程來處理，邏輯進程專心處理邏輯任務(wù)，不合 IO 打交道，網(wǎng)絡(luò) IO 和磁盤 IO 分別交由網(wǎng)路進程和 DB 進程處理。
第三代網(wǎng)游服務(wù)器
之前的網(wǎng)游服務(wù)器都是分區(qū)分服，玩家都被劃分在不同的服務(wù)器上，每臺服務(wù)器運行的邏輯相同，玩家不能在不同服務(wù)器之間交互。
想要更多的玩家在同一世界，保持玩家的活躍度，于是就有了世界服模型了。
世界服類型也有以下 3 種演化：
一類型（三層架構(gòu)）
網(wǎng)關(guān)部分分離成單端的 gate 服務(wù)器，DB 部分分離為 DB 服務(wù)器，把網(wǎng)絡(luò)功能單獨提取出來，讓用戶統(tǒng)一去連接一個網(wǎng)關(guān)服務(wù)器，再用網(wǎng)關(guān)服務(wù)器轉(zhuǎn)發(fā)數(shù)據(jù)到后端游戲服務(wù)器。
而游戲服務(wù)器之間的數(shù)據(jù)交換也統(tǒng)一連接到網(wǎng)關(guān)進行交換。所有有 DB 交互的，都連接到 DB 服務(wù)器來代理處理。
二類型（cluster）
有了一類型的經(jīng)驗，后續(xù)肯定是拆分的越細，性能越好，就類似現(xiàn)在的微服務(wù)，每個相同的模塊分布到一臺服務(wù)器處理，多組服務(wù)器集群共同組成一個游戲服務(wù)端。
一般地，我們可以將一個組內(nèi)的服務(wù)器簡單地分成兩類：場景相關(guān)的（如：行走、戰(zhàn)斗等）以及場景不相關(guān)的（如：公會聊天、不受區(qū)域限制的貿(mào)易等）。
經(jīng)?？梢砸姷降囊环N方案是：gate 服務(wù)器、場景服務(wù)器、非場景服務(wù)器、聊天管理器、AI 服務(wù)器以及數(shù)據(jù)庫代理服務(wù)器。如下模型所示：
以上圖為例，我們簡單的講下服務(wù)器的三種類型功能：
- 場景服務(wù)器：它負責(zé)完成主要的游戲邏輯，這些邏輯包括：角色在游戲場景中的進入與退出、角色的行走與跑動、角色戰(zhàn)斗（包括打怪）、任務(wù)的認領(lǐng)等。
場景服務(wù)器設(shè)計的好壞是整個游戲世界服務(wù)器性能差異的主要體現(xiàn)，它的設(shè)計難度不僅僅在于通信模型方面，更主要的是整個服務(wù)器的體系架構(gòu)和同步機制的設(shè)計。
- 非場景服務(wù)器：它主要負責(zé)完成與游戲場景不相關(guān)的游戲邏輯，這些邏輯不依靠游戲的地圖系統(tǒng)也能正常進行。
比如公會聊天或世界聊天，之所以把它從場景服務(wù)器中獨立出來，是為了節(jié)省場景服務(wù)器的 CPU 和帶寬資源，讓場景服務(wù)器能夠盡可能快地處理那些對游戲流暢性影響較大的游戲邏輯。
- 網(wǎng)關(guān)服務(wù)器：在類型一種的架構(gòu)中，玩家在多個地圖跳轉(zhuǎn)或者場景切換的時候采用跳轉(zhuǎn)的模式，以此跳轉(zhuǎn)不同的服務(wù)器。
還有一種方式是把這些服務(wù)器的節(jié)點都通過網(wǎng)關(guān)服務(wù)器管理，玩家和網(wǎng)關(guān)服務(wù)器交互，每個場景或者服務(wù)器切換的時候，也由網(wǎng)關(guān)服務(wù)器統(tǒng)一來交換數(shù)據(jù)，如此玩家操作會比較流暢。
通過這種類型服務(wù)器架構(gòu)，因為壓力分散了，性能會有明顯提升，負載也更大了，包括目前一些大型的 MMORPG 游戲就是采用此架構(gòu)。
不過每增加一級服務(wù)器，狀態(tài)機復(fù)雜度可能會翻倍，導(dǎo)致研發(fā)和找 Bug 的成本上升，這個對開發(fā)組挑戰(zhàn)比較大，沒有經(jīng)驗，很容易出錯。
三類型（無縫地圖）
魔獸世界的中無縫地圖，想必大家印象深刻,整個世界的移動沒有像以往的游戲一樣，在切換場景的時候需要 loading 等待，而是直接行走過去，體驗流暢。
現(xiàn)在采用無縫地圖的游戲大地圖多數(shù)采用的是 9 宮格的樣式來處理，由于地圖沒有魔獸世界那么大，所以采用單臺服務(wù)器多進程處理即可。
不過類似魔獸世界這種大世界地圖，必須考慮 2 個問題：
- 多個地圖節(jié)點如何無縫拼接，特別是當(dāng)?shù)貓D節(jié)點比較多的時候，如何保證無縫拼接。
- 如何支持動態(tài)分布，有些區(qū)域人多，有些區(qū)域人少，保證服務(wù)器資源利用的***化。
為了解決這個問題，比較以往按照地圖來切割游戲而言，無縫世界并不存在一塊地圖上面的人有且只由一臺服務(wù)器處理了。
此時需要一組服務(wù)器來處理，每臺 Node 服務(wù)器用來管理一塊地圖區(qū)域，由 NodeMaster（NM）來為他們提供總體管理，更高層次的 World 則提供大陸級別的管理服務(wù)。
一個 Node 所負責(zé)的區(qū)域，地理上沒必要連接在一起，可以統(tǒng)一交給一個 Node 去管理，而這些區(qū)塊在地理上并沒有聯(lián)系在一起的必要性。
一個 Node 到底管理哪些區(qū)塊，可以根據(jù)游戲?qū)崟r運行的負載情況，定時維護的時候進行更改 NodeMaster 上面的配置。
對象的無縫遷移
玩家 A、B、C 分別代表 3 種不同的狀態(tài)，以及不同的遷移方式。
我們分別來看：
- 玩家 A：玩家 A 在 Node1 地圖服務(wù)器上，由 Node1 控制，如果遷移到 node2 上，需要將其數(shù)據(jù)復(fù)制到 Node2 上，然后從 Node1 移除。
- 玩家 B：玩家 B 在 Node1 和 Node2 中間，此時由 Node1 和 Node2 維護，若是從 Node1 行走到 Node2 的過程中，會向 1 請求，同時向 2 請求，待全部移動過去了再移除。
- 玩家 C：玩家 C 在 Node2 地圖服務(wù)器上，由 Node2 控制，如果遷移到 Node1 上，需要將其數(shù)據(jù)復(fù)制到 Node1 上，然后從 Node2 移除。
具體魔獸世界服務(wù)器的分析，篇幅過多，我們以后再聊。
房間服務(wù)器（游戲大廳）
房間類玩法和 MMORPG 有很大的不同，在于其在線廣播單元的不確定性和廣播數(shù)量很小。而且需要匹配一臺房間服務(wù)器讓少數(shù)人進入一個服務(wù)器。
這一類游戲最重要的是其“游戲大廳”的承載量，每個“游戲房間”受邏輯所限，需要維持和廣播的玩家數(shù)據(jù)是有限的，但是“游戲大廳”需要維持相當(dāng)高的在線用戶數(shù)。
所以一般來說，這種游戲還是需要做“分服”的。典型的游戲就是《英雄聯(lián)盟》這一類游戲了。
而“游戲大廳”里面最有挑戰(zhàn)性的任務(wù)，就是“自動匹配”玩家進入一個“游戲房間”，這需要對所有在線玩家做搜索和過濾。
玩家先登錄“大廳服務(wù)器”，然后選擇組隊游戲的功能，服務(wù)器會通知參與的所有游戲客戶端，新開一條連接到房間服務(wù)器上，這樣所有參與的用戶就能在房間服務(wù)器里進行游戲交互了。
以上就是目前游戲服務(wù)器的演化進程，由于所涉及的內(nèi)容太多，關(guān)于服務(wù)器的相關(guān)網(wǎng)絡(luò) IO 以及內(nèi)存模型都沒有介紹，以后有機會再具體講講這一部分。
wier，樂元素 leader 軟件工程師，從 2010 年起從事游戲開發(fā)，經(jīng)歷過頁游和手游兩個游戲發(fā)展期，期間曾帶領(lǐng)團隊開發(fā)過山寨機上***款偷菜游戲，如今專注于二次元游戲領(lǐng)域及服務(wù)器技術(shù)研究，運維了一個游戲公眾號（大碼侯I(lǐng)D：cool_wier），期待用自己的一點努力和貢獻，推進游戲社區(qū)的前進。
當(dāng)前名稱：“爆款”游戲吃雞是如何誕生的？聊聊游戲服務(wù)器的架構(gòu)演進
轉(zhuǎn)載源于：http://m.5511xx.com/article/codogjj.html
