對golang伺服器開發模式的一些思考

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

多線程+同步阻塞模型

在我們的遊戲項目中使用的golang伺服器開發方式如下

1.多線程邏輯

2.同步阻塞. 也就是說, 每個人一個線程(goroutine), io線程=邏輯線程

這種方式的優點:

1. 同步阻塞方式與人的思維方式類同

2. 邏輯處理效能有一定提升

在大規模使用這種模式編寫邏輯後, 我們發現了這種模式只有1個缺點: 編寫者需要處理多線程關係

但這本身確實直接致命的, 回想C++時代, 多執行緒時, 調試重現的困難… 腦補景象太慘不敢直視

單線程+非同步多進程模型

在C++時代, 我曾經編寫過一套asio的C++伺服器架構. 採用io多線程, 邏輯單線程, 依賴著C++高效能的優勢, 讓開發便捷簡單且無需關心線程問題.

那麼到了golang時代, 為什麼不能試下單線程非同步多進程方式來編寫邏輯?

與多線程同步阻塞對比後, 我們發現, 兩者優缺點互補. 那這就回到了領域選型問題了. 對於遊戲伺服器需要的上手簡單, 開發便捷, 壓力降低(非MMO)這些特點來說, 單線程非同步多進程再合適不過了

那麼, 我們在用golang編寫單線程非同步多進程伺服器應該注意哪些點呢?

1. socket處理完全封裝, 只通過channel拋出到邏輯線程排隊處理

2. 資料庫, rpc及其他io處理, 一律改為非同步回調模式, 不使用同步介面

3. 玩家存檔提交資料可以考慮複製並提交到存檔線程方式, 提高效能.

4. 採用多進程架構, 比如設網關進程, 把io壓力分散到進程中

5. 邏輯編寫中, 不允許使用go開線程及channel, 有需要提高效能部分需要單獨編寫

 

Actor模型的痛

cellnet在開發時本來考慮使用actor模型來進一步簡化多線程邏輯的麻煩, 經曆了一段時間的原型開發後, 發現了一些問題, 列舉如下:

1. golang的強型別不適合actor模型這種經常需要動態產生各類訊息的模型, 但skynet(C+lua)/erlang就有天生優勢

2. actor模型本身不是萬能的, 不能解決所有需求, 特別是遊戲

3. actor模型理解到應用有一定的難度. 本身還需要搭建架構, 上手複雜

總之, 看過一些erlang及skynet的用例, 沒有應用的很純正且成熟的成功actor模型案例, 從傳統socket伺服器架構跨越到actor模型會扯到蛋, 因此, 後期cellnet會考慮迴歸到成熟的socket伺服器架構. 把架構做到簡單上手, 高擴充上.