網遊伺服器通訊架構設計

隨著網遊從業者的規模和需求不斷擴大，越來越多的朋友進入了網遊開發這個領域，使得市場中網遊開發技術相關的需求量迅猛增長。目前，網遊行業比較緊缺的是具有較深技術功底的“專家型”開發人員，這主要包括兩個方面：伺服器端設計人員以及用戶端設計人員。對於網路遊戲而 言，由於其主要的遊戲邏輯計算是在伺服器端完成的，資料同步與廣播資訊的傳遞也是通過伺服器完成的，所以，是否擁有一個有經驗的伺服器端設計人員已經成為 一款網遊產品能否成功的關鍵之一。鑒於此，本文將試圖就網遊伺服器設計的一系列問題展開討論和總結，筆者將結合自己的開發經驗和體會，將其中各方面內容逐 一呈現。希望能夠對以下三類人員有所協助：
有一定網路編程基礎、準備進入網遊行業作伺服器端設計的人員；
正在從事網遊伺服器設計的人員；
網遊項目的技術負責人。

由於網遊伺服器的設計牽涉到太多內容，比如：網路通訊方面、人工智慧、資料庫設計等等，所以本文將重點從網路通訊方面的內容展開論述。談到網路通訊，就不能不涉及如下五個問題：

1、 常見的網遊服務通訊器架構概述
2、 網遊伺服器設計的基本原則
3、 網遊伺服器通訊架構設計所需的基本技術
4、 網遊伺服器通訊架構的測試
5、 網遊伺服器通訊架構設計的常見問題

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

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

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

a. 玩家到遊戲官方網站註冊使用者名稱和密碼。
b. 註冊完成後，玩家選擇在某一個區啟用遊戲帳號。
c. 玩家在遊戲用戶端中登入進入已經被啟用的遊戲分區，建立遊戲角色進行遊戲。

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

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

各個網遊項目會根據遊戲特點的不同，而靈活選擇自己的伺服器組成方案。經常可以見到的一種方案是：情境伺服器、非情境伺服器、伺服器管理員、AI伺服器以及資料庫Proxy 伺服器。
以上各伺服器的主要功能是：

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

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

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

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

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

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

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

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

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