http://www.infoq.com/cn/articles/design-motivation-and-introduction-of-Pomelo-framework
一、Pomelo的定義和組成以下是Pomelo官網(wǎng)給出的最初定義：Pomelo是基于node.js的高性能,分布式游戲服務(wù)器框架。它包括基礎(chǔ)的開發(fā)框架和相關(guān)的擴展組件（庫和工具包），可以幫助你省去游戲開發(fā)枯燥中的重復(fù)勞動和底層邏輯的開發(fā)。
Pomelo最初的設(shè)計初衷是為了游戲服務(wù)器， 不過我們在設(shè)計、開發(fā)完成后發(fā)現(xiàn)pomelo是個通用的分布式實時應(yīng)用開發(fā)框架。它的靈活性和可擴展性使pomelo框架有了更廣闊的應(yīng)用范圍。 由于強大的可能伸縮性和靈活性，pomelo在很多方面甚至超越了現(xiàn)有的開源實時應(yīng)用框架。
如果你瀏覽一下網(wǎng)易的github，會發(fā)現(xiàn)pomelo遠(yuǎn)遠(yuǎn)不止是一個repository， 它是由一系列松耦合的組件組合在一起的，包括了各類demo， 各類客戶端，各種庫和工具。
下圖是pomelo最初的組成圖：
pomelo包括以下幾部分:
相關(guān)贊助商
QCon北京2016大會，4月21-23日，北京·國際會議中心，精彩內(nèi)容邀您參與！
- 框架, 框架是pomelo最核心的部分。
- 庫，pomelo提供了很多庫，有些是跟游戲邏輯完全相關(guān)的，如AI，AOI，尋路等；也有與游戲邏輯無關(guān)的，如定時任務(wù)執(zhí)行， 數(shù)據(jù)同步。
- 工具，pomelo提供了管理控制臺、命令行工具、壓力測試工具等一系列工具。
- 各類客戶端， pomelo提供了各類平臺的客戶端，包括js, C, android, iOS, unity3d等，這些都可以從pomelo的官方主頁查到。
- Demo， 一個框架需要強大的demo來展示功能，pomelo提供了全平臺的聊天demo和基于HTML5的撿寶Demo，系統(tǒng)還提供了一個強大的基于HTML5開發(fā)的強大的MMO游戲demo Lord Of Pomelo。
而最妙的地方在于所有這些組件都是松耦合的，所有這些組件都可以獨立使用。這使pomelo框架異常靈活，可 由于篇幅有限，本篇文章只討論pomelo框架。
二、游戲服務(wù)器開發(fā)架構(gòu)分析
2.1 游戲服務(wù)器運行架構(gòu)
從單進(jìn)程到多進(jìn)程
最初的網(wǎng)絡(luò)服務(wù)器是單進(jìn)程的架構(gòu)，所有的邏輯都在單臺服務(wù)器內(nèi)完成， 這對于同時在線要求不高的游戲是可以這么做的。由于同時在線人數(shù)的上升， 單服務(wù)器的可伸縮性必然受到挑戰(zhàn)。
隨著網(wǎng)絡(luò)游戲?qū)缮炜s性要求的增加，分布式是必然的趨勢的。
游戲服務(wù)器與web應(yīng)用的不同
游戲服務(wù)器的分布式架構(gòu)與Web服務(wù)器是不同的， 以下是web服務(wù)器與游戲服務(wù)器架構(gòu)的區(qū)別：
- 長連接與短連接。web應(yīng)用使用基于http的短連接以達(dá)到最大的可擴展性，游戲應(yīng)用采用基于socket(websocket)的長連接，以達(dá)到最大的實時性。
- 分區(qū)策略不同。web應(yīng)用的分區(qū)可以根據(jù)負(fù)載均衡自由決定， 而游戲則是基于場景(area)的分區(qū)模式， 這使同場景的玩家跑在一個進(jìn)程內(nèi)， 以達(dá)到最少的跨進(jìn)程調(diào)用。
- 有狀態(tài)和無狀態(tài)。web應(yīng)用是無狀態(tài)的， 可以達(dá)到無限的擴展。 而游戲應(yīng)用則是有狀態(tài)的， 由于基于場景的分區(qū)策略，它的請求必須路由到指定的服務(wù)器， 這也使游戲達(dá)不到web應(yīng)用同樣的可擴展性。
- 廣播模式和request/response模式。web應(yīng)用采用了基于request/response的請求響應(yīng)模式。而游戲應(yīng)用則更頻繁地使用廣播， 由于玩家在游戲里的行動要實時地通知場景中的其它玩家， 必須通過廣播的模式實時發(fā)送。這也使游戲在網(wǎng)絡(luò)通信上的要求高于web應(yīng)用。
因此，同樣是多進(jìn)程架構(gòu)，Web應(yīng)用與游戲應(yīng)用的運行架構(gòu)也完全不同， 下圖是通常web應(yīng)用與游戲應(yīng)用的不同運行架構(gòu)：
以上的游戲服務(wù)器運行架構(gòu)中只是個示意圖， 現(xiàn)在實情況比這復(fù)雜很多。
走向分布式開發(fā)
可以看到由于web服務(wù)器的無狀態(tài)性，只需要通過前端的負(fù)載均衡器可以導(dǎo)向任意一個進(jìn)程，因此運行架構(gòu)相對簡單， 而且很少需要分布式開發(fā)。
而游戲服務(wù)器是蜘蛛網(wǎng)式的架構(gòu)，每個進(jìn)程都有各自的職責(zé)，這些進(jìn)程的交織在一起共同完成一件任務(wù)。
因此游戲服務(wù)器是一個標(biāo)準(zhǔn)的分布式開發(fā)架構(gòu)。
2.2 分布式開發(fā)與難點
幾乎在很多書、演講和文章中都可以看到這樣的觀點： 分布式開發(fā)是很難的。 如果把所有這些難點都合起來也許有好幾本書，我們今天著重看來一下游戲服務(wù)器開發(fā)的難點吧。
多進(jìn)程（服務(wù)器）的管理，重量級的架構(gòu)影響開發(fā)效率
通常的游戲服務(wù)器要由很多進(jìn)程共同去完成任務(wù)。當(dāng)這些進(jìn)程交織在一起的時候，多進(jìn)程的管理并不那么容易。
- 如果沒有統(tǒng)一的抽象與管理，光把這些開發(fā)環(huán)境的進(jìn)程啟動起來就是非常復(fù)雜的工作， 進(jìn)程的啟動與重啟就將嚴(yán)重影響開發(fā)效率。
- 重量級的進(jìn)程消耗大量的機器資源，普通的開發(fā)機支撐不了那么多進(jìn)程，可能一個人的開發(fā)環(huán)境就需要多臺機器。
- 多進(jìn)程間的調(diào)試并不容易， 我們發(fā)現(xiàn)一個bug就要跨好幾個進(jìn)程。
rpc調(diào)用
rpc調(diào)用的解決方案已經(jīng)有n多年的歷史了，但rpc在分布式開發(fā)效率上仍然沒有明顯提升。
以當(dāng)前最流行的開發(fā)框架thrift為例，它在調(diào)用代碼前需要經(jīng)過以下步驟：
Writing a .thrift file
Generate Thrift file to source code
thrift --gen (language) (Thrift filename)
Copy the source to application
如果發(fā)生接口改動，我們又需要重新修改描述文件，重新生成stub接口。對于接口不穩(wěn)定的開發(fā)環(huán)境， 這種方式對開發(fā)效率影響較大。
要想讓rpc調(diào)用的開發(fā)達(dá)到最簡，不需生成stub接口， 無需描述文件， 我們需要一種很巧妙的方法。
分布式事務(wù)、異步化操作
盡管我們盡量把邏輯放在一個進(jìn)程里處理，但分布式事務(wù)仍然是不可避免的。兩階段提交的代碼，異步化的操作在普通的開發(fā)語言里并不是容易的事。
但我們會發(fā)現(xiàn)用了node.js之后，它的編程模式里天生就是這種模式， 兩階段提交、異步化操作這些看似復(fù)雜的工作里在node.js只是一個正常的異步執(zhí)行流程。
負(fù)載均衡，高可用
由于游戲服務(wù)器的有狀態(tài)性，很多請求需要通過特定的路由規(guī)則導(dǎo)到某臺服務(wù)器；對于有些無狀態(tài)的服務(wù)器，我們則可以把請求路由到負(fù)載最低的服務(wù)器。
通常對于無狀態(tài)的服務(wù)器， 高可用是比較好做的。對于有狀態(tài)的服務(wù)器，要做高可用會非常困難， 但也不是完全沒有辦法，常見的兩招：
- 將狀態(tài)引出到外存，例如redis， 這樣進(jìn)程本身就可以無狀態(tài)了。但由于所有的操作都通過redis可能帶來性能損耗，有些場景是不能應(yīng)會這些損耗的。
- 通過進(jìn)程互備， 將狀態(tài)通過日志等方式同步到另一進(jìn)程， 但這可能存在著瞬間數(shù)據(jù)丟失的問題，這種數(shù)據(jù)丟失在一些應(yīng)用場景可能毫無問題， 但在另外一些應(yīng)用場景可能引起嚴(yán)重的數(shù)據(jù)不一致。
有狀態(tài)的高可用并不是那么好實現(xiàn)的，pomelo將在0.5版本提供高可用的實現(xiàn)機制，引入zookeeper和redis可以解決一些進(jìn)程（如master）的高可用問題，但真正復(fù)雜的應(yīng)用場景的邏輯只能由應(yīng)用自己處理。
2.3 Node.js的引入
為什么會在這里談node.js的引入？ 因為在講了這么多分布式開發(fā)的難點之后，引入node.js實在是太自然了。它解決了分布式開發(fā)的很多問題。
- 天生的分布式, node.js之所以叫node就是因為它天生就是做多進(jìn)程開發(fā)的， 多個節(jié)點(node)互相通訊交織在一起組成的分布式系統(tǒng)是node天生就應(yīng)該這么干的。例如前面提到的分布式事務(wù)、異步化操作在node.js里只是個正常的流程。
- 網(wǎng)絡(luò)io與可伸縮性的優(yōu)勢。游戲是非常io密集型的應(yīng)用， 采用node.js是最合適的， 可達(dá)到最好的可伸縮性。
- 輕量級, 輕量級的進(jìn)程帶來的開發(fā)效率的優(yōu)勢在開發(fā)的時候異常明顯。
- 語言優(yōu)勢。使用javascript開發(fā)可以實現(xiàn)快速迭代，客戶端html 5使用javascript，甚至在unity3d，cocos2d-x這樣的游戲平臺上也可以使用javascript, 可實現(xiàn)最大限度的代碼共用。
三、pomelo架構(gòu)分析
pomelo框架在最初設(shè)計的時候只為了一個目標(biāo)：為基于長連接的分布式游戲服務(wù)器架構(gòu)提供基礎(chǔ)設(shè)施。框架的內(nèi)容在逐漸擴展，但最核心的框架只為了干以下三件事：
在web應(yīng)用中， 每個服務(wù)器是無狀態(tài)、對等的， 開發(fā)者無需通過框架或容器來管理服務(wù)器。 但游戲應(yīng)用不同， 游戲可能需要包含多種不同類型的服務(wù)器，每類服務(wù)器在數(shù)量上也可能有不同的需求。這就需要框架對服務(wù)器進(jìn)行抽象和解耦，支持服務(wù)器類型和數(shù)量上的擴展。
客戶端的請求、響應(yīng)與web應(yīng)用是類似的， 但框架是基于長連接的， 實現(xiàn)模式與http請求有一定差別。 廣播是游戲服務(wù)器最頻繁的操作， 需要方便的API， 并且在性能上達(dá)到極致。
盡管框架盡量避免跨進(jìn)程調(diào)用，但進(jìn)程間的通訊是不可避免的， 因此需要一個方便好用的RPC框架來支撐。
下面分別對這三個目標(biāo)進(jìn)行詳細(xì)的分析：
服務(wù)器（進(jìn)程）的抽象與擴展介紹
服務(wù)器的抽象與分類
該架構(gòu)把游戲服務(wù)器做了抽象， 抽象成為兩類：前端服務(wù)器和后端服務(wù)器， 如圖：
前端服務(wù)器(frontend)的職責(zé)：
- 負(fù)責(zé)承載客戶端請求的連接
- 維護(hù)session信息
- 把請求轉(zhuǎn)發(fā)到后端
- 把后端需要廣播的消息發(fā)到前端
后端服務(wù)器(backend)的職責(zé)：
- 處理業(yè)務(wù)邏輯， 包括RPC和前端請求的邏輯
- 把消息推送回前端
服務(wù)器的鴨子類型
動態(tài)語言的面向?qū)ο笥袀€基本概念叫鴨子類型 服務(wù)器的抽象也同樣可以比喻為鴨子， 服務(wù)器的對外接口只有兩類， 一類是接收客戶端的請求， 叫做handler， 一類是接收RPC請求， 叫做remote， handler和remote的行為決定了服務(wù)器長什么樣子。 因此我們只要定義好handler和remote兩類的行為， 就可以確定這個服務(wù)器的類型。
服務(wù)器抽象的實現(xiàn)
利用目錄結(jié)構(gòu)與服務(wù)器對應(yīng)的形式， 可以快速實現(xiàn)服務(wù)器的抽象。
以下是示例圖：
圖中的connector, connector, gate三個目錄代表三類服務(wù)器類型， 每個目錄下的handler與remote決定了這個服務(wù)器的行為（對外接口）。 開發(fā)者只要往handler與remote目錄填代碼， 就可以實現(xiàn)某一類的服務(wù)器。這讓服務(wù)器實現(xiàn)起來非常方便。 讓服務(wù)器動起來， 只要填一份配置文件servers.json就可以讓服務(wù)器快速動起來。 配置文件和對應(yīng)的進(jìn)行架構(gòu)如下所示：
客戶端請求與響應(yīng)、廣播的抽象介紹
所有的web應(yīng)用框架都實現(xiàn)了請求與響應(yīng)的抽象。盡管游戲應(yīng)用是基于長連接的， 但請求與響應(yīng)的抽象跟web應(yīng)用很類似。 下圖的代碼是一個request請求示例：
請求的api與web應(yīng)用的ajax請求很象，基于Convention over configuration的原則， 請求不需要任何配置。 如下圖所示，請求的route字符串：chat.chatHandler.send， 它可以將請求分發(fā)到chat服務(wù)器上chatHandler文件定義的send方法。
Pomelo的框架里還實現(xiàn)了request的filter機制，廣播/組播機制，詳細(xì)介紹見pomelo框架參考。
服務(wù)器間RPC調(diào)用的抽象介紹
架構(gòu)中各服務(wù)器之間的通訊主要是通過底層RPC框架來完成的，該RPC框架主要解決了進(jìn)程間消息的路由和RPC底層通訊協(xié)議的選擇兩個問題。 服務(wù)器間的RPC調(diào)用也實現(xiàn)了零配置。實例如下圖所示：
上圖的remote目錄里定義了一個RPC接口： chatRemote.js，它的接口定義如下：
chatRemote.kick = function(uid, player, cb) { }其它服務(wù)器（RPC客戶端）只要通過以下接口就可以實現(xiàn)RPC調(diào)用：
app.rpc.chat.chatRemote.kick(session, uid, player, function(data){ });這個調(diào)用會根據(jù)特定的路由規(guī)則轉(zhuǎn)發(fā)到特定的服務(wù)器。（如場景服務(wù)的請求會根據(jù)玩家在哪個場景直接轉(zhuǎn)發(fā)到對應(yīng)的server）。
rpc的使用遠(yuǎn)比其它rpc框架簡單好多，因為我們無需寫任何配置文件，也無需生成stub。因為我們服務(wù)器抽象的實現(xiàn)的方式，使得rpc客戶端可以在應(yīng)用啟動時掃描服務(wù)器目錄自動生成stub對象。
完成了以上三個目標(biāo)， 一個實時的分布式應(yīng)用框架的輪廓就搭出來了，剩下的工作是往上添肉，這是我們后續(xù)文章里的內(nèi)容。
四、從游戲框架到實時應(yīng)用框架
當(dāng)我們分析完pomelo框架的設(shè)計目標(biāo)時， 我們發(fā)現(xiàn)核心框架的這件事情竟然與游戲沒有任何關(guān)系。這是一個通用的實時分布式應(yīng)用開發(fā)框架。官網(wǎng)上的聊天服務(wù)器demo就是一個實時應(yīng)用。
事實上pomelo已經(jīng)被應(yīng)用在很多非游戲領(lǐng)域。 網(wǎng)易的消息推送平臺是基于pomelo開發(fā)的，它承擔(dān)了網(wǎng)易移動端和web端的消息推送， 目前已經(jīng)上線使用。
整個開源社區(qū)沒有與pomelo定位相同的實時應(yīng)用框架。目前在開源社區(qū)最流行的實時應(yīng)用框架當(dāng)數(shù)meteor，它與pomelo有著截然不同的設(shè)計目標(biāo)。我們來比較一下這兩個框架的區(qū)別。
以下是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的實時應(yīng)用
- meteor最關(guān)注的是開發(fā)效率
但是我們的問題是：
- 現(xiàn)在的實時應(yīng)用有多少是只面向web端的?
- 規(guī)模稍大的實時應(yīng)用，瓶頸是在可伸縮性、性能還是在開發(fā)效率？
我們給出的答案是：
- 同時支持移動端、web端、PC端的實時應(yīng)用已經(jīng)是主流
- 相比開發(fā)效率，可伸縮性、性能是規(guī)模較大的實時應(yīng)用更有可能出現(xiàn)的瓶頸
而pomelo在這兩方面具有明顯的優(yōu)勢：
- pomelo支持動態(tài)connector協(xié)議機制，使它同時支持web、移動、PC、untiy3d等各類客戶端。開發(fā)無縫衍接各類客戶端的高時應(yīng)用在pomelo里面只是個配置問題
- pomelo在可伸縮性和擴展上具有很強的優(yōu)勢，這也是pomelo設(shè)計的最根本目標(biāo)
以上的比較并不說明pomelo比meteor優(yōu)秀， 它們是完全定位不同的兩個實時應(yīng)用框架。相信用戶會根據(jù)自己的需求做出選擇。
五、未來與展望
pomelo在開社區(qū)才剛剛起步， 僅僅不到半年時間pomelo已經(jīng)在github和各類社區(qū)上積累了強大的人氣，1700多的watcher在github已經(jīng)是相當(dāng)不錯的戰(zhàn)績。但這僅僅只是個起步，pomelo的真正的暴發(fā)期還未到來。
pomelo將會在分布式開發(fā)方面下更大的功夫，在加強高可用、負(fù)載均衡、過載保護(hù)、運維機制等方面做得更好.
pomelo也逐漸在世界的開源社區(qū)推廣。LXJS 2013的組織者邀請了筆者于2013年10月去葡萄牙里斯本做英文演講，可見pomelo已經(jīng)逐漸受到了國際node社區(qū)的牛人關(guān)注。當(dāng)然這還只是個開始。
posted on 2016-03-14 09:15
思月行云 閱讀(559)
評論(0) 編輯 收藏 引用 所屬分類:
Node.js