http://www.infoq.com/cn/articles/design-motivation-and-introduction-of-Pomelo-framework
一、Pomelo的定義和組成以下是Pomelo官網給出的最初定義：Pomelo是基于node.js的高性能,分布式游戲服務器框架。它包括基礎的開發框架和相關的擴展組件（庫和工具包），可以幫助你省去游戲開發枯燥中的重復勞動和底層邏輯的開發。
Pomelo最初的設計初衷是為了游戲服務器， 不過我們在設計、開發完成后發現pomelo是個通用的分布式實時應用開發框架。它的靈活性和可擴展性使pomelo框架有了更廣闊的應用范圍。 由于強大的可能伸縮性和靈活性，pomelo在很多方面甚至超越了現有的開源實時應用框架。
如果你瀏覽一下網易的github，會發現pomelo遠遠不止是一個repository， 它是由一系列松耦合的組件組合在一起的，包括了各類demo， 各類客戶端，各種庫和工具。
下圖是pomelo最初的組成圖：
pomelo包括以下幾部分:
相關贊助商
QCon北京2016大會，4月21-23日，北京·國際會議中心，精彩內容邀您參與！
- 框架, 框架是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社區的牛人關注。當然這還只是個開始。
posted on 2016-03-14 09:15
思月行云 閱讀(558)
評論(0) 編輯 收藏 引用 所屬分類:
Node.js