您當前位置：首頁 > php框架 > 框架設計 > 游戲服務端架構介紹

游戲服務端架構介紹

來源：程序員人生發布時間：2016-09-28 10:16:05 閱讀次數：6373次

類型1：卡牌、跑酷等弱交互服務端
卡牌跑酷類由于交互弱，玩家和玩家之間不需要實時面對面PK，打1下對方的離線數據，計算下排行榜，買賣下道具便可，所以實現常常使用簡單的 HTTP服務器：

登錄時可使用非對稱加密（RSA, DH），服務器根據客戶端uid，當前時間戳還有服務端私鑰，計算哈希得到的加密 key 并發送給客戶端。以后雙方都用 HTTP通訊，并用那個key進行RC4加密。客戶端收到key和時間戳后保存在內存，用于以后通訊，服務端不需要保存 key，由于每次都可以根據客戶端傳上來的 uid 和時間戳和服務端自己的私鑰計算得到。用模仿 TLS的行動，來保證屢次 HTTP要求間的客戶端身份，并通過時間戳保證同1人兩次登錄密鑰不同。
每局開始時，訪問1下，要求1下關卡數據，玩完了又提交1下，驗算1下是不是合法，取得甚么嘉獎，數據庫用單臺 MySQL或 MongoDB便可，后真個 Redis做緩存（可選）。如果要實現通知，那末讓客戶端定時15秒輪詢1下服務器，如果有消息就取下來，如果沒消息可以逐漸放長輪詢時間，比如30秒；如果有消息，就縮短輪詢時間到10秒，5秒，即使兩人聊天，延遲也能自適應。
此類服務器用來實現1款3國類策略或卡牌及酷跑的游戲已綽綽有余，這類游戲由于邏輯簡單，玩家之間交互不強，使用 HTTP來開發的話，開發速度快，調試只需要1個閱讀器就能夠把邏輯調試清楚了。
類型2：第1代游戲服務器 1978
1978年，英國著名的財經學校University of Essex的學生 Roy Trubshaw編寫了世界上第1個MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET以后加入了很多外部的玩家，乃至包括國外的玩家。《MUD1》程序的源代碼在 ARPANET同享以后出現了眾多的改編版本，至此MUD才在全球廣泛流行起來。不斷完善的 MUD1的基礎上產生了開源的 MudOS（1991），成為眾多網游的鼻祖：

MUDOS采取 C語言開發，由于玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務所有玩家，所有玩家的要求都發到同1個線程去處理，主線程每隔1秒鐘更新1次所有對象（網絡收發，更新對象狀態機，處理超時，刷新地圖，刷新NPC）。
游戲世界采取房間的情勢組織起來，每一個房間有東南西北4個方向可以移動到下1個房間，由于歐美最早的網游都是地牢迷宮情勢的，因此場景的基本單位被成為 “房間”。MUDOS使用1門稱為LPC的腳本語言來描寫全部世界（包括房間拓撲，配置，NPC，和各種劇情）。游戲里面的高級玩家（巫師），可以不斷的通過修改腳本來為游戲添加房間和增加重情。早年 MUD1上線時只有17個房間，Roy Trubshaw畢業以后交給他的師弟 Richard Battle，在 Richard Battle手上，不斷的添加各種玩法到1百多個房間，終究讓 MUD發揚光大。
用戶使用 Telnet之類的客戶端用 Tcp協議連接到 MUDOS上，使用純文字進行游戲，每條指令用回車進行分割。比如 1995年國內第1款 MUD游戲《俠客行》，你敲入："go east"，游戲就會提示你：“后花園 - 這里是歸云莊的后花園，種滿了花草，幾個莊丁正在澆花。此地乃是含羞草生長之地。這里唯1的出口是 north。這里有：花待阿牧（A mu），還有2位莊丁（Zhuang Ding）”，然后你繼續用文字操作，查看阿牧的信息：“look a mu”，系統提示：“花待阿牧（A mu）他是陸乘風的弟子，受命在此看管含羞草。他看起來310多歲，生得眉清目秀，端正大方，1表人材。他的武藝看上去【不是很高】，出手似乎【極輕】”。然后你可以選擇擊敗他取得含羞草，但是你吃了含羞草卻又可能會中毒死亡。在初期網上資源貧乏的時候，這樣的游戲有很強的代入感。
用戶數據保存在文件中，每一個用戶登錄時，從文本文件里把用戶的數據全部加載進來，操作全部在內存里面進行，無需馬上刷回磁盤。用戶退出了，或每隔5分鐘檢查到數據改動了，都會保存會磁盤。這樣的系統在當時每臺服務器承載個4000人同時游戲，不是特別大的問題。從1991年的 MUDOS發布后，全球各地都在為他改進，擴充，退出新版本，隨著 Windows圖形性能的增強。1997游戲《UO》在 MUDOS的基礎上為角色增加的x,y坐標，為每一個房間增加了地圖，并且為每一個角色增加了動畫，構成了第1代的圖形網絡游戲。
由于游戲內容基本可以通過 LPC腳本進行定制，所以MUDOS同樣成為名不虛傳的第1款服務端引擎，引擎1次性開發出來，然后制作不同游戲內容。后續國內的《萬王之王》等游戲，很多都是跟《UO》1樣，直接在 MUDOS上進行2次開發，加入房間的地圖還有角色的坐標等要素，該架構1直為國內的第1代 MMORPG提供了穩固的支持，直到 2003年，還有游戲基于 MUDOS開發。
雖然后面圖形化增加了很多東西，但是這些MMORPG后真個本質還是 MUDOS。隨著游戲內容的愈來愈復雜，架構變得愈來愈吃不消了，各種負載問題漸漸浮上水面，因而有了我們的第2代游戲服務器。
類型3：第2代游戲服務器 2003
2000年后，網游已脫離最初的文字MUD，進入全面圖形化年代。最早承受不住的實際上是很多小文件，用戶上下線，頻繁的讀取寫入用戶數據，致使負載愈來愈大。隨著在線人數的增加和游戲數據的增加，服務器變得不抗重負。同時初期 EXT磁盤分區比較脆弱，略微停電，容易產生大面積數據丟失。因此第1步就是拆分文件存儲到數據庫去。

此時游戲服務端已脫離陳腐的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的游戲服務端。并且腳本也拋棄了 LPC，采取擴大性更好的 Python或 Lua來代替。由于主邏輯使用單線程模型，隨著游戲內容的增加，傳統單服務器的結構進1步成為瓶頸。因而有人開始拆分游戲世界，變成下面的模型：

游戲服務器壓力拆分后得意減緩，但是兩臺游戲服務器同時訪問數據庫，大量重復訪問，大量數據交換，使得數據庫成為下1個瓶頸。因而構成了數據庫前端代理（DB Proxy），游戲服務器不直接訪問數據庫而是訪問代理，再有代理訪問數據庫，同時提供內存級別的cache。早年 MySQL4之前沒有提供存儲進程，這個前端代理1般和 MySQL跑在同1臺上，它轉化游戲服務器發過來的高級數據操作指令，拆分成具體的數據庫操作，1定程度上代替了存儲進程：

但是這樣的結構并沒有延續太長時間，由于玩家切換場景常常要切換連接，中間的狀態容易錯亂。而且游戲服務器多了以后，相互之間數據交互又會變得比較麻煩，因而人們拆分了網絡功能，獨立出1個網關服務 Gate（有的地方叫 Session，有的地方叫 LinkSvr之類的，名字不同而已）：

把網絡功能單獨提取出來，讓用戶統1去連接1個網關服務器，再有網關服務器轉發數據到后端游戲服務器。而游戲服務器之間數據交換也統1連接到網管進行交換。這樣類型的服務器基本能穩定的為玩家提供游戲服務，1臺網關服務1⑵萬人，后面的游戲服務器每臺服務5k⑴w，依游戲類型和復雜度不同而已，圖中隱藏了很多不重要的服務器，如登錄和管理。這是目前利用最廣的1個模型，到今天任然很多新項目會才用這樣的結構來搭建。
人都是有慣性的，依照先前的經驗，似乎把 MUDOS拆分的越開性能越好。因而大家繼續想，網關可以拆分呀，基礎服務如聊天交易，可以拆分呀，還可以提供web接口，數據庫可以拆分呀，因而有了下面的模型：

這樣的模型好用么？確切有成功游戲使用類似這樣的架構，并且發揮了它的性能優勢，比如1些大型 MMORPG。但是有兩個挑戰：每增加1級服務器，狀態機復雜度可能會翻倍，致使研發和找bug的本錢上升；并且對開發組挑戰比較大，1旦項目時間吃緊，開發人員經驗不足，很容易弄掛。
比如我見過某上海1線游戲公司的1個 RPG上來就要上這樣的架構，我看了下他們團隊成員的經驗，問了下他們的上線日期，勸他們用前面略微簡單1點的模型。人家自信得很，認為有成功項目是這么做的，他們也要這么做，自己很想實現1套。因而他們義無返顧的開始編碼，項目做了1年多，然后，就沒有然后了。
當今在游戲成功率不高的情況下，1開始上1套比較復雜的架構需要斟酌投資回報率，比如你的游戲上線半年內 PCU會去到多少？如果1個 APRG游戲，每組服務器5千人都到不了的話，那末選擇1套更加貼近實際情況的結構更加經濟。即便后面你的項目真的超過5千人朝著1萬人目標奔的話，相信那個時候你的項目已掙大錢了，你數著錢加著班去逐漸迭代，1次次拆分它，相信心里也是樂開花的。
上面這些類型基本都是從拆分 MUDOS開始，將 MUDOS中的各個部件從單機1步步拆成份布式。雖然今天任然很多新項目在用上面某1種類似的結構，或自己又做了其他熱門模塊的拆分。由于他們本質上都是對 MUDOS的分解，故將他們歸納為第2代游戲服務器。
類型4：第3代游戲服務器 2007
從魔獸世界開始無縫世界地圖已深入人心，比較以往游戲玩家走個幾步還需要切換場景，每次切換就要等待 LOADING個幾10秒是1件10分破壞游戲體驗的事情。因而對 2005年以后的大型 MMORPG來講，無縫地圖已成為1個標準配置。比較以往依照地圖來切割游戲而言，無縫世界其實不存在1塊地圖上面的人有且只由1臺服務器處理了：

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

玩家1完全由節點A控制，玩家3完全由節點B控制。而處在兩個節點邊沿的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的進程中，會同時向A要求左側的情況，并向B要求右側的情況。但是此時玩家2還是屬于A管理。直到玩家2完全離開AB邊界很遠，才完全交由B管理。依照這樣的邏輯將世界地圖分割為1塊1塊的區域，交由不同的 Node去管理。
對1個 Node所負責的區域，地理上沒必要連接在1起，比如大陸的4周邊沿部份和高山部份的區塊人比較少，可以統1交給1個Node去管理，而這些區塊在地理上并沒有聯系在1起的必要性。1個 Node到底管理哪些區塊，可以根據游戲實時運行的負載情況，定時保護的時候進行更改 NodeMaster 上面的配置。
因而碰到第1個問題是很多 Node服務器需要和玩家進行通訊，需要問管理服務器特定UID為多少的玩家到底在哪臺 Gate上，之前按場景切割的服務器這個問題不大，問了1次以后就能夠緩存起來了，但是現在服務器種類增加很多，玩家又會飄來飄去，按UID查找玩家比較麻煩；另外1方面 GATE需要動態根據坐標計算和哪些 Node通訊，致使邏輯愈來愈厚，因而把：“用戶對象”從負責連接收理的 GATE中切割出來勢在必行因而有了下面的模型：

網關服務器再次退回到精簡的網絡轉發功能，而用戶邏輯則由依照 UID劃分的 OBJ服務器來承當，GATE是依照網絡接入時的負載來散布，而 OBJ則是依照資源的編號（UID）來散布，這樣和1個用戶通訊直接根據 UID計算出 OBJ服務器編號發送數據便可。而新獨立出來的 OBJ則提供了更多高層次的服務：
· 對象移動：管理具體玩家在不同的 Node所管轄的區域之間的移動，并同需要的 Node進行溝通。
· 數據廣播：Node可以給每一個用戶設置若干 TAG，然后通知 Object Master 依照TAG廣播。
· 對象消息：通用消息推送，給某個用戶發送數據，直接告知 OBJ，不需要直接和 GATE打交道。
· 好友聊天：角色之間聊天直接走 OBJ/OBJ MASTER。
全部服務器主體分為3層以后，NODE專注場景，OBJ專注玩家對象，GATE專注網絡。這樣的模型在無縫場景服務器中得到廣泛的利用。但是隨著時間的推移，負載問題也愈來愈明顯，做個活動，遠來不活躍的區域變得10分活躍，靠每周保護來調劑還是比較笨重的，因而有了動態負載均衡。
動態負載均衡有兩種方法，第1種是依照負載，由 Node Master 定時動態移動修改1下各個 Node的邊界，而不同的玩家對象依照先前的方法從1臺 Node上遷移到另外1臺 Node上：

圖11 動態負載均衡
這樣 Node Master定時查找地圖上的熱門區域，計算新的場景切割方式，然后告知其他服務器開始調劑，具體處理方式還是和上面對象逾越邊界移動的方法1樣。
但是上面這類方式實現相對復雜1些，因而人們設計出了更加簡單直接的1種新方法：

圖12 基于網格的動態負載均衡
還是將地圖依照標準尺寸均勻切割成靜態的網格，每一個格子由1個具體的Node負責，但是根據負載情況，能夠實時的遷移到其他 Node上。在遷移分為3個階段：準備，切換，完成。3個狀態由Node Master負責保護。準備階段新的 Node開始同步老 Node上面該網格的數據，完成后告知NM；NM確認OK后同時通知新舊 Node完成切換。完成切換后，如果 Obj服務器還在和老的 Node進行通訊，老的 Node將會對它進行糾正，得到糾正的 OBJ將修正自己的狀態，和新的 Node進行通訊。
很多無縫動態負載均衡的服務端宣稱自己支持無窮的人數，但不意味著 MMORPG游戲的人數上限真的可以無窮擴充，由于這樣的體系會受制于網絡帶寬和客戶端性能。帶寬決定了同1個區域最大廣播上限，而客戶端性能決定了同1個屏幕到底可以繪制多少個角色。
從無縫地圖引入了散布式對象模型開始，已完全脫離 MUDOS體系，成為1種新的服務端模型。又由于動態負載均衡的引入，讓無縫服務器如虎添翼，容納著超過上1代游戲服務器數倍的人數上限，并提供了更好的游戲體驗，我們稱其為第3代游戲服務端架構。網游以大型多人角色扮演為開端，RPG網游在相當長的時間里1度占據90%以上，使得基于 MMORPG的服務端架構得到了蓬勃的發展，但是隨著玩家對RPG的疲憊，各種非MMORPG游戲如雨后春筍般的出現在人們眼前，遭到市場的歡迎。
類型5：戰網游戲服務器
經典戰網服務端和 RPG游戲有兩個區分：RPG是分辨別服的，北京區的用戶和廣州區的用戶老死不相來往。而戰網，雖然每局游戲1般都是 8人之內，但全國只有1套服務器，所有的玩家都可以在1起游戲，而玩家和玩家之使用 P2P的方式連接在1起，組成1局游戲：

玩家通過 Match Making 服務器使用：創建、加入、自動匹配、約請等方式組成1局游戲。服務器會選擇1個人做 Host，其他人 P2P連接到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引服務器，而由于 P2P聯通情況大概只有 75%，實在聯不通的玩家會通過 Forward進行轉發。
大量的連接對戰，體育競技游戲采取類似的結構。P2P有網狀模型（所有玩家相互連接），和星狀模型（所有玩家連接1個主玩家）。復雜的游戲狀態在網狀模型下難以構成1致，因此星狀P2P模型承受住了歷史的考驗。除去游戲數據，支持語音的戰網系統也會將所有人的語音數據發送到做主的那個玩家機器上，通過混音去重再編碼的方式返回給所有用戶。
戰網類游戲，以競技、體育、動作等類型的游戲為主，較慢節奏的 RPG（包括ARPG）有本質上的區分，而劇烈的游戲進程必定帶來到較 RPG復雜的多的同步策略，這樣的同步機制常常帶來的是很多游戲結果由客戶端直接計算得出，那在到處都是破解的今天，如何保證游戲結果的公正呢？
主要方法就是投票法，所有客戶端都會獨立計算，然后傳遞給服務器。如果結果相同就更新記錄，如果結果不1致，會采取類似投票的方式肯定終究結果。同時記錄本劇游戲的所有輸入，在可能的情況下，找另外閑散的游戲客戶端驗算整局游戲是不是為該結果。并且記錄常常有做弊嫌疑的用戶，供運營人員封號時參考。
類型7：休閑游戲服務器
休閑游戲同戰網服務器類似，都是全區架構，不同的是有房間服務器，還有具體的游戲服務器，游戲主體不再以玩家 P2P進行，而是連接到專門的游戲服務器處理：

和戰網1樣的全區架構，用戶數據不能象分區的 RPG那樣1次性load到內存，然后在內存里面直接修改。全區架構下，為了應對1個用戶同時玩幾個游戲，用戶數據需要辨別基本數據和不同的游戲數據，而游戲數據又需要辨別積分數據、和文檔數據。勝平負之類的積分可以直接提交增量修改，而更加普遍的文檔類數據則需要提供讀寫令牌，寫令牌只有1塊，讀令牌有很多塊。同帳號同1個游戲同時在兩臺電腦上玩時，最早開始的那個游戲取得寫令牌，可以操作任意的用戶數據。而后開始的那個游戲除可以提交勝平負積分的增量改變外，對用戶數據采取只讀的方式，保證游戲能運行下去，但是會提示用戶，游戲數據鎖定。
類型8：現代動作類網游
從初期的韓國動作游戲開始，傳統的戰網動作類游戲和 RPG游戲開始嘗試融會。單純的動作游戲玩家容易疲倦，保存也沒有 RPG那末高；而單純 RPG戰役卻又慢節奏的乏味，沒法滿足很多玩家劇烈對抗的期望，因而2者開始融會成為新1代的：動作 + 城鎮模式。玩家在城鎮中聚集，然后以開副本的方式幾個人出去以動作游戲的玩法來完成各種 RPG任務。本質就是1套 RPG服務端+副本服務端。由于每次副本時人物可以控制在8人之內，因此可以取得更加實時的游戲體驗，讓玩家玩的更加爽快。
說了那末多的游戲服務器類型，其實也差不多了，剩下的類型大家拼湊1下其實也就是這個模樣而已。游戲服務端經歷了那末多結構上的變遷，內部開發模式是不是仍然不變？究竟是繼續延續傳統的開發方式？還是有了更多突破性的方法？經歷那末屢次架構變遷，后面是不是有共通的邏輯？未來的發展還會存在哪些困難？游戲服務端開發如何到達終究的彼岸？請看下節：技術的演進。
技術的演進
（待續）
【感受
從目前流行的開源游戲服務端框架來分析：
網易pomelo 屬于第2代游戲服務端 5型的架構，即圖7的架構。
skynet由于是1個服務端框架，官方只是提供了login server 和 gate server的參考實現，其他的需要自己來實現，編程的自由度變大了，架構完全取決于程序員自己的選擇，程序員可以自己嘗試去實現第2代的架構，也能夠實現第3代的架構。注意: skynet僅僅是框架，其他屬于完全解決方案。
Kbengine屬于第3代服務端框架，可能類似于圖10。（這個理解不肯定）
Kbengine引擎應當是對圖10中的Gate服務器和NODE和OBJ進行了細分。在功能上大體劃分為與位置有關（在Kbengine中稱為Cellapp）和與位置無關（在Kbengine中稱為Baseapp）。類似于下面的示圖架構。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
程序員人生

------分隔線----------------------------

上一篇 [置頂] Android 做一款直播APP？一分鐘掌握樂視云直播Demo

下一篇 自定義時間選擇器

分享到:

------分隔線----------------------------

為碼而活

積分：4237

15粉絲

7關注

欄目熱點

多多色-多人伦交性欧美在线观看-多人伦精品一区二区三区视频-多色视频-免费黄色视屏网站-免费黄色在线

游戲服務端架構介紹