新一代MMO架構

                                               翻譯：趙月明

摘要

本文闡述了一種MMO架構的實現，架構充分利用了微線程和多核處理器，使服務器能夠承載更多的玩家。本方案使用erlang實現服務器集群，并將游戲世界實現分區。

I 介紹

MMOG（大型多人在線游戲）讓數千計甚至數以百萬計的人玩同一個游戲。新一代MMO 將提供一個高動態的游戲設計。讓游戲設計者的設計充分自由將提升了技術門檻。

Achterbosch,皮爾斯,西蒙斯(2008)，對下一代MMO期望是什么這兒問題調查了122人。

當問及到什么樣的特性是令人滿意的，受訪者提出了一些想法：

    作為6.2.1指出的，寧愿玩家影響世界，許多受訪者轉而提議：

世界靠其自身的自然環境事件發生改變。這些例子包括毀滅森林的火災，淹沒陸地的洪水，生長的植被，衰減的人類建筑和道路等等。這要創造一個身臨其境的世界，只是增加了晝夜循環和過去天氣的改變。燃燒的森林可能最終再生,洪水可能平息，還有npc(非游戲角色)可能維護衰退的地區,以至于世界沒有發生戲劇性的改變。

    另一個有趣但視為不可行的建議：許多受訪者相信他們的角色應該能夠產生影響,在游戲世界中,會永遠完全的改變它。一個任務中的部分生物和NPC，每一個玩家完成任務之后都要重置，以便下一個玩家完成同樣的任務。這通常被稱為重生。

當一個被殺的怪在世界里完全健康的重置，被稱為重生。一個參與調查者提出：開發者永遠改變世界，使怪或者任務不能重生。

問題是：早晚沒有任務留下，沒有怪獸留下去被殺死。因為玩家已經完成任務，并殺死了所有的怪獸。開發者必須趕在玩家完成之前，快速的創造出新的任務。 這是不可能的。

    游戲開發者不斷地創造新的內容視乎是不可行的，但是動態設計游戲能夠自動的搜索適當的時機建立任務。

動態NPC也是一項受訪者期望并有技術挑戰的特色。受訪者表示，NPC過于靜態，因此在提升游戲真實體驗方面，NPC應該進行一些日常的活動。如同在單人游戲里一樣被遺忘。

大多數情況下，友好的NPC晝夜閑站著等待玩家與他們溝通，在這種情況下他們只有一個目的，快速執行簡單的一句話，商店購物，或者給玩家一個任務。敵人的NPC趨向于站著等死。

一個受訪者建議，NPC可以被雇傭，做一些搜集資源保護建筑物的任務。

據一些受訪者所說，NPC除了站立還會有一個目的用途。

另一個受訪者建議：玩家應該有NPC敵人的選擇權，用很小的時間間隔來增大預測難度。就像龍與地下城中的地下城主的情況。

下一代的MMO特性要求架構先進, 允許動態游戲設計、分發和縮放。在大多數編程語言中，這是一個難以處理的任務。要開發滿足這些需求的服務，需要新工具和編程語言提供更好的支持。

如果這一需求能夠實現，玩家會有豐富的體驗，讓他們感覺到在自己的影響下，世界發生持續改變。

II 背景

基本上有兩種不同類型的MMOG架構：服務器-客戶端模式和點對點。

A客戶/服務器結構

通過(Cai, Xavier, Turner, and Lee, 2002) 和(Gil, Tavares, and Roque, 2005)的討論，集中服務器-客戶端實現是現在最普遍的MMO’S架構方案。每個玩家通過客戶端連接游戲服務。服務器可以驗證客戶端發送的所有信息和防作弊。，讓服務器處理所有的事件，可以非常容易的保持世界的一致性狀態。

問題是在于，當玩家連接足夠多時，服務器將耗盡硬件資源，然后拒絕更多的連接。解決這個問題最常見的方案是：分區，游戲復制到許多分區服務器上，這些服務器上存儲了數以千計的玩家，并維持他們在世界中的狀態。

負面效應是，玩家基地被孤立的分布在這些服務器上。意味著如果兩個朋友想在一起玩，他們必須在同一臺服務器上。另一個問題是平衡人口，如果服務器有很多玩家,人們不得不等待一個長隊來登錄。如果一個服務器玩家很少，人們可能很難有機會和其他玩家一起玩，這樣就降低了游戲的玩法。

B 點對點架構

分散的點對點實現是通過by (Hampel, Bopp, and Hinn, 2007) 和

(el Rhalibi and Merabti, 2005)提出的，他讓每個客戶端成為一個地理有限區域的服務器。這避免了使用集中服務的伸縮性問題，但很大程度上提升了作弊的風險，增大了所有玩家狀態連貫性維護的復雜性。

C  Erlang

Erlang 是一個內置并發性的語言，erlang為每一個對象或任務創建一個輕型進程，代替一個連續運行的主循環.每個進程都有其自己的主循環。依賴于硬件，一個普通的桌面計算機可以建立數以萬計的進程。Erlang附帶了一個稱為OTP（開放通信平臺）的平臺。為構建服務，OTP提供了通用的設計模式：狀態機、容錯系統、實行熱代碼升級。Erlang也有自己的分布式數據庫系統Mneisa.如果架構用c++或者java實現，這些特色必須從頭開發或者

借助于第三方庫。 erlang 代碼被組織在被稱為模塊的文件里，模塊里是被寫好的函數。據（Nystr?m, 2004）說，選擇erlang為實現語言，通過使用其輕量級的進程就能使服務器的性能得到顯著提升。

D 理論研究

在近期流行的這些游戲中,有許多對提升MMO的研究。與本架構最相關的是對世界分區的研究。此研究就是在本章節中對討論和批評。

有兩個商業項目Eve Online (CCP) 和 Second Life (Linden Lab)使用了將世界分成子區域的技術。

研究論文如(Chen, Wu, Knutsson, Lu, and Amza, 2005), (Yamamoto, Murat, Yasumoto, and Ito, 2005) 和 (Bossche, Verdickt, and Vleeschauwer, 2006)提到以允許架構平衡的方式將游戲劃分成一些子區域。當一個子區域變得有負載的時候，建議移植到新的服務器。使用這樣一個伸縮性的限制，一個子地區的玩家數量不可能超過計算機負載人數上限。By assigning the computers to sub areas instead removes this limitation. (聯系上下文，沒翻譯出來)。所需要的是子區域狀態必須分布在指定的計算機上。

E 商業項目

EvE在線是一個發生在太空的游戲。架構將世界劃分為若干子地區（星系）。集群包括刀片服務器，也稱為節點。每個星系駐留在一個節點上。若干星系可以共享一個節點。玩家在節點間無縫轉移。當一個玩家“跳”到另一個恒星系統,一個加載屏幕出現而轉移發生。

據稱，約60名玩家一起參加戰斗足以搞垮一個節點。如果節點移動到一臺專業的服務器上，大約能夠負載大約1000次戰斗或者交換玩家。利用機器所有的CPU內核資源是一個令開發者感到棘手問題。在集群中，有大約五成的內核處于閑置狀態。?insertref? 是 EvE 服務器實現所用的命令式設計語言 python的東西。 Python開發人員稱之為“全局解釋器鎖”。在其內部主要部分沒有重新設計的情況下，他有效的阻止Python使用多核。

第二人生（游戲名稱）也有類似的地區服務器架構。當無縫轉移玩家時，他們穿過了世界。沒有前端集群服務器為客戶端進行通訊。客戶端保持四個連接，連接最近的四個地區服務器。

地區服務器將所有數據流實時傳給玩家，沒有內容保存硬盤，這樣使客戶端會很小。

III  推薦建構

如圖1所示:架構由四個類型的服務器通過一個計算機集群組成。服務器由：鏈接服務器，賬戶服務器，角色服務器，區域服務器。這些服務器運行在一個計算機網絡（局域網）的不同服的計算機上。然而這不是必需的，所有的服務器也可以配置部署在同一臺計算機上。服務器軟件用Erlang實施，因為他具有并發、容錯和分布式特性。客戶端通過互聯網鏈接到鏈接服務器鏈接服務器操縱客戶端和其他服務器之間的通訊。該帳戶服務器包含用于驗證登錄的賬戶信息。所有的玩家角色存儲在角色服務器上，角色是玩家在游戲中的替身或者實體。地區服務器應該運行的像一個地理網格連接地區。如圖2所示, 他們在一起，是一個玩家相互作用的世界。每個服務器運行在一個由名稱、@和主機名稱組成的節點上。例如：完整的節點名稱是start_area@myserver。 start_area是節點名，myserver是主機名。節點名作用于運行在不同計算機上的服務器之間的通訊。

A 客戶端

客戶端是運行在玩家計算機上的程序。通過互聯網與鏈接服務器建立鏈接。客戶端是系統中非常重要的部分，但不屬于架構的內容。只要是能夠建立TCP鏈接，能夠與服務器發送和接受數據的語言就能實現。客戶端的目的是通過圖像或者文本接口為玩家展示世界。

B 鏈接服務器

    鏈接服務器等待客戶端的鏈接，服務于集群的前端。客戶端從不會直接與其他服務器直接通訊，所有與客戶端的通訊必須通過鏈接服務器。為每個客戶端創建一個鏈接進程。鏈接進程是一個在四種狀態間變化的簡單有限狀態機。

*鏈接狀態：客戶端已經建立一個鏈接，但是沒有發送任何進一步的指令請求。

*大廳狀態：客戶端已經登錄賬號，瀏覽或者在游戲中建立了實體。

*玩：客戶端已經用一個實體聯機，目前正在游戲中玩。

*鏈接丟失狀態：客戶端已經失去鏈接。鏈接服務器保持玩家有效，給他一個再次登錄的機會繼續玩游戲。當斷開時間超時，鏈接服務器斷開session并終止。

C  賬戶服務器

如圖3所示：賬戶服務器在一個Mneisa數據庫中存儲了所有的用戶賬號信息。如圖3所示：賬戶服務器在一個Mneisa數據庫中存儲了所有的用戶賬號信息。通過賬號和密碼驗證玩家的合法性。

 D  角色服務器

        如圖4所示：角色服務器存儲了所有的角色數據。每個賬戶能創建能夠登陸游戲世界的新角色。服務器提供了保存和創建新角色的功能。

E 地區服務器

地區服務器是集群中最復雜的服務器。他管理一個世界中的一個地區。為在地區服務器加載完成的每一個角色或對象，創建一個保存其狀態的進程。圖5闡述此過程。在游戲世界里，每個進程有一個通過erlang生成的自定義id和一個作為唯一標示id。唯一標示id和進程id存儲在一個用來查詢對象的數據庫中。

F 動態特性

如圖6所示，地區服務器有一個模塊化的構建。它核心是僅僅提供了一個簡單事件注冊和啟動與選擇函數庫的能力。這些庫依次為地區服務器提供所有的功能。這些函數庫在運行時，可以編譯、重新編譯、啟動和停止。他們為開發和測試提供了新類庫，例如一個戰斗系統無需重新啟動服務器。

架構提供了三個默認庫：

* libstd:這個庫提供了基本的功能，如注冊/檢索對象、對象記錄和熱代碼升級。

* libchar:這個庫允許角色在地區服務器登錄。

*libdist: 這個庫允許一個地區服務在集群中跨多個計算機分發。

注意不是直接啟動庫，而是啟動他們的監督者。依次啟動庫以及庫運行所需要的其他任何進程。這樣，模塊libstd_sup提供了一個開始函數代替libstd。在erlang中，監督者是一個監督其他進程的的進程，如果一個進程崩潰，監督者進程會重啟它。下面是一個命令啟動一個庫展示：

用下面的命令關閉一個庫：

另一個動態特性被稱為熱代碼交換。這使得Erlang在運行的同時升級代碼。為此，一個名為upgrade的函數被添加到類庫libstd。接下來一個例子，對模塊libchar做了修改之后，新的代碼成功編譯，通過以下命令完成升級：

Erlang允許兩個版本的代碼同時運行。當升級函數被調用的模塊作為參數時，erlang讓當前運行的代碼為舊的，讓已升級的作為現在的。升級之后，當前代碼（新）被使用，原來執行舊代碼的所有進程，在下個函數調用時將被升級。

G 分布

數臺電腦可以管理同一個地區服務器。如圖7中，兩臺分別名為server1和server2的計算機運行各自名為start_area節點。運行下面的命令，從節點start_area@server2將關聯位于start_area@server1的分布式對象記錄。

分布式對象記錄是一個Mnesia數據庫，存儲的信息和本地對象記錄一樣，不同之處是分布式對象記錄不只是包含本地進程，還有所有地區服務器中的管理同一個地區的所有進程。（不知道翻譯的對不對）

如果start_area@server2往分布式對象記錄中寫數據，erlang也同樣將修改同步到start_area@server1。erlang進程id在本地是透明的，這就意味著如果進程運行在同一個本地機器或者同一個網絡中的另一臺計算機，他們的通訊是沒有問題的。分布式注冊對象表將start_area@server1和start_area@server2鏈接在一起，這就使他們如同在同一個地區服務器上操作一樣。

G1  負載均衡

libdist庫提供動態負載分布的特征

當管理同一片區域的所有服務器開啟時更新分布式Mnsia表。分布式庫通過檢查本地區域節點負載 與 表中的最少負載的節點進行對比。如果負載差值等于或大于1時，則節點開始將一半的進程移動到負載最小的地區服務器上去。

 G.2 遷移

分布式的增加，在系統運行時，使客戶端沒有任何察覺的情況下，角色在從一臺服務器遷徙到另一臺服務器成為可能。下面解釋如何遷移：

如圖8所示，一個對象接收到一個將要遷徙到另外一個節點的消息。這個消息通常是由分布式庫 libdist 發送，但也可以通過以下命令從節點手動發送。

如圖9所示：在遷徙目標節點，當收到一個遷徙消息時，當前對象進程開始一個帶有相等id和狀態的新進程。新進程id被返回到位于start_area@server2上舊的進程。當一個新進程被創建，他覆蓋了當前在全局注冊表中擁有自己進程id的數據條目，因此所有的消息應該發給他自己。

圖10所描述，這時，即使所有消息仍然發送給舊的進程，舊的進程會轉發給新的進程。

圖11所示, 如果舊進程一秒鐘之內無法接受新的消息，將殺死自己，我們認為遷移是成功的。

IV 效果

用于測試的服務器處理器Phenom(tm) II X4 940，8G內存。地區的大小為10000公尺，在一個625公尺的四邊形中，四叉樹將世界拆分成256個四邊形。在測試中，地區里生成了一些機器人對象。機器人大約每7.5秒（5+5秒內隨即）前后移動改變方向。

每個動作更新都要發送給在同一區塊中的其他機器人對象，這就意味著與系統中機器人數量相比，消息數量是呈指數增長的。

A  CPU負載

圖12展示了在系統中機器人增長同時所有CPU核心的負載情況。CPU負載呈指數增長，當24000個并發機器人運行時，所有的核心負載都接近了100%。

當機器人達到24000時，在一個四邊形區塊中每秒鐘處理1178個消息，在整個地區服務器中，每秒鐘處理了301568個消息。

B 內存負載

在圖13中顯示的是鏈接服務器，角色服務器、賬戶服務器和地區服務器的內存負載情況。

當24000個并發機器人運行時，地區服務器使用內存619M的時候。其他服務器內存負載基本保持不變，仍然在40-43M之間。

C 視覺效果

當一個客戶端登陸，大約60-80個機器人被做了統計。視覺定時被用來檢查所有明顯視覺延遲。根據不同的負載水平，隨即挑選一些機器人，他們的運動變化在iphone上面同步。6000機器人在地區服務器上時，平均運動變化時間是7.1秒。（我應該估量一下12000和24000個機器人時的情況，但在機器人中做了一個日志功能來代替手動計時。）

V討論

    測試數以千計的客戶端在現實的環境是一個問題,因為很難獲得如此數量的計算機。從同一臺計算機上運行數以千計的客戶端可能會造成瓶頸，不是每個客戶端都有他們自己的計算機。所有的測試計算機都通過同一個局域網內連接，真實的生產環境或許不會是這樣的。當從世界各地通過互聯網連接時，響應時間可能會增加。（我還未測試這些）。在這種情況下，服務器集群的地理位置也會影響到客戶端的響應時間。

當游戲的特性數據向進程狀態增加時，地區服務器的內存消耗可能會增加。在測試時，地區服務器的進程中有一個極小的狀態，可以充分的管理角色登陸和遷徙過程。

在沒有檢查探測已經登陸的賬戶或者角色，又或者角色是否屬于賬號的登陸之前，賬號和角色登陸序列是不安全的。（感覺沒翻譯清楚。）

將世界劃分在地區服務器中可能并不是最好的方案。一個更好的方式是做出一個模型：對統一服務器做一個繼承，分支出包含區域/太陽系系統的銀河服務器，同樣區域/太陽系系統包含星球服務器，星球服務器又被劃分成區域服務器。該方法將可以使它通過自上而下的方式更加容易的分發消息。這將使星際旅行甚至從星球表面到它周圍太空的無縫運動變得如此簡單。

VI     結論和未來工作

原文件Pdf下載： Next_Generation_MMO_Architecture.zip   

nextgen架構官網：http://www.next-gen.cc

由于本人英文水平太爛，本文完全是為學習之用的業余翻譯。希望對大家有用~~  文章難免多處錯誤，歡迎批評指正。

若轉載，請附上原文鏈接：http://blog.chinaunix.net/uid-429659-id-3396370.html