一、早期網游服務器
網游剛出現的時候，游戲服務器和小Web服務器沒有區別。
從《傳奇》的時代開始，游戲服務器內部就出現了游戲邏輯，既能用于同步每個玩家看到的世界，又能讓邏輯與客戶端分離，避免早期的網絡游戲那種毫無防范的邏輯體系（對外掛防御能力為0）。

這種服務器在客戶端通過某種形式驗證登陸以后，就和服務器通過TCP直接連接了。這種服務器的承載能力不高。 靠多開服務器來彌補單服人數不足的問題 。

二、早期游戲服務器的改進版本

游戲邏輯服務依舊是在一臺服務器上，單進程（邏輯處理本身肯定是在一個線程中，可以有子線程負責內網通信）。但是我們自然地想到，儲存負載和網絡負載可以從邏輯服務器上拆出來。

連接服務器負責把客戶端和服務器之間的消息轉化為服務器的消息，可以順便做一下加密的工作。
由于連接服務器本身沒有時序性，很容易做分布式的（其實大部分游戲還是只有一個連接服），存儲服務不要求高實時性，高峰期存盤間隔可以稍長一些，不會對游戲服造成影響。

三、成熟形態的服務器框架
邏輯服務器的負載均攤方法一：按照功能劃分多個服務器進程

邏輯服務器的負載均攤方法二：按照場景劃分多個服務器進程

這種服務器的難點就在邏輯的設計上，要想做手術一樣把本來一體的功能切開，并抽象出若干個API來保持聯系（服務器之間是TCP連接）。 在分解時，要找聯系相對最薄弱的環節入手比如 場景和場景之間分開、單獨抽出聊天服務、組隊服務、好友服務。 無論如何分解，最終結果只能是有限個服務。而且分解的越細，開發難度越大。因為跨服務器邏輯時把簡單的同步邏輯編程異步Callback邏輯，而且容易出現時序問題等不易測試的問題。單個場景在服務幾乎是無法分解的。分解單個場景難度巨大以至于出現BigWorld引擎來專門解決場景分隔問題。

附：開房間式的網絡游戲

開房間式的網絡游戲是游戲的重要分支，moba和卡牌類游戲都屬于這種形式。 這些游戲房間內幾乎沒有交互，只有大廳內有交互，可以理解為原始形態的游戲服務器的平行拓展。 房間式游戲擴展難度較小，只是需要根據玩家數量動態擴展游戲房間的數量、服務數量。很像網站的架構。

小結：游戲服務器框架特點
1.真正的數據都在內存中，數據庫性能不那么重要（注：很多大型游戲采用了共享內存，避免宕機時損失過大）

2.單CPU性能比CUP數量重要得多3.目前有很多游戲，特別是手游，使用Redis讀寫代替內存讀寫，甚至也有用Mongo的。4.開新服、舊區合服的情況特別適合云平臺。

四、先進服務器框架
? BigWorld
BigWorld的核心理念時場景分割，利用平面切分的原理，將場景劃分為小塊，不同的塊可以運行在不同的服務器上。而且塊的劃分是動態的，根據玩家密度程度，數量動態調整動態整塊的大小。
具體技術上，使用了Actor模型，要求每個對象都是獨立的Entity，對象之間只能通過消息協作，嚴格限制對象之間的直接交互。
? Skynet
Skynet是新興的一種通用型服務器框架（完全開源），它游走在傳統不易分布服務器和分布式服務器之間。
? 以Go語言為主的其他框架
Go語言的goroutine特性，給游戲開發者帶來巨大的想象空間。

戲服務器特征
游戲服務器端，是一個會長期運行的程序，并且它還要服務于多個不定時、不定點的網絡請求。
所以這類軟件的特點是要非常關注 穩定性和 性能。這類程序如果需要多個協作來提高承載能力，則還要關注部署和擴容的便利性；同時，還需要考慮如何實現某種程度的容災需求。由于多進程協同工作，也帶來了開發的復雜度，這也是需要關注的問題。

功能約束，是架構設計的決定性因素。基于游戲領域的功能特征，對服務器端系統來說，有以下幾個特殊的需求：? 對于游戲數據和玩家數據的存儲 ? 對玩家數據進行數據廣播和同步 ? 把一部分游戲邏輯在服務器上運算，做好驗證，防止外掛。針對以上的需求特征，在服務器端，我們往往會關注對電腦內存和 CPU 的使用，以求在特定業務代碼下，能盡量滿足承載量和響應延遲的需求。最基本的做法就是 空間換時間，用各種緩存的方式來求得 CPU 和內存空間上的平衡。在 CPU 和內存之上，是另外一個約束因素：網卡。網絡帶寬直接限制了服務器的處理能力，所以游戲服務器架構也必定要考慮這個因素。

游戲服務器架構要素
對于游戲服務端架構，最重要的三個部分就是，如何使用 CPU、內存、網卡的設計：
? 內存架構：主要決定服務器如何使用內存，以最大化利用服務器端內存來提高承載量，降低服務延遲。
? 邏輯架構：設計如何使用進程、線程、協程這些對于 CPU 調度的方案。選擇同步、異步等不同的編程模型，以提高服務器的穩定性和承載量。可以分區分服，也可以采用世界服的方式，將相同功能模塊劃分到不同的服務器來處理。
? 通信模式：決定使用何種方式通訊。基于游戲類型不同采用不同的通信模式，比如 http,tcp,udp 等。
服務器基于游戲類型不同，所采用的架構也有所不同，我們先講一下簡單的模型，采用 HTTP 通信模式架構的服務器:

這種服務器架構和我們常用的 web 服務器架構差不多，也是采用 Nginx 負載集群支持服務器的水平擴展，memcache 做緩存。唯一的不同點在于通信層需要對協議再加工和加密。一般每個公司都有自己的一套基于 HTTP 的協議層框架，很少采用開源框架。長連接游戲服務器長連接游戲和弱聯網游戲不同的地方在于，長連接中，玩家是有狀態的，服務器可以時時和 client 交互。數據的傳送，不像弱聯網一般每次都需要重新創建一個連接，消息傳送的頻率以及速度上都快于弱聯網游戲。

服務器的三種類型功能：
場景服務器：它負責完成主要的游戲邏輯，這些邏輯包括角色在游戲場景中的進入與退出、角色的行走與跑動、角色戰斗（包括打怪）、任務的認領等。場景服務器設計的好壞是整個游戲世界服務器性能差異的主要體現，它的設計難度不僅僅在于通信模型方面，更主要的是整個服務器的體系架構和同步機制的設計。

非場景服務器：它主要負責完成與游戲場景不相關的游戲邏輯，這些邏輯不依靠游戲的地圖系統也能正常進行，比如公會聊天或世界聊天，之所以把它從場景服務器中獨立出來，是為了節省場景服務器的 CPU 和帶寬資源，讓場景服務器能夠盡可能快地處理那些對游戲流暢性影響較大的游戲邏輯。網關服務器: 在類型一種的架構中，玩家在多個地圖跳轉或者場景切換的時候采用跳轉的模式，以此進行跳轉不同的服務器。還有一種方式是把這些服務器的節點都通過網關服務器管理，玩家和網關服務器交互，每個場景或者服務器切換的時候，也有網關服務器統一來交換數據，如此玩家操作會比較流暢。 通過這種類型服務器架構，因為壓力分散了，性能會有明顯提升，負載也更大了，包括目前一些大型的 MMORPG 游戲就是采用此架構。不過每增加一級服務器，狀態機復雜度可能會翻倍，導致研發和找 bug 的成本上升，這個對開發組挑戰比較大，沒有經驗，很容出錯。3、三類型 - 無縫地圖 魔獸世界的中無縫地圖，想必大家印象深刻，整個世界的移動沒有像以往的游戲一樣，在切換場景的時候需要 loading 等待，而是直接行走過去，體驗流暢。 現在的游戲大地圖采用無縫地圖多數采用的是 9 宮格的樣式來處理，由于地圖沒有魔獸世界那么大，所以采用單臺服務器多進程處理即可，不過類似魔獸世界這種大世界地圖，必須考慮 2 個問題：? 多個地圖節點如何無縫拼接，特別是當地圖節點比較多的時候，如何保證無縫拼接? 如何支持動態分布，有些區域人多，有些區域人少，保證服務器資源利用的最大化 為了解決這個問題，需要一組服務器來處理，每臺 Node 服務器用來管理一塊地圖區域，由 NodeMaster（NM）來為他們提供總體管理。更高層次的 World 則提供大陸級別的管理服務。 一個 Node 所負責的區域，地理上沒必要連接在一起，可以統一交給一個 Node 去管理，而這些區塊在地理上并沒有聯系在一起的必要性。一個 Node 到底管理哪些區塊，可以根據游戲實時運行的負載情況，定時維護的時候進行更改 NodeMaster 上面的配置。

結語
游戲服務開發需要應對高并發，低時延的業務場景，必須要懂得正確地分拆各個模塊。

總結

以上是生活随笔為你收集整理的网游服务器架构变迁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。