深刻淺出node.js遊戲服務器開發1——基礎架構與框架介紹

 

2013年04月19日 14:09:37 MJiao 閱讀數：4614

 

深刻淺出node.js遊戲服務器開發1——基礎架構與框架介紹

 

遊戲服務器概述

沒開發過遊戲的人會以爲遊戲服務器是很神祕的東西。但事實上它並不比web服務器複雜，無非是給客戶端提供網絡請求服務，本質上它只是基於長鏈接的socket服務器。固然在邏輯複雜性、消息量、實時性方面有更高的要求。

 

遊戲服務器是複雜的socket服務器。

若是說web服務器的本質是http服務器，那麼遊戲服務器的本質就是socket服務器。 它利用socket通信來實現服務器與客戶端之間的交互。事實上有很多遊戲是直接基於原生socket來開發的。 相對於簡單的socket服務器，它承受着更加煩重的任務：

• 後端承載着極複雜的遊戲邏輯。
• 網絡流量與消息量巨大，且實時性要求極高。
• 一般一臺socket服務器沒法支撐複雜的遊戲邏輯，所以在socket服務器的背後還有一個服務器羣。

爲何純粹的socket服務器還不夠好？

不少web應用不會基於原生的http服務器搭建，通常都會基於某類應用服務器（如tomcat）搭建，並且還會利用一些開發框架來簡化web開發。 一樣，通常遊戲服務器的開發都會在socket服務器上封裝出一套框架或相似的應用服務器。爲何使用原生的socket接口開發不夠好呢?

• 抽象程度。原生的socket抽象程度太低，接口過於底層，不少機制都須要本身封裝，如Session、filter、請求抽象、廣播等機制都要自已實現，工做量很大，容易出錯，且有不少的重複勞動。
• 可伸縮性。高可伸縮性需考慮不少問題，消息密度、存儲策略、進程架構等因素都須要考慮。用原生的socket要達到高可伸縮性，須要在架構上花費大量的功夫，並且效果也未必能達到開源框架的水準。
• 服務端的監控、管理。不少服務器的數據須要監控，例如消息密度、在線人數、機器壓力、網絡壓力等，若是採用原生socket，全部這些都要本身開發，代價很大。

用框架來簡化遊戲服務器開發

一個好的框架能夠大大簡化遊戲服務器的工做。除了遊戲自身的邏輯外，大部分的工做均可以用框架來解決。服務端的抽象，可伸縮性，可擴展性這些問題均可以經過框架來解決。 遊戲服務器框架也承擔了應用服務器的功能。能夠把框架當作容器，只要把符合容器標準的代碼扔進去，容器就運行起來了。它天然具有了抽象能力、可伸縮性和監控、管理等能力。

遊戲服務器框架介紹

在開源社區裏充斥了數不清的web服務器框架，遊戲客戶端的框架和庫也有一大堆，但惟獨遊戲服務器框架少之又少，零星有一些類庫，但完整的解決方案几乎沒有。咱們只好從商用的解決方案中拿出一些框架進行類比：

Sun RedDwarf

RedDwarf是惟一一個能找到的完整的開源遊戲服務器框架，由sun出品。惋惜在它合併到Oracle之後已經中止開發了。 在設計上，RedDwarf是個分佈式架構，它在分佈式數據存儲和任務管理上投入了太多精力，並且作的過於理想化，如動態任務遷移功能的實現很是複雜，但實際應用中根本用不到。而在可伸縮性和性能的設計上不太理想。所以RedDwarf夭折了。

SmartfoxServer

SmartfoxServer是由意大利的一家遊戲公司gotoAndPlay()推出的商用遊戲服務器。 它是基於java開發的，與web應用服務器如Tomcat看上去很相似。Smartfox支持各類客戶端，且有一些成功案例。它在服務端封裝和監控管理方面實現得很完善。 但在可伸縮性上並非太理想，儘管Smartfox也支持Cluster模式，但它的擴展方式是基於jvm內存複製的。也沒有實現傳統MMORPG基於場景分區的解決方案。 Smartfox有免費版本，但徹底不開源。並且它的免費版本(達不到高併發用戶要求)很大程度是爲了吸引開發者最終購買它的收費版本。不限在線人數的收費版本價格達到3500美刀。

BigWorld

Bigworld是澳大利亞Bigworld公司開發的全套3d MMORPG遊戲解決方案，解決方案包含了客戶端和服務端。Bigworld功能很是強大，在動態負載均衡和容錯性作了不少工做。可擴展性很是強大。 它的缺點是過於重量級，對硬件要求高，且價格很是昂貴。Bigworld是專門爲3d MMORPG遊戲定製，但並不適用於中小型遊戲的開發。

Pomelo

Pomelo是網易於2012年11月推出的開源遊戲服務器。它是基於node.js開發的高性能、可伸縮、輕量級遊戲服務器框架。 它的主要優點有如下幾點：

• 開發模型快速、易上手，基於Convention over configuration的原則，讓代碼達到最大的簡化。
• 架構的可伸縮性和可擴展性好，pomelo在服務器擴展和應用擴展上實現得很是方便。
• 輕量級，雖然是分佈式架構，但啓動很是迅速，佔用資源少。
• 參考全面，框架不只提供了完整的中英文檔，還提供了完整的MMO demo代碼(客戶端html5)，能夠做爲很好的開發參考。

Pomelo目前的主要缺點是推出時間尚短，一些功能還在完善中，支持的客戶端類型還有限，目前已支持HTML五、ios、android、untiy3d等4類客戶端，將來還會支持更多的客戶端類型。

遊戲服務器的可伸縮性探討

無論是web應用仍是遊戲服務器，可伸縮性始終是最重要的指標，也是最棘手的問題，它涉及到系統運行架構的搭建，各類優化策略。 只有把可伸縮性設計好了，遊戲的規模、同時在線人數、響應時間等參數才能獲得保證。

爲何遊戲服務器的可伸縮性遠遠不及web?

相比web應用幾乎無限擴展的架構（前提是架構設計得好），遊戲服務器的可伸縮性相比就着差遠了。那麼是哪些因素致使遊戲沒法達到web應用的擴展能力呢？ 說明：本文提到的web應用不包括相似於聊天這樣的高實時web應用，高實時web可認爲是一種邏輯較簡單的遊戲。

長鏈接和響應實時性

web應用都是基於request/response的短鏈接模式。佔用的資源要比一直hold長鏈接的遊戲服務器要少不少。Web應用能使用短鏈接模式的緣由以下：

• 通信的單向性，普通web應用通常只有拉模式
• 響應的實時性要求不高，通常web應用的響應時間在3秒之內都算響應比較及時的。

而遊戲應用只能使用長鏈接，緣由以下：

• 通信的雙向性，遊戲應用不只僅是推拉模式，並且推送的數據量要遠遠大於拉的數據量
• 響應的實時性要求極高，通常遊戲應用要求推送的消息實時反映，而實時響應的最大時間是100ms。

在高併發長鏈接服務的解決方案中，目前除了傳統的C語言（過於重量級）實現，用的最多的是erlang與node.js。二者的性能指標差很少，而node.js在易用性方面毫無疑問勝出太多。

最近微博上看到時go的能撐起100萬的併發鏈接，node.js也能達到一樣的數據， Node.js w/1M concurrent connections!有node.js的長鏈接數據，它佔用了16G內存，但CPU還遠沒跑滿。

交互的相鄰性與分區策略

普通的web應用在交互上沒有相鄰性的概念，全部用戶之間的交互都是平等，交互頻率也不受地域限制。 而遊戲則否則，遊戲交互跟玩家所在地圖（場景）上的位置關係很是大，如兩個玩家在相鄰的地方能夠互相PK或組隊打怪。這種相鄰的交互頻率很是高，對實時性的要求也很是高，這就必需要求相鄰玩家在分佈在同一個進程裏。 因而就有了按場景分區的策略，如圖所示：

一個進程裏能夠有一個場景，也能夠有多個場景。這種實現帶來了如下問題：

• 遊戲的可伸縮性受到場景進程的限制，若是某個場景過於煩忙可能會把進程撐爆，也就把整個遊戲撐爆。
• 場景服務器是有狀態的，每一個用戶請求必須發回原來的場景服務器。服務器的有狀態帶來一系列的問題：場景進程的可伸縮，高可用性等都比不上web服務器。目前只能經過遊戲服務器的隔離來緩解這些問題。

廣播

遊戲中廣播的代價是很是大的。玩家的輸入與輸出是不對等的，玩家本身簡單地動一下，就須要將這個消息實時推送給全部看到這個玩家的其餘玩家。 假如場景裏面人較少，廣播發送的消息數還很少，但若是人數達到很密集的程度，則廣播的頻度將呈平方級增加。如圖所示：

假如場景中1000個玩家，每人發1條消息，若是須要其它玩家都看到的話，消息的推送量將高達1,000,000條，這足以把任何服務器撐爆。

解決這個問題的方案：

• 減小消息數量---消息只發送給能看到的玩家。玩家能看到的只是屏幕的大小，而不是整張地圖的大小，這樣推送消息的時候能夠只推給對本身的狀態感興趣的玩家。這個能夠用AOI（area of interested）算法來實現，在pomelo的庫pomelo-aoi中實現了簡單的燈塔算法。
• 分擔負載，將消息推送的進程與具體的邏輯進程分離。如圖：

這樣廣播邏輯與具體的進程邏輯就不會相互影響了，並且因爲只有後端的場景服務器是有狀態的，前端負責廣播的服務器仍是無狀態的，所以前端服務器能夠無限擴展。

實時Tick

實時遊戲的服務端通常都須要一個定時tick來執行定時任務，爲了遊戲的實時性，通常要求這個tick時間在100ms以內。這些任務包括如下邏輯:

• 遍歷場景中的實體(包括玩家、怪物等)，進行定時操做，如移動、復活、消失等邏輯。
• 按期補充場景中被殺掉的怪的數量。
• 按期執行AI操做，如怪物的攻擊、逃跑等邏輯。

因爲實時100ms的限制，這個實時tick的執行時間必需要遠少於100ms，所以單進程內不少數據都會受到限制。

• 場景內實體的數量受限制，由於要遍歷全部實體
• 注意更新的算法，全部的算法，包括AI在內都要在幾十毫秒所有完成
• 注意GC，full GC最好永遠不要發生。通常full GC的時間都會高於100ms，幸虧node.js在內存少於500M時表現良好，只有小GC。所以必定要控制內存大小。
• 儘可能分進程，進程的粒度越少，出現tick超時或full GC的可能越少。在多核時代裏，CPU是最廉價的資源。

高可伸縮的運行架構

通過以上這些分析。咱們能夠獲得如今的運行架構，以下圖：

運行架構說明：

• 客戶端經過websocket長鏈接連到connector服務器羣。
• connector負責承載鏈接，並把請求轉發到後端的服務器羣。
• 後端的服務器羣主要包括按場景分區的場景服務器(area)、聊天服務器(chat)和狀態服務器等(status)，這些服務器負責各自的業務邏輯。真實的案例中還會有各類其它類型的服務器。
• 後端服務器處理完邏輯後把結果返回給connector，再由connector廣播回給客戶端。 master負責統一管理這些服務器，包括各服務器的啓動、監控和關閉等功能。

這個運行架構符合了剛纔提到的幾個伸縮性原則：

• 先後端進程分離，把承載鏈接和廣播的壓力盡可能分出去。
• 進程的粒度儘可能小，把功能細分到各個服務器
• 按場景分區

前面提到4個遊戲服務器框架，只有bigworld和pomelo符合這樣的架構，固然bigworld實現的還要更復雜。 如今的問題是，這個運行架構是個分佈式架構，並且並不簡單，那就帶來如下問題：

• 須要多少的代碼來實現這樣的運行架構？
• 服務器類型、數量管理和擴展有點複雜，該怎麼管理？
• 服務器之間會有一堆的相互rpc調用，實現起來怎麼簡化？
• 分佈式的開發和調試並不容易，消耗資源量過大，過於重量級，多進程bug定位困難，該怎麼解決？ Pomelo和node.js將很輕鬆地幫咱們解決這些難題，咱們下一節將討論。

node.js、pomelo與遊戲服務器

Node.js的特色與遊戲服務器極其符合。列舉以下:

• 對網絡IO的處理能力，node.js生來就是爲IO而生的，而遊戲服務器恰好是網絡密集型的應用。
• 單線程的應用模型，node.js的單線程處理能力遠比其它語言強大，而單線程處理遊戲邏輯是最簡單，最不容易出錯，並且不可能出現死鎖、鎖競爭的狀況。
• 語言與輕量的開發模型。Javascript語言已經不是昔日的吳下阿蒙，它不只因爲腳本語言的輕量、簡單帶來了開發效率的提高。還能夠與一些類型的客戶端共享部分代碼，如html5，unity3d的js客戶端等。
• 語言的動態性帶來了不少框架設計的便利，如設計DSL，實現Convention over configuration。儘管這方面比ruby稍差，但在pomelo框架中使用已經足夠好了。

Pomelo是基於node.js搭建的遊戲服務器框架，它在靈活性、擴展能力，輕量級調試方面具備無可比擬的優點。咱們先簡單回答第三章最末的幾個問題：

• 用pomelo來實現以上的運行架構幾乎是零代碼的，由於它在設計時天生就具有這樣的架構。
• 服務器類型、數量的管理極簡單，利用鴨子類型、目錄定義，只要一個簡單json配置文件就能夠實現全部服務器的管理。
• rpc調用能夠實現徹底零配置，也不用生成stub。感謝js語言的動態性，基於Convention over configuration的原則，能夠直接實現rpc調用。
• 分佈式的開發和調試只佔用不多的資源，啓動極其迅速，十幾個進程只用10秒不到的時間徹底啓動。多進程調試與單進程調試沒有任何區別，只在一個console裏搞定。

在本系列文章後面將會陸續討論pomelo是怎麼實現以上如此方便的特性， 以及這些設計帶來的啓發。

小結

本文分析了遊戲服務器框架的市場現狀，一個高可伸縮遊戲服務器架構的設計原則及運行架構。Node.js與pomelo在解決高併發和分佈式架構中起到的做用。下文咱們將深刻分析pomelo在解決複雜的遊戲服務器運行架構中提供了哪些便利。

 

您可能也會喜歡

深刻淺出node.js遊戲服務器開發——基於Pomelo的MMO RPG開發

深刻淺出Node.js遊戲服務器開發--分佈式聊天服務器搭建

Game Server Development in node.js