服務(wù)器常用基本框架

1、轉(zhuǎn)自知乎類型1：卡牌、跑酷等弱交互服務(wù)端卡牌跑酷類因?yàn)榻换ト酰婕液屯婕抑g不需要實(shí)時(shí)面對(duì)面PK，打一下對(duì)方的離線數(shù)據(jù)，計(jì)算下排行榜，買賣下道具即可，所以實(shí)現(xiàn)往往使用簡(jiǎn)單的 HTTP服務(wù)器：<img src=" data-rawwidth="438" data-rawheight="186" class="origin_image zh-lightbox-thumb" width="438" data-original=" DH），服務(wù)器根據(jù)客戶端uid，當(dāng)前時(shí)間戳還有服務(wù)端私鑰，計(jì)算哈希

2、得到的加密 key 并發(fā)送給客戶端。之后雙方都用 HTTP通信，并用那個(gè)key進(jìn)行RC4加密。客戶端收到key和時(shí)間戳后保存在內(nèi)存，用于之后通信，服務(wù)端不需要保存 key，因?yàn)槊看味伎梢愿鶕?jù)客戶端傳上來的 uid 和 時(shí)間戳 以及服務(wù)端自己的私鑰計(jì)算得到。用模仿 TLS的行為，來保證多次 HTTP請(qǐng)求間的客戶端身份，并通過時(shí)間戳保證同一人兩次登錄密鑰不同。登錄時(shí)可以使用非對(duì)稱加密（RSA, DH），服務(wù)器根據(jù)客戶端uid，當(dāng)前時(shí)間戳還有服務(wù)端私鑰，計(jì)算哈希得到的加密 key 并發(fā)送給客戶端。之后雙方都用 HTTP通信，并用那個(gè)key進(jìn)行RC4加密。客戶端收到key和時(shí)間戳后保存在內(nèi)存，用于之后

3、通信，服務(wù)端不需要保存 key，因?yàn)槊看味伎梢愿鶕?jù)客戶端傳上來的 uid 和 時(shí)間戳 以及服務(wù)端自己的私鑰計(jì)算得到。用模仿 TLS的行為，來保證多次 HTTP請(qǐng)求間的客戶端身份，并通過時(shí)間戳保證同一人兩次登錄密鑰不同。每局開始時(shí)，訪問一下，請(qǐng)求一下關(guān)卡數(shù)據(jù)，玩完了又提交一下，驗(yàn)算一下是否合法，獲得什么獎(jiǎng)勵(lì)，數(shù)據(jù)庫(kù)用單臺(tái) MySQL或者 MongoDB即可，后端的 Redis做緩存（可選）。如果要實(shí)現(xiàn)通知，那么讓客戶端定時(shí)15秒輪詢一下服務(wù)器，如果有消息就取下來，如果沒消息可以逐步放長(zhǎng)輪詢時(shí)間，比如30秒；如果有消息，就縮短輪詢時(shí)間到10秒，5秒，即便兩人聊天，延遲也能自適應(yīng)。此類服務(wù)器用來實(shí)現(xiàn)

4、一款三國(guó)類策略或者卡牌及酷跑的游戲已經(jīng)綽綽有余，這類游戲因?yàn)檫壿嫼?jiǎn)單，玩家之間交互不強(qiáng)，使用 HTTP來開發(fā)的話，開發(fā)速度快，調(diào)試只需要一個(gè)瀏覽器就可以把邏輯調(diào)試清楚了。類型2：第一代游戲服務(wù)器 19781978年，英國(guó)著名的財(cái)經(jīng)學(xué)校University of Essex的學(xué)生 Roy Trubshaw編寫了世界上第一個(gè)MUD程序MUD1，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括國(guó)外的玩家。MUD1程序的源代碼在 ARPANET共享之后出現(xiàn)了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的 MUD1的基礎(chǔ)上產(chǎn)生了開源

5、的 MudOS（1991），成為眾多網(wǎng)游的鼻祖：<img src=" data-rawwidth="368" data-rawheight="225" class="content_image" width="368">MUDOS采用 C語言開發(fā)，因?yàn)橥婕液屯婕抑g有比較強(qiáng)的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務(wù)所有玩家，所有玩家的請(qǐng)求都發(fā)到同一個(gè)線程去處理，主線程每隔1秒鐘更新一次所有對(duì)象（網(wǎng)絡(luò)收發(fā)，更新對(duì)象狀態(tài)機(jī)，處理超時(shí)，刷新地圖，刷新NPC）。MUDOS采用

6、C語言開發(fā)，因?yàn)橥婕液屯婕抑g有比較強(qiáng)的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務(wù)所有玩家，所有玩家的請(qǐng)求都發(fā)到同一個(gè)線程去處理，主線程每隔1秒鐘更新一次所有對(duì)象（網(wǎng)絡(luò)收發(fā)，更新對(duì)象狀態(tài)機(jī)，處理超時(shí)，刷新地圖，刷新NPC）。游戲世界采用房間的形式組織起來，每個(gè)房間有東南西北四個(gè)方向可以移動(dòng)到下一個(gè)房間，由于歐美最早的網(wǎng)游都是地牢迷宮形式的，因此場(chǎng)景的基本單位被成為 “房間”。MUDOS使用一門稱為L(zhǎng)PC的腳本語言來描述整個(gè)世界（包括房間拓?fù)洌渲?，NPC，以及各種劇情）。游戲里面的高級(jí)玩家（巫師），可以不斷的通過修改腳本來為游戲添加房間以及增加劇情。早年 MUD1上線時(shí)只

7、有17個(gè)房間，Roy Trubshaw畢業(yè)以后交給他的師弟 Richard Battle，在 Richard Battle手上，不斷的添加各種玩法到一百多個(gè)房間，終于讓 MUD發(fā)揚(yáng)光大。用戶使用 Telnet之類的客戶端用 Tcp協(xié)議連接到 MUDOS上，使用純文字進(jìn)行游戲，每條指令用回車進(jìn)行分割。比如 1995年國(guó)內(nèi)第一款 MUD游戲俠客行，你敲入："go east"，游戲就會(huì)提示你：“后花園 - 這里是歸云莊的后花園，種滿了花草，幾個(gè)莊丁正在澆花。此地乃是含羞草生長(zhǎng)之地。這里唯一的出口是 north。這里有：花待 阿牧（A mu），還有二位莊?。╖huang Ding）

8、”，然后你繼續(xù)用文字操作，查看阿牧的信息：“l(fā)ook a mu”，系統(tǒng)提示：“花待 阿牧（A mu）他是陸乘風(fēng)的弟子，受命在此看管含羞草。他看起來三十多歲，生得眉清目秀，端正大方，一表人才。他的武藝看上去【不是很高】，出手似乎【極輕】”。然后你可以選擇擊敗他獲得含羞草，但是你吃了含羞草卻又可能會(huì)中毒死亡。在早期網(wǎng)上資源貧乏的時(shí)候，這樣的游戲有很強(qiáng)的代入感。用戶數(shù)據(jù)保存在文件中，每個(gè)用戶登錄時(shí)，從文本文件里把用戶的數(shù)據(jù)全部加載進(jìn)來，操作全部在內(nèi)存里面進(jìn)行，無需馬上刷回磁盤。用戶退出了，或者每隔5分鐘檢查到數(shù)據(jù)改動(dòng)了，都會(huì)保存會(huì)磁盤。這樣的系統(tǒng)在當(dāng)時(shí)每臺(tái)服務(wù)器承載個(gè)4000人同時(shí)游戲，不是特別大的

9、問題。從1991年的 MUDOS發(fā)布后，全球各地都在為他改進(jìn)，擴(kuò)充，退出新版本，隨著 Windows圖形機(jī)能的增強(qiáng)。1997游戲UO在 MUDOS的基礎(chǔ)上為角色增加的x,y坐標(biāo)，為每個(gè)房間增加了地圖，并且為每個(gè)角色增加了動(dòng)畫，形成了第一代的圖形網(wǎng)絡(luò)游戲。因?yàn)橛螒騼?nèi)容基本可以通過 LPC腳本進(jìn)行定制，所以MUDOS也成為名副其實(shí)的第一款服務(wù)端引擎，引擎一次性開發(fā)出來，然后制作不同游戲內(nèi)容。后續(xù)國(guó)內(nèi)的萬王之王等游戲，很多都是跟UO一樣，直接在 MUDOS上進(jìn)行二次開發(fā)，加入房間的地圖還有角色的坐標(biāo)等要素，該架構(gòu)一直為國(guó)內(nèi)的第一代 MMORPG提供了穩(wěn)固的支持，直到 2003年，還有游戲基于 MUD

10、OS開發(fā)。雖然后面圖形化增加了很多東西，但是這些MMORPG后端的本質(zhì)還是 MUDOS。隨著游戲內(nèi)容的越來越復(fù)雜，架構(gòu)變得越來越吃不消了，各種負(fù)載問題慢慢浮上水面，于是有了我們的第二代游戲服務(wù)器。類型3：第二代游戲服務(wù)器 20032000年后，網(wǎng)游已經(jīng)脫離最初的文字MUD，進(jìn)入全面圖形化年代。最先承受不住的其實(shí)是很多小文件，用戶上下線，頻繁的讀取寫入用戶數(shù)據(jù)，導(dǎo)致負(fù)載越來越大。隨著在線人數(shù)的增加和游戲數(shù)據(jù)的增加，服務(wù)器變得不抗重負(fù)。同時(shí)早期 EXT磁盤分區(qū)比較脆弱，稍微停電，容易發(fā)生大面積數(shù)據(jù)丟失。因此第一步就是拆分文件存儲(chǔ)到數(shù)據(jù)庫(kù)去。<img src=" data-rawwi

11、dth="439" data-rawheight="159" class="origin_image zh-lightbox-thumb" width="439" data-original="此時(shí)游戲服務(wù)端已經(jīng)脫離陳舊的 MUDOS體系，各個(gè)公司在參考 MUDOS結(jié)構(gòu)的情況下，開始自己用 C在重新開發(fā)自己的游戲服務(wù)端。并且腳本也拋棄了 LPC，采用擴(kuò)展性更好的 Python或者 Lua來代替。由于主邏輯使用單線程模型，隨著游戲內(nèi)容的增加，傳統(tǒng)單服務(wù)器的結(jié)構(gòu)進(jìn)一步成為瓶頸。于是有人開始拆分游戲世界，變?yōu)橄?/p>

12、面的模型：<img src=" data-rawwidth="404" data-rawheight="163" class="content_image" width="404">游戲服務(wù)器壓力拆分后得意緩解，但是兩臺(tái)游戲服務(wù)器同時(shí)訪問數(shù)據(jù)庫(kù)，大量重復(fù)訪問，大量數(shù)據(jù)交換，使得數(shù)據(jù)庫(kù)成為下一個(gè)瓶頸。于是形成了數(shù)據(jù)庫(kù)前端代理（DB Proxy），游戲服務(wù)器不直接訪問數(shù)據(jù)庫(kù)而是訪問代理，再有代理訪問數(shù)據(jù)庫(kù)，同時(shí)提供內(nèi)存級(jí)別的cache。早年 MySQL4之前沒有提供存儲(chǔ)過程，這個(gè)前端代理一般和 M

13、ySQL跑在同一臺(tái)上，它轉(zhuǎn)化游戲服務(wù)器發(fā)過來的高級(jí)數(shù)據(jù)操作指令，拆分成具體的數(shù)據(jù)庫(kù)操作，一定程度上代替了存儲(chǔ)過程：游戲服務(wù)器壓力拆分后得意緩解，但是兩臺(tái)游戲服務(wù)器同時(shí)訪問數(shù)據(jù)庫(kù)，大量重復(fù)訪問，大量數(shù)據(jù)交換，使得數(shù)據(jù)庫(kù)成為下一個(gè)瓶頸。于是形成了數(shù)據(jù)庫(kù)前端代理（DB Proxy），游戲服務(wù)器不直接訪問數(shù)據(jù)庫(kù)而是訪問代理，再有代理訪問數(shù)據(jù)庫(kù)，同時(shí)提供內(nèi)存級(jí)別的cache。早年 MySQL4之前沒有提供存儲(chǔ)過程，這個(gè)前端代理一般和 MySQL跑在同一臺(tái)上，它轉(zhuǎn)化游戲服務(wù)器發(fā)過來的高級(jí)數(shù)據(jù)操作指令，拆分成具體的數(shù)據(jù)庫(kù)操作，一定程度上代替了存儲(chǔ)過程：<img src=" data-raww

14、idth="466" data-rawheight="162" class="origin_image zh-lightbox-thumb" width="466" data-original=" Gate（有的地方叫 Session，有的地方叫 LinkSvr之類的，名字不同而已）：但是這樣的結(jié)構(gòu)并沒有持續(xù)太長(zhǎng)時(shí)間，因?yàn)橥婕仪袚Q場(chǎng)景經(jīng)常要切換連接，中間的狀態(tài)容易錯(cuò)亂。而且游戲服務(wù)器多了以后，相互之間數(shù)據(jù)交互又會(huì)變得比較麻煩，于是人們拆分了網(wǎng)絡(luò)功能，獨(dú)立出一個(gè)網(wǎng)關(guān)服務(wù) Gate（有的地方叫 Session

15、，有的地方叫 LinkSvr之類的，名字不同而已）：<img src=" data-rawwidth="486" data-rawheight="289" class="origin_image zh-lightbox-thumb" width="486" data-original="人都是有慣性的，按照先前的經(jīng)驗(yàn)，似乎把 MUDOS拆分的越開性能越好。于是大家繼續(xù)想，網(wǎng)關(guān)可以拆分呀，基礎(chǔ)服務(wù)如聊天交易，可以拆分呀，還可以提供web接口，數(shù)據(jù)庫(kù)可以拆分呀，于是有了下面的模型：<im

16、g src=" data-rawwidth="480" data-rawheight="266" class="origin_image zh-lightbox-thumb" width="480" data-original=" MMORPG。但是有兩個(gè)挑戰(zhàn)：每增加一級(jí)服務(wù)器，狀態(tài)機(jī)復(fù)雜度可能會(huì)翻倍，導(dǎo)致研發(fā)和找bug的成本上升；并且對(duì)開發(fā)組挑戰(zhàn)比較大，一旦項(xiàng)目時(shí)間吃緊，開發(fā)人員經(jīng)驗(yàn)不足，很容易弄掛。這樣的模型好用么？確實(shí)有成功游戲使用類似這樣的架構(gòu)，并且發(fā)揮了它的性能優(yōu)勢(shì)，比如一些大型 MM

17、ORPG。但是有兩個(gè)挑戰(zhàn)：每增加一級(jí)服務(wù)器，狀態(tài)機(jī)復(fù)雜度可能會(huì)翻倍，導(dǎo)致研發(fā)和找bug的成本上升；并且對(duì)開發(fā)組挑戰(zhàn)比較大，一旦項(xiàng)目時(shí)間吃緊，開發(fā)人員經(jīng)驗(yàn)不足，很容易弄掛。比如我見過某上海一線游戲公司的一個(gè) RPG上來就要上這樣的架構(gòu)，我看了下他們團(tuán)隊(duì)成員的經(jīng)驗(yàn)，問了下他們的上線日期，勸他們用前面稍微簡(jiǎn)單一點(diǎn)的模型。人家自信得很，認(rèn)為有成功項(xiàng)目是這么做的，他們也要這么做，自己很想實(shí)現(xiàn)一套。于是他們義無反顧的開始編碼，項(xiàng)目做了一年多，然后，就沒有然后了?，F(xiàn)今在游戲成功率不高的情況下，一開始上一套比較復(fù)雜的架構(gòu)需要考慮投資回報(bào)率，比如你的游戲上線半年內(nèi) PCU會(huì)去到多少？如果一個(gè) APRG游戲，每組

18、服務(wù)器5千人都到不了的話，那么選擇一套更為貼近實(shí)際情況的結(jié)構(gòu)更為經(jīng)濟(jì)。即使后面你的項(xiàng)目真的超過5千人朝著1萬人目標(biāo)奔的話，相信那個(gè)時(shí)候你的項(xiàng)目已經(jīng)掙大錢了 ，你數(shù)著錢加著班去逐步迭代，一次次拆分它，相信心里也是樂開花的。上面這些類型基本都是從拆分 MUDOS開始，將 MUDOS中的各個(gè)部件從單機(jī)一步步拆成分布式。雖然今天任然很多新項(xiàng)目在用上面某一種類似的結(jié)構(gòu)，或者自己又做了其他熱點(diǎn)模塊的拆分。因?yàn)樗麄儽举|(zhì)上都是對(duì) MUDOS的分解，故將他們歸納為第二代游戲服務(wù)器。類型4：第三代游戲服務(wù)器 2007從魔獸世界開始無縫世界地圖已經(jīng)深入人心，比較以往游戲玩家走個(gè)幾步還需要切換場(chǎng)景，每次切換就要等待

19、LOADING個(gè)幾十秒是一件十分破壞游戲體驗(yàn)的事情。于是對(duì)于 2005年以后的大型 MMORPG來說，無縫地圖已成為一個(gè)標(biāo)準(zhǔn)配置。比較以往按照地圖來切割游戲而言，無縫世界并不存在一塊地圖上面的人有且只由一臺(tái)服務(wù)器處理了：<img src=" data-rawwidth="418" data-rawheight="185" class="content_image" width="418">每臺(tái) Node服務(wù)器用來管理一塊地圖區(qū)域，由 NodeMaster（NM）來為他們提供總體管理。更高層次的

20、 World則提供大陸級(jí)別的管理服務(wù)。這里省略若干細(xì)節(jié)服務(wù)器，比如傳統(tǒng)數(shù)據(jù)庫(kù)前端，登錄服務(wù)器，日志和監(jiān)控等，統(tǒng)統(tǒng)用 ADMIN概括。在這樣的結(jié)構(gòu)下，玩家從一塊區(qū)域走向另外一塊區(qū)域需要簡(jiǎn)單處理一下：<img src=" data-rawwidth="388" data-rawheight="290" class="content_image" width="388">玩家1完全由節(jié)點(diǎn)A控制，玩家3完全由節(jié)點(diǎn)B控制。而處在兩個(gè)節(jié)點(diǎn)邊緣的2號(hào)玩家，則同時(shí)由A和B提供服務(wù)。玩家2從A移動(dòng)到B的過程中，

21、會(huì)同時(shí)向A請(qǐng)求左邊的情況，并向B請(qǐng)求右邊的情況。但是此時(shí)玩家2還是屬于A管理。直到玩家2徹底離開AB邊界很遠(yuǎn)，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區(qū)域，交由不同的 Node去管理。玩家1完全由節(jié)點(diǎn)A控制，玩家3完全由節(jié)點(diǎn)B控制。而處在兩個(gè)節(jié)點(diǎn)邊緣的2號(hào)玩家，則同時(shí)由A和B提供服務(wù)。玩家2從A移動(dòng)到B的過程中，會(huì)同時(shí)向A請(qǐng)求左邊的情況，并向B請(qǐng)求右邊的情況。但是此時(shí)玩家2還是屬于A管理。直到玩家2徹底離開AB邊界很遠(yuǎn)，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區(qū)域，交由不同的 Node去管理。對(duì)于一個(gè) Node所負(fù)責(zé)的區(qū)域，地理上沒必要連接在一起，比如大陸的

22、四周邊緣部分和高山部分的區(qū)塊人比較少，可以統(tǒng)一交給一個(gè)Node去管理，而這些區(qū)塊在地理上并沒有聯(lián)系在一起的必要性。一個(gè) Node到底管理哪些區(qū)塊，可以根據(jù)游戲?qū)崟r(shí)運(yùn)行的負(fù)載情況，定時(shí)維護(hù)的時(shí)候進(jìn)行更改 NodeMaster 上面的配置。于是碰到第一個(gè)問題是很多 Node服務(wù)器需要和玩家進(jìn)行通信，需要問管理服務(wù)器特定UID為多少的玩家到底在哪臺(tái) Gate上，以前按場(chǎng)景切割的服務(wù)器這個(gè)問題不大，問了一次以后就可以緩存起來了，但是現(xiàn)在服務(wù)器種類增加不少，玩家又會(huì)飄來飄去，按UID查找玩家比較麻煩；另外一方面 GATE需要?jiǎng)討B(tài)根據(jù)坐標(biāo)計(jì)算和哪些 Node通信，導(dǎo)致邏輯越來越厚，于是把：“用戶對(duì)象”從負(fù)

23、責(zé)連接管理的 GATE中切割出來勢(shì)在必行于是有了下面的模型：<img src=" data-rawwidth="420" data-rawheight="275" class="content_image" width="420">網(wǎng)關(guān)服務(wù)器再次退回到精簡(jiǎn)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)功能，而用戶邏輯則由按照 UID劃分的 OBJ服務(wù)器來承擔(dān)，GATE是按照網(wǎng)絡(luò)接入時(shí)的負(fù)載來分布，而 OBJ則是按照資源的編號(hào)（UID）來分布，這樣和一個(gè)用戶通信直接根據(jù) UID計(jì)算出 OBJ服務(wù)器編號(hào)發(fā)送數(shù)據(jù)即可。而新獨(dú)立出來的

24、OBJ則提供了更多高層次的服務(wù)：網(wǎng)關(guān)服務(wù)器再次退回到精簡(jiǎn)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)功能，而用戶邏輯則由按照 UID劃分的 OBJ服務(wù)器來承擔(dān)，GATE是按照網(wǎng)絡(luò)接入時(shí)的負(fù)載來分布，而 OBJ則是按照資源的編號(hào)（UID）來分布，這樣和一個(gè)用戶通信直接根據(jù) UID計(jì)算出 OBJ服務(wù)器編號(hào)發(fā)送數(shù)據(jù)即可。而新獨(dú)立出來的 OBJ則提供了更多高層次的服務(wù)：· 對(duì)象移動(dòng)：管理具體玩家在不同的 Node所管轄的區(qū)域之間的移動(dòng)，并同需要的 Node進(jìn)行溝通。· 數(shù)據(jù)廣播：Node可以給每個(gè)用戶設(shè)置若干 TAG，然后通知 Object Master 按照TAG廣播。· 對(duì)象消息：通用消息推送，給某個(gè)

25、用戶發(fā)送數(shù)據(jù)，直接告訴 OBJ，不需要直接和 GATE打交道。· 好友聊天：角色之間聊天直接走 OBJ/OBJ MASTER。整個(gè)服務(wù)器主體分為三層以后，NODE專注場(chǎng)景，OBJ專注玩家對(duì)象，GATE專注網(wǎng)絡(luò)。這樣的模型在無縫場(chǎng)景服務(wù)器中得到廣泛的應(yīng)用。但是隨著時(shí)間的推移，負(fù)載問題也越來越明顯，做個(gè)活動(dòng)，遠(yuǎn)來不活躍的區(qū)域變得十分活躍，靠每周維護(hù)來調(diào)整還是比較笨重的，于是有了動(dòng)態(tài)負(fù)載均衡。動(dòng)態(tài)負(fù)載均衡有兩種方法，第一種是按照負(fù)載，由 Node Master 定時(shí)動(dòng)態(tài)移動(dòng)修改一下各個(gè) Node的邊界，而不同的玩家對(duì)象按照先前的方法從一臺(tái) Node上遷移到另外一臺(tái) Node上：<im

26、g src=" data-rawwidth="162" data-rawheight="181" class="content_image" width="162"> 圖11 動(dòng)態(tài)負(fù)載均衡 圖11 動(dòng)態(tài)負(fù)載均衡這樣 Node Master定時(shí)查找地圖上的熱點(diǎn)區(qū)域，計(jì)算新的場(chǎng)景切割方式，然后告訴其他服務(wù)器開始調(diào)整，具體處理方式還是和上面對(duì)象跨越邊界移動(dòng)的方法一樣。但是上面這種方式實(shí)現(xiàn)相對(duì)復(fù)雜一些，于是人們?cè)O(shè)計(jì)出了更為簡(jiǎn)單直接的一種新方法：<img src=" data-rawwidth

27、="251" data-rawheight="250" class="content_image" width="251"> 圖12 基于網(wǎng)格的動(dòng)態(tài)負(fù)載均衡 圖12 基于網(wǎng)格的動(dòng)態(tài)負(fù)載均衡還是將地圖按照標(biāo)準(zhǔn)尺寸均勻切割成靜態(tài)的網(wǎng)格，每個(gè)格子由一個(gè)具體的Node負(fù)責(zé)，但是根據(jù)負(fù)載情況，能夠?qū)崟r(shí)的遷移到其他 Node上。在遷移分為三個(gè)階段：準(zhǔn)備，切換，完成。三個(gè)狀態(tài)由Node Master負(fù)責(zé)維護(hù)。準(zhǔn)備階段新的 Node開始同步老 Node上面該網(wǎng)格的數(shù)據(jù)，完成后告訴NM；NM確認(rèn)OK后同時(shí)通知新舊 Node完成

28、切換。完成切換后，如果 Obj服務(wù)器還在和老的 Node進(jìn)行通信，老的 Node將會(huì)對(duì)它進(jìn)行糾正，得到糾正的 OBJ將修正自己的狀態(tài)，和新的 Node進(jìn)行通信。很多無縫動(dòng)態(tài)負(fù)載均衡的服務(wù)端宣稱自己支持無限的人數(shù)，但不意味著 MMORPG游戲的人數(shù)上限真的可以無限擴(kuò)充，因?yàn)檫@樣的體系會(huì)受制于網(wǎng)絡(luò)帶寬和客戶端性能。帶寬決定了同一個(gè)區(qū)域最大廣播上限，而客戶端性能決定了同一個(gè)屏幕到底可以繪制多少個(gè)角色。從無縫地圖引入了分布式對(duì)象模型開始，已經(jīng)完全脫離 MUDOS體系，成為一種新的服務(wù)端模型。又由于動(dòng)態(tài)負(fù)載均衡的引入，讓無縫服務(wù)器如虎添翼，容納著超過上一代游戲服務(wù)器數(shù)倍的人數(shù)上限，并提供了更好的游戲體驗(yàn)

29、，我們稱其為第三代游戲服務(wù)端架構(gòu)。網(wǎng)游以大型多人角色扮演為開端，RPG網(wǎng)游在相當(dāng)長(zhǎng)的時(shí)間里一度占據(jù)90%以上，使得基于 MMORPG的服務(wù)端架構(gòu)得到了蓬勃的發(fā)展，然而隨著玩家對(duì)RPG的疲憊，各種非MMORPG游戲如雨后春筍般的出現(xiàn)在人們眼前，受到市場(chǎng)的歡迎。類型5：戰(zhàn)網(wǎng)游戲服務(wù)器經(jīng)典戰(zhàn)網(wǎng)服務(wù)端和 RPG游戲有兩個(gè)區(qū)別：RPG是分區(qū)分服的，北京區(qū)的用戶和廣州區(qū)的用戶老死不相往來。而戰(zhàn)網(wǎng)，雖然每局游戲一般都是 8人以內(nèi)，但全國(guó)只有一套服務(wù)器，所有的玩家都可以在一起游戲，而玩家和玩家之使用 P2P的方式連接在一起，組成一局游戲：<img src=" data-rawwidth=&qu

30、ot;493" data-rawheight="352" class="origin_image zh-lightbox-thumb" width="493" data-original=" Match Making 服務(wù)器使用：創(chuàng)建、加入、自動(dòng)匹配、邀請(qǐng) 等方式組成一局游戲。服務(wù)器會(huì)選擇一個(gè)人做 Host，其他人 P2P連接到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引服務(wù)器，而由于 P2P聯(lián)通情況大概只有 75%，實(shí)在聯(lián)不通的玩家會(huì)通過 Forward進(jìn)行轉(zhuǎn)發(fā)。玩家通過 Match Making 服

31、務(wù)器使用：創(chuàng)建、加入、自動(dòng)匹配、邀請(qǐng) 等方式組成一局游戲。服務(wù)器會(huì)選擇一個(gè)人做 Host，其他人 P2P連接到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引服務(wù)器，而由于 P2P聯(lián)通情況大概只有 75%，實(shí)在聯(lián)不通的玩家會(huì)通過 Forward進(jìn)行轉(zhuǎn)發(fā)。大量的連接對(duì)戰(zhàn)，體育競(jìng)技游戲采用類似的結(jié)構(gòu)。P2P有網(wǎng)狀模型（所有玩家互相連接），和星狀模型（所有玩家連接一個(gè)主玩家）。復(fù)雜的游戲狀態(tài)在網(wǎng)狀模型下難以形成一致，因此星狀P2P模型經(jīng)受住了歷史的考驗(yàn)。除去游戲數(shù)據(jù)，支持語音的戰(zhàn)網(wǎng)系統(tǒng)也會(huì)將所有人的語音數(shù)據(jù)發(fā)送到做主的那個(gè)玩家機(jī)器上，通過混音去重再編碼的方式返回給所有用戶。戰(zhàn)網(wǎng)類游戲，以競(jìng)技、體育、動(dòng)作等類型