服務器常用基本框架轉自知乎

類型1：卡牌、跑酷等弱交互服務端

卡牌跑酷類因為交互弱，玩家和玩家之間不需要實時面對面PK，打一下對方的離線數據，計算下排行榜，買賣下道具即可，所以實現往往使用簡單的HTTP服務器：

<imgsrc="/b82310466e1546e288b02b8664afd843_b.jpg"data-rawwidth="438"data-rawheight="186"class="origin_imagezh-lightbox-thumb"width="438"data-original="/b82310466e1546e288b02b8664afd843_r.jpg">登錄時可以使用非對稱加密（RSA,DH），服務器根據客戶端uid，當前時間戳還有服務端私鑰，計算哈希得到的加密key并發(fā)送給客戶端。之后雙方都用HTTP通信，并用那個key進行RC4加密?？蛻舳耸盏絢ey和時間戳后保存在內存，用于之后通信，服務端不需要保存key，因為每次都可以根據客戶端傳上來的uid和時間戳以及服務端自己的私鑰計算得到。用模仿TLS的行為，來保證多次HTTP請求間的客戶端身份，并通過時間戳保證同一人兩次登錄密鑰不同。登錄時可以使用非對稱加密（RSA,DH），服務器根據客戶端uid，當前時間戳還有服務端私鑰，計算哈希得到的加密key并發(fā)送給客戶端。之后雙方都用HTTP通信，并用那個key進行RC4加密?？蛻舳耸盏絢ey和時間戳后保存在內存，用于之后通信，服務端不需要保存key，因為每次都可以根據客戶端傳上來的uid和時間戳以及服務端自己的私鑰計算得到。用模仿TLS的行為，來保證多次HTTP請求間的客戶端身份，并通過時間戳保證同一人兩次登錄密鑰不同。

每局開始時，訪問一下，請求一下關卡數據，玩完了又提交一下，驗算一下是否合法，獲得什么獎勵，數據庫用單臺MySQL或者MongoDB即可，后端的Redis做緩存（可選）。如果要實現通知，那么讓客戶端定時15秒輪詢一下服務器，如果有消息就取下來，如果沒消息可以逐步放長輪詢時間，比如30秒；如果有消息，就縮短輪詢時間到10秒，5秒，即便兩人聊天，延遲也能自適應。

此類服務器用來實現一款三國類策略或者卡牌及酷跑的游戲已經綽綽有余，這類游戲因為邏輯簡單，玩家之間交互不強，使用HTTP來開發(fā)的話，開發(fā)速度快，調試只需要一個瀏覽器就可以把邏輯調試清楚了。

類型2：第一代游戲服務器1978

1978年，英國著名的財經學校UniversityofEssex的學生RoyTrubshaw編寫了世界上第一個MUD程序《MUD1》，在UniversityofEssex于1980年接入ARPANET之后加入了不少外部的玩家，甚至包括國外的玩家?！禡UD1》程序的源代碼在ARPANET共享之后出現了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的MUD1的基礎上產生了開源的MudOS（1991），成為眾多網游的鼻祖：

<imgsrc="/b647b152f0352f239d9840c29b29e2c9_b.jpg"data-rawwidth="368"data-rawheight="225"class="content_image"width="368">MUDOS采用C語言開發(fā)，因為玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務所有玩家，所有玩家的請求都發(fā)到同一個線程去處理，主線程每隔1秒鐘更新一次所有對象（網絡收發(fā)，更新對象狀態(tài)機，處理超時，刷新地圖，刷新NPC）。MUDOS采用C語言開發(fā)，因為玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務所有玩家，所有玩家的請求都發(fā)到同一個線程去處理，主線程每隔1秒鐘更新一次所有對象（網絡收發(fā)，更新對象狀態(tài)機，處理超時，刷新地圖，刷新NPC）。

游戲世界采用房間的形式組織起來，每個房間有東南西北四個方向可以移動到下一個房間，由于歐美最早的網游都是地牢迷宮形式的，因此場景的基本單位被成為“房間”。MUDOS使用一門稱為LPC的腳本語言來描述整個世界（包括房間拓撲，配置，NPC，以及各種劇情）。游戲里面的高級玩家（巫師），可以不斷的通過修改腳本來為游戲添加房間以及增加劇情。早年MUD1上線時只有17個房間，RoyTrubshaw畢業(yè)以后交給他的師弟RichardBattle，在RichardBattle手上，不斷的添加各種玩法到一百多個房間，終于讓MUD發(fā)揚光大。

用戶使用Telnet之類的客戶端用Tcp協議連接到MUDOS上，使用純文字進行游戲，每條指令用回車進行分割。比如1995年國內第一款MUD游戲《俠客行》，你敲入："goeast"，游戲就會提示你：“后花園-這里是歸云莊的后花園，種滿了花草，幾個莊丁正在澆花。此地乃是含羞草生長之地。這里唯一的出口是north。這里有：花待阿牧（Amu），還有二位莊?。╖huangDing）”，然后你繼續(xù)用文字操作，查看阿牧的信息：“l(fā)ookamu”，系統提示：“花待阿牧（Amu）他是陸乘風的弟子，受命在此看管含羞草。他看起來三十多歲，生得眉清目秀，端正大方，一表人才。他的武藝看上去【不是很高】，出手似乎【極輕】”。然后你可以選擇擊敗他獲得含羞草，但是你吃了含羞草卻又可能會中毒死亡。在早期網上資源貧乏的時候，這樣的游戲有很強的代入感。

用戶數據保存在文件中，每個用戶登錄時，從文本文件里把用戶的數據全部加載進來，操作全部在內存里面進行，無需馬上刷回磁盤。用戶退出了，或者每隔5分鐘檢查到數據改動了，都會保存會磁盤。這樣的系統在當時每臺服務器承載個4000人同時游戲，不是特別大的問題。從1991年的MUDOS發(fā)布后，全球各地都在為他改進，擴充，退出新版本，隨著Windows圖形機能的增強。1997游戲《UO》在MUDOS的基礎上為角色增加的x,y坐標，為每個房間增加了地圖，并且為每個角色增加了動畫，形成了第一代的圖形網絡游戲。

因為游戲內容基本可以通過LPC腳本進行定制，所以MUDOS也成為名副其實的第一款服務端引擎，引擎一次性開發(fā)出來，然后制作不同游戲內容。后續(xù)國內的《萬王之王》等游戲，很多都是跟《UO》一樣，直接在MUDOS上進行二次開發(fā)，加入房間的地圖還有角色的坐標等要素，該架構一直為國內的第一代MMORPG提供了穩(wěn)固的支持，直到2003年，還有游戲基于MUDOS開發(fā)。

雖然后面圖形化增加了很多東西，但是這些MMORPG后端的本質還是MUDOS。隨著游戲內容的越來越復雜，架構變得越來越吃不消了，各種負載問題慢慢浮上水面，于是有了我們的第二代游戲服務器。

類型3：第二代游戲服務器2003

2000年后，網游已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很<imgsrc="/84639b389f9c970434e21313a5acd999_b.jpg"data-rawwidth="418"data-rawheight="185"class="content_image"width="418">

每臺Node服務器用來管理一塊地圖區(qū)域，由NodeMaster（NM）來為他們提供總體管理。更高層次的World則提供大陸級別的管理服務。這里省略若干細節(jié)服務器，比如傳統數據庫前端，登錄服務器，日志和監(jiān)控等，統統用ADMIN概括。在這樣的結構下，玩家從一塊區(qū)域走向另外一塊區(qū)域需要簡單處理一下：

<imgsrc="/61343d4be52424cd1cee4959f580cfeb_b.jpg"data-rawwidth="388"data-rawheight="290"class="content_image"width="388">玩家1完全由節(jié)點A控制，玩家3完全由節(jié)點B控制。而處在兩個節(jié)點邊緣的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的過程中，會同時向A請求左邊的情況，并向B請求右邊的情況。但是此時玩家2還是屬于A管理。直到玩家2徹底離開AB邊界很遠，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區(qū)域，交由不同的Node去管理。玩家1完全由節(jié)點A控制，玩家3完全由節(jié)點B控制。而處在兩個節(jié)點邊緣的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的過程中，會同時向A請求左邊的情況，并向B請求右邊的情況。但是此時玩家2還是屬于A管理。直到玩家2徹底離開AB邊界很遠，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區(qū)域，交由不同的Node去管理。

對于一個Node所負責的區(qū)域，地理上沒必要連接在一起，比如大陸的四周邊緣部分和高山部分的區(qū)塊人比較少，可以統一交給一個Node去管理，而這些區(qū)塊在地理上并沒有聯系在一起的必要性。一個Node到底管理哪些區(qū)塊，可以根據游戲實時運行的負載情況，定時維護的時候進行更改NodeMaster上面的配置。

于是碰到第一個問題是很多Node服務器需要和玩家進行通信，需要問管理服務器特定UID為多少的玩家到底在哪臺Gate上，以前按場景切割的服務器這個問題不大，問了一次以后就可以緩存起來了，但是現在服務器種類增加不少，玩家又會飄來飄去，按UID查找玩家比較麻煩；另外一方面GATE需要動態(tài)根據坐標計算和哪些Node通信，導致邏輯越來越厚，于是把：“用戶對象”從負責連接管理的GATE中切割出來勢在必行于是有了下面的模型：

<imgsrc="/b258799af7d2bec76b90651cfdf696da_b.jpg"data-rawwidth="420"data-rawheight="275"class="content_image"width="420">網關服務器再次退回到精簡的網絡轉發(fā)功能，而用戶邏輯則由按照UID劃分的OBJ服務器來承擔，GATE是按照網絡接入時的負載來分布，而OBJ則是按照資源的編號（UID）來分布，這樣和一個用戶通信直接根據UID計算出OBJ服務器編號發(fā)送數據即可。而新獨立出來的OBJ則提供了更多高層次的服務：網關服務器再次退回到精簡的網絡轉發(fā)功能，而用戶邏輯則由按照UID劃分的OBJ服務器來承擔，GATE是按照網絡接入時的負載來分布，而OBJ則是按照資源的編號（UID）來分布，這樣和一個用戶通信直接根據UID計算出OBJ服務器編號發(fā)送數據即可。而新獨立出來的OBJ則提供了更多高層次的服務：對象移動：管理具體玩家在不同的Node所管轄的區(qū)域之間的移動，并同需要的Node進行溝通。數據廣播：Node可以給每個用戶設置若干TAG，然后通知ObjectMaster按照TAG廣播。對象消息：通用消息推送，給某個用戶發(fā)送數據，直接告訴OBJ，不需要直接和GATE打交道。好友聊天：角色之間聊天直接走OBJ/OBJMASTER。整個服務器主體分為三層以后，NODE專注場景，OBJ專注玩家對象，GATE專注網絡。這樣的模型在無縫場景服務器中得到廣泛的應用。但是隨著時間的推移，負載問題也越來越明顯，做個活動，遠來不活躍的區(qū)域變得十分活躍，靠每周維護來調整還是比較笨重的，于是有了動態(tài)負載均衡。

動態(tài)負載均衡有兩種方法，第一種是按照負載，由NodeMaster定時動態(tài)移動修改一下各個Node的邊界，而不同的玩家對象按照先前的方法從一臺Node上遷移到另外一臺Node上：

<imgsrc="/0c4dcad7e6e8a694a46d6836140b0f5e_b.jpg"data-rawwidth="162"data-rawheight="181"class="content_image"width="162">圖11動態(tài)負載均衡圖11動態(tài)負載均衡

這樣NodeMaster定時查找地圖上的熱點區(qū)域，計算新的場景切割方式，然后告訴其他服務器開始調整，具體處理方式還是和上面對象跨越邊界移動的方法一樣。

但是上面這種方式實現相對復雜一些，于是人們設計出了更為簡單直接的一種新方法：

<imgsrc="/8e250bfe7fc15eb0a0d2925dab684ec2_b.jpg"data-rawwidth="251"data-rawheight="250"class="content_image"width="251">圖12基于網格的動態(tài)負載均衡圖12基于網格的動態(tài)負載均衡

還是將地圖按照標準尺寸均勻切割成靜態(tài)的網格，每個格子由一個具體的Node負責，但是根據負載情況，能夠實時的遷移到其他Node上。在遷移分為三個階段：準備，切換，完成。三個狀態(tài)由NodeMaster負責維護。準備階段新的Node開始同步老Node上面該網格的數據，完成后告訴NM；NM確認OK后同時通知新舊Node完成切換。完成切換后，如果Obj服務器還在和老的Node進行通信，老的Node將會對它進行糾正，得到糾正的OBJ將修正自己的狀態(tài)，和新的Node進行通信。

很多無縫動態(tài)負載均衡的服務端宣稱自己支持無限的人數，但不意味著MMORPG游戲的人數上限真的可以無限擴充，因為這樣的體系會受制于網絡帶寬和客戶端性能。帶寬決定了同一個區(qū)域最大廣播上限，而客戶端性能決定了同一個屏幕到底可以繪制多少個角色。

從無縫地圖引入了分布式對象模型開始，已經完全脫離MUDOS體系，成為一種新的服務端模型。又由于動態(tài)負載均衡的引入，讓無縫服務器如虎添翼，容納著超過上一代游戲服務器數倍的人數上限，并提供了更好的游戲體驗，我們稱其為第三代游戲服務端架構。網游以大型多人角色扮演為開端，RPG網游在相當長的時間里一度占據90%以上，使得基于MMORPG的服務端架構得到了蓬勃的發(fā)展，然而隨著玩家對RPG的疲憊，各種非MMORPG游戲如雨后春筍般的出現在人們眼前，受到市場的歡迎。

類型5：戰(zhàn)網游戲服務器

經典戰(zhàn)網服務端和RPG游戲有兩個區(qū)別：RPG是分區(qū)分服的，北京區(qū)的用戶和廣州區(qū)的用戶老死不相往來。而戰(zhàn)網，雖然每局游戲一般都是8人以內，但全國只有一套服務器，所有的玩家都可以在一起游戲，而玩家和玩家之使用P2P的方式連接在一起，組成一局游戲：<imgsrc="/40254f76ec9b875314b12fda3d0c5da7_b.jpg"data-rawwidth="493"data-rawheight="352"class="origin_imagezh-lightbox-thumb"width="493"data-original="/40254f76ec9b875314b12fda3d0c5da7_r.jpg">玩家通過MatchMaking服務器使用：創(chuàng)建、加入、自動匹配、邀請等方式組成一局游戲。服務器會選擇一個人做Host，其他人P2P連接到做主的玩家上來。STUN是幫助玩家之間建立P2P的牽引服務器，而由于P2P聯通情況大概只有75%，實在聯不通的玩家會通過Forward進行轉發(fā)。玩家通過MatchMaking服務器使用：創(chuàng)建、加入、自動匹配、邀請等方式組成一局游戲。服務器會選擇一個人做Host，其他人P2P連接到做主的玩家上來。STUN是幫助玩家之間建立P2P的牽引服務器，而由于P2P聯通情況大概只有75%，實在聯不通的玩家會通過Forward進行轉發(fā)。

大量的連接對戰(zhàn)，體育競技游戲采用類似的結構。P2P有網狀模型（所有玩家互相連接），和星狀模型（所有玩家連接一個主玩家）。復雜的游戲狀態(tài)在網狀模型下難以形成一致，因此星狀P2P模型經受住了歷史的考驗。除去游戲數據，支持語音的戰(zhàn)網系統也會將所有人的語音數據發(fā)送到做主的那個玩家機器上，通過混音去重再編碼的方式返回給所有用戶。

戰(zhàn)網類游戲，以競技、體育、動作等類型的游戲為主，較慢節(jié)奏的RPG（包括ARPG）有本質上的區(qū)別，而激烈的游戲過程必然帶來到較RPG復雜的多的同步策略，這樣的同步機制往往帶來的是很多游戲結果由客戶端直接計算得出，那在到處都是破解的今天，如何保證游戲結果的公正呢？

主要方法就是投票法，所有客戶端都會獨立計算，然后傳遞給服務器。如果結果相同就更新記錄，如果結果不一致，會采取類似投票的方式確定最終結果。同時記錄本劇游戲的所有輸入，在可能的情況下，找另外閑散的游戲客戶端驗算整局游戲是否為該結果。并且記錄經常有作弊嫌疑的用戶，供運營人員封號時參考。

類型7：休閑游戲服務器

休閑游戲同戰(zhàn)網服務器類似，都是全區(qū)架構，不同的是有