有一定網絡編程基礎、準備進入網遊行業作服務器端設計的人員；
正在從事網遊服務器設計的人員；
網遊項目的技術負責人。
由於網遊服務器的設計牽涉到太多內容，比如：網絡通信方面、人工智能、數據庫設計等等，所以本文將重點從網絡通信方面的內容展開論述。談到網絡通信，就不能不涉及如下五個問題：
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界面)。
從技術角度而言，筆者更傾向於將獨立的服務器組設計成帶網關的模型，雖然這加大了服務器的設計難度，但卻增強了遊戲的流暢感和安全性，這種花費還是值得的。
