深入淺出node.js遊戲伺服器開發——Pomelo框架的設計動機與架構介紹

文章介紹了Pomelo框架的設計動機與架構。pomelo在開社區才剛剛起步， 僅僅不到半年時間pomelo已經在github和各類社區上積累了強大的人氣，1700多的watcher在github已經是相當不錯的戰績。

【InfoQ/作者：謝騁超】

一、Pomelo的定義和組成

以下是Pomelo官網給出的最初定義：Pomelo是基於node.js的高性能,分散式遊戲伺服器框架。它包括基礎的開發框架和相關的擴展組件（庫和工具包），可以幫助你省去遊戲開發枯燥中的重複勞動和底層邏輯的開發。

Pomelo最初的設計初衷是為了遊戲伺服器， 不過我們在設計、開發完成後發現pomelo是個通用的分散式實時應用開發框架。它的靈活性和可擴展性使pomelo框架有了更廣闊的應用範圍。 由於強大的可能伸縮性和靈活性，pomelo在很多方面甚至超越了現有的開源實時應用框架。

如果你瀏覽一下網易的github，會發現pomelo遠遠不止是一個repository， 它是由一系列松耦合的組件組合在一起的，包括了各類demo， 各類客戶端，各種庫和工具。

下圖是pomelo最初的組成圖：

pomelo包括以下幾部分:

>框架, 框架是pomelo最核心的部分。

>庫，pomelo提供了很多庫，有些是跟遊戲邏輯完全相關的，如AI，AOI，尋路等；也有與遊戲邏輯無關的，如定時任務執行， 數據同步。

>工具，pomelo提供了管理控制台、命令行工具、壓力測試工具等一系列工具。

>各類客戶端， pomelo提供了各類平台的客戶端，包括js, C, android, iOS, unity3d等，這些都可以從pomelo的官方主頁查到。

>Demo， 一個框架需要強大的demo來展示功能，pomelo提供了全平台的聊天demo和基於HTML5的撿寶Demo，系統還提供了一個強大的基於HTML5開發的強大的MMO遊戲demo Lord Of Pomelo。

而最妙的地方在於所有這些組件都是松耦合的，所有這些組件都可以獨立使用。這使pomelo框架異常靈活，可 由於篇幅有限，本篇文章只討論pomelo框架。

二、遊戲伺服器開發架構分析

2.1 遊戲伺服器運行架構

從單進程到多進程最初的網路伺服器是單進程的架構，所有的邏輯都在單台伺服器內完成， 這對於同時在線要求不高的遊戲是可以這麼做的。由於同時在線人數的上升， 單伺服器的可伸縮性必然受到挑戰。

隨著網路遊戲對可伸縮性要求的增加，分散式是必然的趨勢的。

遊戲伺服器與web應用的不同遊戲伺服器的分散式架構與Web伺服器是不同的， 以下是web伺服器與遊戲伺服器架構的區別：

>長連接與短連接。web應用使用基於http的短連接以達到最大的可擴展性，遊戲應用採用基於socket(websocket)的長連接，以達到最大的實時性。

>分區策略不同。web應用的分區可以根據負載均衡自由決定， 而遊戲則是基於場景(area)的分區模式， 這使同場景的玩家跑在一個進程內， 以達到最少的跨進程調用。

>有狀態和無狀態。web應用是無狀態的， 可以達到無限的擴展。 而遊戲應用則是有狀態的， 由於基於場景的分區策略，它的請求必須路由到指定的伺服器， 這也使遊戲達不到web應用同樣的可擴展性。

>廣播模式和request/response模式。web應用採用了基於request/response的請求響應模式。而遊戲應用則更頻繁地使用廣播， 由於玩家在遊戲里的行動要實時地通知場景中的其它玩家， 必須通過廣播的模式實時發送。這也使遊戲在網路通信上的要求高於web應用。

因此，同樣是多進程架構，Web應用與遊戲應用的運行架構也完全不同， 下圖是通常web應用與遊戲應用的不同運行架構：

以上的遊戲伺服器運行架構中只是個示意圖， 現在實情況比這複雜很多。

走向分散式開發可以看到由於web伺服器的無狀態性，只需要通過前端的負載均衡器可以導向任意一個進程，因此運行架構相對簡單， 而且很少需要分散式開發。

而遊戲伺服器是蜘蛛網式的架構，每個進程都有各自的職責，這些進程的交織在一起共同完成一件任務。

因此遊戲伺服器是一個標準的分散式開發架構。

2.2 分散式開發與難點

幾乎在很多書、演講和文章中都可以看到這樣的觀點： 分散式開發是很難的。 如果把所有這些難點都合起來也許有好幾本書，我們今天著重看來一下遊戲伺服器開發的難點吧。

多進程（伺服器）的管理，重量級的架構影響開發效率通常的遊戲伺服器要由很多進程共同去完成任務。當這些進程交織在一起的時候，多進程的管理並不那麼容易。

如果沒有統一的抽象與管理，光把這些開發環境的進程啟動起來就是非常複雜的工作， 進程的啟動與重啟就將嚴重影響開發效率。重量級的進程消耗大量的機器資源，普通的開發機支撐不了那麼多進程，可能一個人的開發環境就需要多台機器。多進程間的調試並不容易， 我們發現一個bug就要跨好幾個進程。rpc調用rpc調用的解決方案已經有n多年的歷史了，但rpc在分散式開發效率上仍然沒有明顯提升。

以當前最流行的開發框架thrift為例，它在調用代碼前需要經過以下步驟：

Writing a .thrift file

Generate Thrift file to source code

thrift --gen (language) (Thrift filename)

Copy the source to application

如果發生介面改動，我們又需要重新修改描述文件，重新生成stub介面。對於介面不穩定的開發環境， 這種方式對開發效率影響較大。

要想讓rpc調用的開發達到最簡，不需生成stub介面， 無需描述文件， 我們需要一種很巧妙的方法。

分散式事務、非同步化操作儘管我們盡量把邏輯放在一個進程里處理，但分散式事務仍然是不可避免的。兩階段提交的代碼，非同步化的操作在普通的開發語言里並不是容易的事。

但我們會發現用了node.js之後，它的編程模式里天生就是這種模式， 兩階段提交、非同步化操作這些看似複雜的工作里在node.js只是一個正常的非同步執行流程。

負載均衡，高可用由於遊戲伺服器的有狀態性，很多請求需要通過特定的路由規則導到某台伺服器；對於有些無狀態的伺服器，我們則可以把請求路由到負載最低的伺服器。

通常對於無狀態的伺服器， 高可用是比較好做的。對於有狀態的伺服器，要做高可用會非常困難， 但也不是完全沒有辦法，常見的兩招：

將狀態引出到外存，例如redis， 這樣進程本身就可以無狀態了。但由於所有的操作都通過redis可能帶來性能損耗，有些場景是不能應會這些損耗的。通過進程互備， 將狀態通過日誌等方式同步到另一進程， 但這可能存在著瞬間數據丟失的問題，這種數據丟失在一些應用場景可能毫無問題， 但在另外一些應用場景可能引起嚴重的數據不一致。有狀態的高可用並不是那麼好實現的，pomelo將在0.5版本提供高可用的實現機制，引入zookeeper和redis可以解決一些進程（如master）的高可用問題，但真正複雜的應用場景的邏輯只能由應用自己處理。

2.3 Node.js的引入

為什麼會在這裡談node.js的引入？ 因為在講了這麼多分散式開發的難點之後，引入node.js實在是太自然了。它解決了分散式開發的很多問題。

天生的分散式, node.js之所以叫node就是因為它天生就是做多進程開發的， 多個節點(node)互相通訊交織在一起組成的分散式系統是node天生就應該這麼乾的。例如前面提到的分散式事務、非同步化操作在node.js里只是個正常的流程。網路io與可伸縮性的優勢。遊戲是非常io密集型的應用， 採用node.js是最合適的， 可達到最好的可伸縮性。輕量級, 輕量級的進程帶來的開發效率的優勢在開發的時候異常明顯。語言優勢。使用javascript開發可以實現快速迭代，客戶端html 5使用javascript，甚至在unity3d，cocos2d-x這樣的遊戲平台上也可以使用javascript, 可實現最大限度的代碼共用。

三、pomelo架構分析

pomelo框架在最初設計的時候只為了一個目標：為基於長連接的分散式遊戲伺服器架構提供基礎設施。框架的內容在逐漸擴展，但最核心的框架只為了干以下三件事：

伺服器（進程）的抽象與擴展在web應用中， 每個伺服器是無狀態、對等的， 開發者無需通過框架或容器來管理伺服器。 但遊戲應用不同， 遊戲可能需要包含多種不同類型的伺服器，每類伺服器在數量上也可能有不同的需求。這就需要框架對伺服器進行抽象和解耦，支持伺服器類型和數量上的擴展。

客戶端的請求、響應、廣播客戶端的請求、響應與web應用是類似的， 但框架是基於長連接的， 實現模式與http請求有一定差別。 廣播是遊戲伺服器最頻繁的操作， 需要方便的API， 並且在性能上達到極致。

伺服器間的通訊、調用儘管框架盡量避免跨進程調用，但進程間的通訊是不可避免的， 因此需要一個方便好用的RPC框架來支撐。

下面分別對這三個目標進行詳細的分析：

伺服器（進程）的抽象與擴展介紹

伺服器的抽象與分類

該架構把遊戲伺服器做了抽象， 抽象成為兩類：前端伺服器和後端伺服器， 如圖：

前端伺服器(frontend)的職責：

>負責承載客戶端請求的連接

>維護session信息

>把請求轉發到後端

>把後端需要廣播的消息發到前端

後端伺服器(backend)的職責：

>處理業務邏輯， 包括RPC和前端請求的邏輯

>把消息推送回前端

伺服器的鴨子類型

動態語言的面向對象有個基本概念叫鴨子類型 伺服器的抽象也同樣可以比喻為鴨子， 伺服器的對外介面只有兩類， 一類是接收客戶端的請求， 叫做handler， 一類是接收RPC請求， 叫做remote， handler和remote的行為決定了伺服器長什麼樣子。 因此我們只要定義好handler和remote兩類的行為， 就可以確定這個伺服器的類型。

伺服器抽象的實現利用目錄結構與伺服器對應的形式， 可以快速實現伺服器的抽象。

以下是示例圖：

圖中的connector, connector, gate三個目錄代表三類伺服器類型， 每個目錄下的handler與remote決定了這個伺服器的行為（對外介面）。 開發者只要往handler與remote目錄填代碼， 就可以實現某一類的伺服器。這讓伺服器實現起來非常方便。 讓伺服器動起來， 只要填一份配置文件servers.json就可以讓伺服器快速動起來。 配置文件和對應的進行架構如下所示：

客戶端請求與響應、廣播的抽象介紹

所有的web應用框架都實現了請求與響應的抽象。儘管遊戲應用是基於長連接的， 但請求與響應的抽象跟web應用很類似。 下圖的代碼是一個request請求示例：

請求的api與web應用的ajax請求很象，基於Convention over configuration的原則， 請求不需要任何配置。 如下圖所示，請求的route字元串：chat.chatHandler.send， 它可以將請求分發到chat伺服器上chatHandler文件定義的send方法。

Pomelo的框架里還實現了request的filter機制，廣播/組播機制，詳細介紹見pomelo框架參考。

伺服器間RPC調用的抽象介紹架構中各伺服器之間的通訊主要是通過底層RPC框架來完成的，該RPC框架主要解決了進程間消息的路由和RPC底層通訊協議的選擇兩個問題。 伺服器間的RPC調用也實現了零配置。實例如下圖所示：

上圖的remote目錄里定義了一個RPC介面： chatRemote.js，它的介面定義如下：

chatRemote.kick = function(uid, player, cb) {}

其它伺服器（RPC客戶端）只要通過以下介面就可以實現RPC調用：

app.rpc.chat.chatRemote.kick(session, uid, player, function(data){});

這個調用會根據特定的路由規則轉發到特定的伺服器。（如場景服務的請求會根據玩家在哪個場景直接轉發到對應的server）。

rpc的使用遠比其它rpc框架簡單好多，因為我們無需寫任何配置文件，也無需生成stub。因為我們伺服器抽象的實現的方式，使得rpc客戶端可以在應用啟動時掃描伺服器目錄自動生成stub對象。

完成了以上三個目標， 一個實時的分散式應用框架的輪廓就搭出來了，剩下的工作是往上添肉，這是我們後續文章里的內容。

四、從遊戲框架到實時應用框架

當我們分析完pomelo框架的設計目標時， 我們發現核心框架的這件事情竟然與遊戲沒有任何關係。這是一個通用的實時分散式應用開發框架。官網上的聊天伺服器demo就是一個實時應用。

事實上pomelo已經被應用在很多非遊戲領域。 網易的消息推送平台是基於pomelo開發的，它承擔了網易移動端和web端的消息推送， 目前已經上線使用。

整個開源社區沒有與pomelo定位相同的實時應用框架。目前在開源社區最流行的實時應用框架當數meteor，它與pomelo有著截然不同的設計目標。我們來比較一下這兩個框架的區別。

以下是meteor給出的定義：

Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you"re an expert developer or just getting started.

可以用以下兩點概括：

meteor是只能面向web的實時應用meteor最關注的是開發效率但是我們的問題是：

現在的實時應用有多少是只面向web端的?規模稍大的實時應用，瓶頸是在可伸縮性、性能還是在開發效率？我們給出的答案是：

同時支持移動端、web端、PC端的實時應用已經是主流相比開發效率，可伸縮性、性能是規模較大的實時應用更有可能出現的瓶頸而pomelo在這兩方面具有明顯的優勢：

pomelo支持動態connector協議機制，使它同時支持web、移動、PC、untiy3d等各類客戶端。開發無縫衍接各類客戶端的高時應用在pomelo裡面只是個配置問題pomelo在可伸縮性和擴展上具有很強的優勢，這也是pomelo設計的最根本目標以上的比較並不說明pomelo比meteor優秀， 它們是完全定位不同的兩個實時應用框架。相信用戶會根據自己的需求做出選擇。

五、未來與展望

pomelo在開社區才剛剛起步， 僅僅不到半年時間pomelo已經在github和各類社區上積累了強大的人氣，1700多的watcher在github已經是相當不錯的戰績。但這僅僅只是個起步，pomelo的真正的暴發期還未到來。

pomelo將會在分散式開發方面下更大的功夫，在加強高可用、負載均衡、過載保護、運維機制等方面做得更好.

pomelo也逐漸在世界的開源社區推廣。LXJS 2013的組織者邀請了筆者於2013年10月去葡萄牙里斯本做英文演講，可見pomelo已經逐漸受到了國際node社區的牛人關注。當然這還只是個開始。

（關注更多鈦媒體作者觀點，參與鈦媒體微信互動（微信搜索「鈦媒體」或「taimeiti」））

來自：http://www.tmtpost.com/45809.html