mqant分散式伺服器框架設計動機

2016年底的時候對即時通訊以及遊戲開發產生了一些興趣,而且自己這方面的知識掌握也非常少,在未來很多產品應該都會使用到長連線技術(物聯網IOT),因此很有必要掌握這方面的技術。於是就在網路上查詢相關的資料,但發現目前網路上的開源遊戲伺服器框架相對較少,而目前市面上已有的一些開源遊戲框架又不太對自己的胃口。正好17年初剛回公司的時候事情比較少,就抽時間按照自己對遊戲伺服器的架構思路做了一套,取名就叫mqant了,現在已經發布到Github上,歡迎大家Fork mqant開源框架

為什麼決定要重新造一個輪子?

目前網上優秀的開源遊戲伺服器框架也不少(當然與web框架比起來就少太多了),但總結起來都各有各的優缺點,下面列出我在選型過程中的一些考量,希望大家能開放的討論,有不恰當的地方也請指正。

首先是開發語言

目前用於遊戲伺服器開發的主要應該有以下這些語言:

1. c/c++

   優點:

   效能很好

   缺點:

   不過我個人不會C++

   開源框架:

   skynet
   底層是C 開發語言是lua,
   沒有客戶端庫
   
   kbengine
   底層是C++ 開發語言可以使用C#,Python
   有多個平臺的客戶端庫

2. C#

   優點:

   效能很好

   缺點:

   不過我個人不會C#

   開源框架:

   Scut
   底層C#   開發語言是 C#、Python和Lua多種指令碼進行開發
   有多個平臺的客戶端庫
   
   Photon
   底層C#   好像是收費的,但畢竟出名
   有多個平臺的客戶端庫

3. python

   是我最想使用的一種開發語言

   1. 開發效率非常高
   2. 支援協程,能開發出高併發性的遊戲,而且程式碼可讀性好
   3. 目前有很多遊戲公司應該都使用的是Python作為後端遊戲伺服器開發語言,有相對成熟的案例

   缺點:

   1. Python很致命的一個問題是程式不能利用多核,也就是說一個程式只能利用一個CPU進行計算,如果要用多核就需要新開程式,這樣會造成伺服器的維護成本增加,而且開發專案時所需要考慮的問題也更多

   開源框架:

   twisted  可以用來做閘道器伺服器
   firefly  應該很早就不維護了

4. java

   1. 沒有找到比較好的開源框架
   2. 對協程支援不夠好
   3. 開發效率較低

5. javascript

   優點:

   1. 語法靈活(這是一把雙刃刀,用起來要小心,尤其是團隊開發中)
   2. 開源庫豐富

   缺點:

   1. 語法上有一些缺陷
   2. 跟Python一樣不支援多核
   3. 對協程支援不夠好,地獄回撥很可怕,雖然有一些解決方案,但用起來稍微有點彆扭

   開源框架:

   Pomelo 網易出的,安靜了一段時間,最近又開始維護了
   有多個平臺的客戶端庫

6. golang

   優點:

   1. 效能好,跟C/C++/C#一樣編譯型語言
   2. 語法比較簡單,開發效率也比較高,接近Python
   3. 語言級別支援協程
   4. 單程式支援多核併發計算

   缺點:

   1. 開源庫較少,會golang的開發者比較少

   開源框架:

   leaf        接觸的第一個golang框架,設計不錯,但不支援多程式
   沒有客戶端庫,需要自己實現
   cellnet 剛接觸,沒法評價,但好像它用了callback回撥函式的設計,這樣的設計在golang應該可以避免

遊戲框架的不足

結合個人的實際情況,當時我主要的選擇從 skynet Pomelo leaf 這三個框架裡面來選擇

skynet設計思路非常牛逼,看了風雲大牛的設計感覺應該是一個高效能,高穩定性的遊戲伺服器框架,而且有很多產品已經使用上了。 但個人認為skynet可能也會有以下的兩個問題

1. Actor模式可能對架構能力比較高,不如rpc模式明瞭
2. skynet使用第三方網路庫的時候可能需要造輪子,要放開膀子開發有些難,跟python tornado的一樣,要寫出高效能的程式也對開發人員有一定的要求

Pomelo由網易團隊開發的,對多程式架構做的非常好,不過由於javascript效能的關係Pomelo的定位也在一些中小型非即時戰鬥類遊戲,經過一段時間的學習和測試,最後還是無奈放棄了

最後經過多方考慮,我選擇golang作為開發語言,當時第一個接觸的就是leaf,學習開發了一段時間發現了leaf的一些不足

1. 不支援多程式
2. 沒有客戶端開發庫,需要自己造輪子

上面列出來的都是這幾個框架的缺點,其實這幾個框架都非常優秀,只是不同的需求有不同的要求罷了,希望大家能根據自己實際需求選擇最適合自己的框架

對遊戲伺服器框架的想法

自己心裡也對遊戲伺服器框架有一些自己的想法,最終決定造這個輪子。

1. 高效能,支援多核

   這在未來開發,擴充套件,維護會輕鬆很多,比如Python這樣一臺伺服器跑上百個程式的遊戲伺服器,維護起來就很讓人頭疼

2. 支援協程

   協程在客戶端中應用不大,但在伺服器開發中可以發揮極大的威力:

   1. 高併發,能最大的利用cpu資源
   2. 非同步開發同步化,免去了回撥函式設計,避免了地獄回撥

3. 支援分散式,但也支援單程式部署

   有些框架寫一個demo都需要啟動多個程式,實際上在專案前期可能一臺伺服器就能夠支援了,我希望實現一個既可以單程式部署又可以分散式部署的框架

   1. 單程式能夠實現高效能
   2. 分散式部署不用重新設計編碼

   這個需求的實現主要靠約定,只要開發的時候按分散式環境來開發,程式碼一般都不需要移植

4. 有豐富的客戶端開發庫

   讓開發者專心業務開發,不同再去造輪子了

mqant框架的架構

mqant就是按照以上的思路設計的,同時設計思路上參考了Pomelo,並且也使用了leaf框架的部分程式碼。

1. golang本身支援高效能,支援多核

2. 支援協程 因此mqant的RPC通訊都可以按同步來寫, 例如:

   //遠端呼叫 Login模組的getRand方法
   result,err:=m.RpcInvoke("Login","getRand",roomName)
   if err==nil{
       //getRand 呼叫成功了，再做下面的遠端呼叫
       result,err:=m.RpcInvoke("Login","getName",roomName)
   }
   //上面的呼叫都執行完了才執行下面的程式碼
   ....
   
   result 是遠端呼叫成功以後的返回值
   err     是遠端呼叫失敗的資訊
   
   以上程式碼非常清晰,跟普通的函式呼叫基本一樣,但如果用回撥函式的話,如下:
   
   m.RpcInvoke("Login","getRand",roomName,func(result string,err string){
           if err!=nil{
               m.RpcInvoke("Login","getName",roomName,func(result string,err string){
                   //呼叫都執行完了才執行下面的程式碼
               })
           }
   })
   ...

3. 支援分散式,但也支援單程式部署

   mqant是按模組為單位來劃分功能模組的,可以將一組模組放到一個程式來執行,也可以將所有模組放到同一個程式來執行(即單程式模式)

   mqant模組間約定按標準的RPC來相互呼叫

   RPC底層分兩種模式

   1. 基於golang chan的單程式通訊
   2. 基於rabbitmq的跨程式通訊

   RPC會根據模組間的部署情況選用適當的通訊方式,以達到在單程式模式下RPC通訊的最低效能損耗和最快的響應時間

4. 有豐富的客戶端開發庫

   mqant沒有考慮幫開發者造一個客戶端開發庫,而是選用了目前物聯網中非常流行mqtt協議來作為通訊協議,mqtt本身就有各個平臺的客戶端開發庫,因此可以直接用mqtt的客戶端開發庫對接到mqant上來。實現了mqant跨平臺通訊的要求

總結

mqant還是一個非常新的框架,有很多地方都不完善,但我相信有更多大牛的加入進來參與完善和優化的話,mqant框架將變得更好。