由于網游服務器的設計牽涉到太多內容，比如：網絡通信方面、人工智能、數據庫設計等等，所以本文將重點從網絡通信方面的內容展開論述。談到網絡通信，就不能不涉及如下五個問題：
1、 常見的網游服務通信器架構概述
2、 網游服務器設計的基本原則
3、 網游服務器通信架構設計所需的基本技術
4、 網游服務器通信架構的測試
5、 網游服務器通信架構設計的常見問題

下面我們就從第一個問題說起：

常見的網游服務器通信架構概述
　　目前，國內的網游市場中大體存在兩種類型的網游游戲：MMORPG（如：魔獸世界）和休閑網游（如：QQ休閑游戲和聯眾游戲，而如泡泡堂一類的游戲與QQ休閑游戲有很多相同點，因此也歸為此類）。由于二者在游戲風格上的截然不同，導致了他們在通信架構設計思路上的較大差別。下面筆者將分別描述這兩種網游的通信架構。

1．MMORPG類網游的通信架構
　　網游的通信架構，通常是根據幾個方面來確定的：游戲的功能組成、游戲的預計上線人數以及游戲的可擴展性。
　　目前比較通用的MMORPG游戲流程是這樣的：

a. 玩家到游戲官方網站注冊用戶名和密碼。
b. 注冊完成后，玩家選擇在某一個區激活游戲賬號。
c. 玩家在游戲客戶端中登錄進入已經被激活的游戲分區，建立游戲角色進行游戲。

　　通常，在這樣的模式下，玩家的角色數據是不能跨區使用的，即：在A區建立的游戲角色在B區是無法使用的，各區之間的數據保持各自獨立性。我們將這樣獨立的A區或B區稱為一個獨立的服務器組，一個獨立的服務器組就是一個相對完整的游戲世界。而網游服務器的通信架構設計，則包括了基于服務器組之上的整個游戲世界的通信架構，以及在一個服務器組之內的服務器通信架構。

　　我們先來看看單獨的服務器組內部的通信是如何設計的。
　　一個服務器組內的各服務器組成，要依據游戲功能進行劃分。不同的游戲內容策劃會對服務器的組成造成不同的影響。一般地，我們可以將一個組內的服務器簡單地分成兩類：場景相關的（如：行走、戰斗等）以及場景不相關的（如：公會聊天、不受區域限制的貿易等）。為了保證游戲的流暢性，可以將這兩類不同的功能分別交由不同的服務器去各自完成。另外，對于那些在服務器運行中進行的比較耗時的計算，一般也會將其單獨提煉出來，交由單獨的線程或單獨的進程去完成。

　　各個網游項目會根據游戲特點的不同，而靈活選擇自己的服務器組成方案。經常可以見到的一種方案是：場景服務器、非場景服務器、服務器管理器、AI服務器以及數據庫代理服務器。
　　以上各服務器的主要功能是：

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

　　非場景服務器：它主要負責完成與游戲場景不相關的游戲邏輯，這些邏輯不依靠游戲的地圖系統也能正常進行，比如公會聊天或世界聊天，之所以把它從場景服務器中獨立出來，是為了節省場景服務器的CPU和帶寬資源，讓場景服務器能夠盡可能快地處理那些對游戲流暢性影響較大的游戲邏輯。

　　服務器管理器：為了實現眾多的場景服務器之間以及場景服務器與非場景服務器之間的數據同步，我們必須建立一個統一的管理者，這個管理者就是服務器組中的服務器管理器。它的任務主要是在各服務器之間作數據同步，比如玩家上下線信息的同步。其最主要的功能還是完成場景切換時的數據同步。當玩家需要從一個場景A切換到另一個場景B時，服務器管理器負責將玩家的數據從場景A轉移到場景B，并通過協議通知這兩個場景數據同步的開始與結束。所以，為了實現這些內容繁雜的數據同步任務，服務器管理器通常會與所有的場景服務器和非場景服務器保持socket連接。

　　AI（人工智能）服務器：由于怪物的人工智能計算非常消耗系統資源，所以我們把它獨立成單獨的服務器。AI服務器的主要作用是負責計算怪物的AI，并將計算結果返回給場景服務器，也就是說，AI服務器是單獨為場景服務器服務的，它完成從場景服務器交過來的計算任務，并將計算結果返回給場景服務器。所以，從網絡通信方面來說，AI服務器只與眾多場景服務器保持socket連接。

　　數據庫代理服務器：在網游的數據庫讀寫方面，通常有兩種作法，一種是在應用服務器中直接加進數據庫訪問的代碼進行數據庫訪問，還有一種方式是將數據庫讀寫獨立出來，單獨作成數據庫代理，由它統一進行數據庫訪問并返回訪問結果。

　　其中，非場景服務器在不同的游戲項目中可能會被設計成不同的功能，比如以組隊、公會或全頻道聊天為特色的游戲，很可能為了滿足玩家的聊天需求而設立單獨的聊天服務器；而如果是以物品貿易（如拍賣等）為特色的游戲，很可能為了滿足拍賣的需求而單獨設立拍賣服務器。到底是不是有必要將某一項游戲功能獨立處理成一個服務器，要視該功能對游戲的主場景邏輯（指行走、戰斗等玩家日常游戲行為）的影響程度而定。如果該功能對主場景邏輯的影響比較大，可能對主場景邏輯的運行造成比較嚴重的性能和效率損失，那么應考慮將其從主場景邏輯中剝離，但能否剝離還有另一個前提：此功能是否與游戲場景（即地圖坐標系統）相關。如果此功能與場景相關又確實影響到了主場景邏輯的執行效率，則可能需要在場景服務器上設立專門的線程來處理而不是將它獨立成一個單獨的服務器。

　　以上是一個服務器組內的各服務器組成情況介紹，那么，各服務器之間是如何通信的呢？它的基本通信構架有哪些呢？
　　MMORPG的單組服務器架構通常可以分為兩種：第一種是帶網關的服務器架構；第二種是不帶網關的服務器架構。兩種方案各有利弊。

　　就帶網關的服務器架構而言，由于它對外只向玩家提供唯一的一個通信端口，所以在玩家一側會有比較流暢的游戲體驗，這通常也是那些超大規模無縫地圖網游所采用的方案，但這種方案的缺點是服務器組內的通信架構設計相對復雜、調試不方便、網關的通信壓力過大、對網關的通信模型設計要求較高等。第二種方案會同時向玩家開放多個游戲服務器端口，除了游戲場景服務器的通信端口外，同時還可能提供諸如聊天服務器等的通信端口。這種方案的主要缺點是在進行場景服務器的切換時，玩家客戶端的表現中通常會有一個諸如場景調入的界面出現，影響了游戲的流暢感。基于這種方案的游戲在客戶端的界面處理方面，比較典型的表現是：當要進行場景切換時，只能通過相應的“傳送功能”傳送到另外的場景去，或者需要進入新的場景時，客戶端會有比較長時間的等待進入新場景的等待界面(Loading界面)。

　　從技術角度而言，筆者更傾向于將獨立的服務器組設計成帶網關的模型，雖然這加大了服務器的設計難度，但卻增強了游戲的流暢感和安全性，這種花費還是值得的。
　　筆者在下面附上了帶網關的MMORPG通信架構圖，希望能給業內的朋友們一點有益的啟迪。