轉自 http://blog.csdn.net/SmartTony/article/details/6842065

過去一年中，花了很多時間在考慮服務器架構設計方面的問題。看了大量文章、也研究了不少開源項目，眼界倒是開闊了不少，不過回過頭來看，對網遊架構設計方面的幫助卻是不多。老外還是玩兒console game的多，MMO Games方面涉及的還是不如國內廣泛。看看 Massively Multiplayer Games Development 1 & 2 這兩本書吧，質量說實話很一般，幫助自然也很有限。當然這也是好事，對國內的研發公司/團隊來說，在網遊服務器技術方面當然就存在超越老外的可能性，而且在這方面技術超越的機會更大，當然前提是要有積累、要舍得投入，研發人員更要耐得住寂寞、經得起誘惑，在平均每天收到超過3個獵頭電話的時候——依然不動心。

上面有點兒扯遠了，下面聊聊無縫世界架構（Seamless world server architecture）設計方面的一點兒看法。

先說架構設計的目標——我的看法，服務器組架構設計的目標就是確定各服務器拓補關系和主要的業務邏輯處理方法。主要要解決的問題就是在滿足遊戲內容設計需要的前提下，如何提高帶負載能力的問題。

最簡單的架構就是基本的C/S架構，一臺Server直接構成一個Cluster，所有Client直接連接這個Server，這個Server完成所有邏輯和數據處理。這架構其實很好，最大的好處就是它架構上的 Simplicity ，Cluster內部的跨進程交互完全被排除，復雜度立刻就降下來了，而且——完全可以實現一個無縫（Seamless world）的遊戲世界。但是即使我不說，大家也知道這種單Server架構會有什麽問題。不過我們不妨以另外一個角度來看這個Server——一個黑盒子。從系統外部的角度來看，什麽樣的系統都可以看成一個整體、一個黑盒，而不管系統內部的拓補關系和實現復雜度方面的問題。在不考慮這個系統的實現的前提下，理論上Cluster的處理能力就是由硬件的數量和能力決定的，也就是說一個Server Cluster內包含越多的服務器、服務器越‘快’，那麽這個Cluster的處理能力越好、帶負載能力越好。那麽我們要面對的帶負載能力的問題，就是如何高效的利用這些Server的問題，基本上也可以理解為如何提高玩家請求的並發處理能力

SERVICES-BASED ARCHITECTURE——基於服務的架構。在這種架構內部，我們根據處理數據、邏輯的相關性來劃分組內各個服務器的工作任務。例如：位置服務提供物體可見性信息、物品服務處理所有物品相關的邏輯、社會關系服務提供行會家族等等方面的邏輯、戰鬥服務器只處理戰鬥相關的邏輯，等等。這樣劃分的話、邏輯處理的並發就有了可能性。舉例來說：A砍B一刀這件事情與C從奸商手裏買到一件武器這個事情是完全不相幹的，而且這2個請求本來就在不同的服務器上被處理，他們是被不同的Service Server並發處理的。這就是 Services-based Architecture 的並發方法。

基本上，把遊戲邏輯的處理拆分成一個個的service，就和設計cpu的時候把機器指令的具體處理拆分，然後設計出一個個流水線單元是一個道理。

CELLS-BASED ARCHITECTURE——基於cell的架構。每個cell都在不同的物理server上面運行著完全一樣的應用程序服務器，但是他們負責承載不同的遊戲場景區域的遊戲邏輯。和 services-based arch. 明顯不同的就是，每個cell都是個‘在邏輯上完整的’服務器。它得處理物品操作、人物移動、戰鬥計算等等幾乎所有的遊戲邏輯。盡管這麽做會帶來一些（可能是很復雜）的問題，但是它完全是可行的。舉例來說：在吳國A砍B一刀顯然地和千裏之外在越國的C砍D一刀不搭界，他們完全可以被不同的Cell並發地處理。

基本上，這就相當於一個主板上面插多個CPU或者一個CPU但是有多個內核，每個CPU能做的事情都是一樣的，而且能一起做。

從一組服務器的角度來看，一般來說，我們的服務器組（Cluster）內都會有登陸驗證服務器（Login Server）、持久性數據服務器（DB及DB Proxy）、連接代理服務器（Gate Server、FEP Server、Client Proxy等）以及Auto Patch Server、還有用於集中管理及控制組的服務器等等，由於這些服務器基本上什麽樣的架構設計都會用到，所以——現在不考慮以上這些服務器，只考慮具體處理遊戲邏輯、遊戲規則的各個服務器。以此為前提來分析一下 Services-based Architecture 和 Cells-based Architecture 的優缺點。

對Services-based Architecture 的分析

基於服務的架構，顧名思義這種架構的實現（程序）會是和服務的具體內容（策劃）相關的，這是因為——各種【服務】內容的確定是建立於項目的【需求分析】基礎上的，【需求分析】的前提是基本確定了【策劃設計】，至少是項目的概要設計。

我想多數做過遊戲項目的人都應該對需求變更 有很深的感觸，每個人都說“開始想做的那個和最後實際做出來的那個不一樣”。特別是在項目的早期階段，團隊的不同成員對項目做完之後的樣子有相當不同的看 法（很可能大家互相都不知道對方怎麽看的），這很容易理解，誰也不可能從幾頁紙幾張圖就確切地知道這個遊戲做完了什麽樣子，即使不考慮需求變更。涉及到項 目開發方法方面的東西這裏就不多說了，總之我的看法就是——盡管我們不大可能設計出一個架構能夠適應任何的遊戲設計，但是不同開發任務間的耦合度顯然還是越低越好，基於服務的架構適應需求變更的能力較差。

關於服務耦合

不管如何劃分service，不同 service之間都一定存在不同程度的耦合（coupling）關系，不同的 service 之間會有相互依賴關系。而你們的策劃設計可能會讓這種關系復雜到程序在運行時的狀態很難以琢磨的程度。

假設：
服務器組內的戰鬥處理和物品處理分別由兩個不同的服務（器）提供
遊戲規則：
人物被攻擊後自己攜帶的物品可能掉落到地上
某些物品掉落後會爆炸
物品在地上爆炸可能傷及周圍（半徑10米內）人物
人物之間的‘仇恨度’影響戰鬥數值計算
被攻擊時掉落的物品爆炸後傷及的人物，會增加對‘被攻擊人’的‘仇恨度’

我想我還能想出很多很多“看上去不算過分”的規則來讓這個事情變得復雜無比，很可能你們的策劃也在無意中，已經擁有我這種能力 :) 而 且他們在寫文檔時候的表達還多半不如我上面寫的清楚，另外，他們還會把這些規則分到很多不同的文檔裏面去寫。好吧，你肯定會想“把這兩個服務合二為一好 了”，實際上不管你想把哪兩個（或多個）服務合並為一個服務的時候，都應該先考慮一下當時是為什麽把他們獨立為不同服務的？

實際上很多這樣“看上去不算過分”的規則都會導致service間的頻繁交互，所以每個service最好都是stateless service，這樣的話情況會好很多，但是對於遊戲來說這很難做到。

請求處理的時序問題

服務耦合的問題在不考慮開發復雜度比較高的情況下，還是可以被搞定的，只要腦袋夠清醒，願意花夠多的時間，那麽還有更難以搞定的麽？我看確實還有，如果你對將要面對的問題，了解得足夠多的話:)

上面兩個序列圖描述的是某個玩家做了連續做了兩次同樣的操作但是很可能得到了不同的結果，當然這些請求都是異步地被處理。問題的關鍵在於——盡管兩次玩家執行的命令一樣、順序一樣，甚至時間間隔都一樣，但是結果卻很不同——因為圖（1）裏面C2CS::Request_to_attack請求被處理的時候，C2IS::Request_equip_item 這個請求還沒有被處理完，但是圖（2）顯示的情況就不一樣了。因為C2IS::Request_equip_item這個操作很可能會改變遊戲人物的屬性，這個屬性又很可能影響attack的結果。這兩幅圖實際上省略了 Combat Server 與 Item Server 之間的交互過程。但是已經足以說明問題了，每個Service處理每個Request時具體會消耗的時間，是無法在設計時確定的!

誰喜歡這類結果上的不確定性？舉個例子：玩家很可能已經裝備上了“只能使用1次的魔獸必殺刀”然後攻擊了一下魔獸，但是它卻沒死！這會導致什麽樣的結果？請自行想象。另外，這種不確定性還會表現為“在項目開發期和運營期的行為差異”，或者“出現某些偶然的奇怪現象”。

那還有解決方案麽？有的，其實只要序列化玩 家請求的處理，使處理有序進行就可以了。但是又一次的，這會帶來新的復雜度——在某個範圍（整個服務器組？一個行會？一個隊伍？）內，以每個玩家為單位， 序列化他（們）的（可能是所有）操作，但是也顯而易見，這在某種程度上降低了請求處理的並發性，盡管它對並發性的影響可能只局限於不大（最少是一個玩家） 的範圍。

對Cells-based Architecture 的分析

基於Cell的架構有個明顯的優勢就是Cell如何劃分和你的策劃沒有關系J這是真的。而且Cell間如何交互可以被放到系統的底層，具體有多底層、多隱蔽（實際上可以隱蔽到對開發上層遊戲邏輯的程序員都不可見的程度）要看你的實現如何了。如果做到了某個系統的程序設計與遊戲設計完全無關的話，顯然，這個系統受到遊戲設計變更（需求變更）的影響就會很小很小，甚至會到完全不受影響的程度，當然這是理想情況。

關於跨邊界對象交互

在基於Cell的服務器架構裏面，實現無縫世界（Seamless World）的主要難點在於實現跨邊界對象的交互時會出現的一些問題，因為這些對象在不同的Cell進程裏面，這些Cell一般來說是在不同的物理服務器上運行。

無縫世界的特點自然就是無縫，並且因為無縫給玩家帶來更好的遊戲體驗，所以顯然我們希望“跨邊界對象交互”問題不把事情搞砸，那麽這種交互的表現就必須滿足穩定、高效的前提。一般來說，高於300ms的延遲對玩家操作來說就屬於“明顯可見”的程度了，不能讓玩家騎著500塊RMB買來的虛擬馬在一片大草原上面暢快的奔跑的時候，在某個地方突然就被“看不見的墻”給“擋”了一下，因為這“墻”根本看不見，所以會很影響“上帝”的遊戲心情。

關於組成整個虛擬世界的Cell之間的關系，下面來分析兩種情況：

一， Cell 承載的場景不重疊

如圖（1），一個連續的虛擬世界場景被分成左右兩塊，分別在不同的Cell Server上面運行。A、B、C分別是3個不同的遊戲角色。在這種情況下B與C的交互並不存在任何障礙，因為B和C只不過是同一個物理服務器上同一個進程內的兩塊不同的內存數據而已。但是A與B/C的交互就不那麽直接了，盡管他們所在的場景看上去是“連續的、一體的”但是事情不會像表面上那麽簡單。A與B發生交互時候會發生什麽事情？例如A攻擊了B、A與B交易物品等等，因為在這種結構下做數據同步會帶來很多問題，例如對象狀態不確定性、開發復雜度等等、相對來說兩個Cell Server之間做網絡通訊而帶來的延遲可能反而是最小的問題，這些問題不需要很復雜的分析就可以得出結論，在此不再多說了。

二，Cell 承載的場景（部分地）重疊

如圖（2），一個連續的虛擬世界場景被分成左右兩塊，分別在不用的Cell Server上面運行。A、B、C、D分別是4個不同的遊戲角色。這個情況下，中間的區域為2個Cell所共同維護，中間區域的對象同屬於2個Cell所‘擁有’。這有什麽好處？現在，任意兩個對象之間，除了A與C之間的交互，都變得更‘直接’了。變得直接肯定是一件好事兒，那麽A與C之間呢？他們之間其實也沒有任何問題J 因為雙方都已經超出了對方的Area of Interest（AoI）區域，遊戲規則可以限制他們不能直接交互。

上面提到的第二種方案算不上什麽魔法，但是肯定是比第一種方案更有效。接下來怎麽辦？假設B是個玩家，他站在中間這塊區域上面時，並不會產生“我到底是在哪裏”這樣的疑問J 問題的關鍵在於對於Cell Server來說，怎麽樣同步那些處於重疊區域對象的狀態。遊戲世界內的對象可能同時處於1個、2個、3個或者4個不同的Cell Server。如果你的Cell分隔方法不限於水平線和垂直線、或者有人故意搗亂的話，還可能會更多。需要被同步的對象也不只是玩家本身，還包括怪物、NPC、一顆會走的樹、某玩家在地上吐的痰等等。

由於我們的基於無縫世界的遊戲規則不大會直 接去限制遊戲世界某處玩家的行為，也就是說玩家如果能相互交易物品的話，他們肯定希望在任何地方都能交易，“為什麽其他地方都行，但是在某個墻角做交易就 會導致物品丟失？”所以比較可靠的方法是建立一套的用於同步的底層機制，來同步這些跨邊界對象。

怎麽實現？這個話題很大，恐怕再寫幾篇Blog我也講不完，但是有一些東西可以作為參考，例如：DCOM和CORBA規範，Java的RMI，基於Python的 PYRO，TAO(The ACE ORB)等等。好在分布式處理的問題不止是網絡遊戲會涉及到，可以借鑒的東西還是很多的。

總結

很顯然，這篇文章在兩種架構的評價上面存在某些傾向性，但是傾向性本身只是副產品。另外一個副產品就是關於一些技術分析方法。

在考慮采用何種技術的時候，我們往往很容易地就會忽略對程序之外那些事情的影響。上面我提到的關於Services-based架構實現的時候，提到劃分service及數據設計對程序設計能力的挑戰、對策劃設計的制約，對適應需求變更能力的影響，都不會只是空談。這些問題也不是只在實現這種架構的時候才出現。

不要高估自己的智商，Keep It Simple and Stupid :) 應該可以讓我們離成功更近一點兒。

【轉】無縫世界網遊服務器架構的設計思路