遊戲伺服器與Web伺服器特點對比

28 人贊了文章

為了編寫基於cellnet的新一代遊戲伺服器框架，最近深入研究微服務，ServiceMesh等概念。研究過程中對Web和遊戲兩種伺服器架構設計有一些心得，編寫並記錄下來。(下文中，Game表示遊戲伺服器，Web表示Web伺服器)

狀態緩存

所謂狀態緩存，就是在內存而非專業數據緩存伺服器（如redis）中保存和處理邏輯數據，手動編寫此過程較為繁瑣但是效率較高，但隨著狀態邏輯複雜性和並發、擴容問題提出，狀態同步會變得越來越複雜。

Game:

強交互性的伺服器類型需要在伺服器做緩存，邏輯編寫也較為容易，無需處理事務並發問題。例如：組隊，匹配，戰鬥邏輯。伺服器不能隨意重啟。

弱交互性的伺服器類型可配合redis做成無狀態伺服器，例如：養成，技能升級，領取物品等。伺服器隨時支持重啟。

遊戲伺服器為了提高性能，早期所有伺服器都是使用狀態緩存寫法編寫，特別是MMORPG這類強交互的遊戲伺服器尤為嚴重。

Web:

均為無狀態伺服器，弱交互。使用事務方式處理並發邏輯，例如：交易，下單等。

推送，單獨發送

這裡提到的所謂推送，單獨發送是與RPC區別的通訊方法。RPC要求請求必須有回應。而推送單獨發送則更像是通知和廣播，無需目的方返回任何消息。

Game:

找到伺服器的Session，直接Send

通過中轉伺服器，或稱為中心伺服器進行註冊/廣播

客戶端的model數據需要更新時，伺服器會主動推送消息。

遊戲伺服器沒有嚴格的RPC設計需求，推送和單獨發送較Web伺服器更多。而且遊戲伺服器多使用長連接，所以主動推送也比Web伺服器來的方便一些。

Web:

將推送做成專有的服務，並做排隊和並發處理。

可用性

聽說過遊戲停服更新，支付寶伺服器在刷二維碼時停服了可一定被罵慘吧。Web對伺服器高可用性要求很高，遊戲雖然也注重伺服器穩定性和可用性，但是由於版本迭代更新頻繁，停服更新反而能獲得玩家接受。

Game:

遊戲對可用性要求不高。

遊戲大版本更新時需要停服更新。支持熱更新技術的伺服器（例如Erlang，Skynet）僅使用熱更新修復bug，很少直接更新新版本。

不是所有的遊戲伺服器支持動態添加伺服器。

Web:

極高的可用性，服務不允許停服更新，使用藍綠及灰度方式更新伺服器。

隨時可以橫向擴展伺服器，提高伺服器容量和承載。

連接及傳輸

均使用TCP傳輸協議，遊戲伺服器注重性能，自有協議及二進位協議使用較多。

Web注重兼容和介面友好，使用JSON格式較多。

Game:

使用長連接，需要從邏輯層維護連接狀態及處理伺服器不在線情況

使用自有封包格式，大部分使用protobuf或二進位流格式。

Web:

微服務大部分使用短連接，grpc支持http2長連接

使用json編碼方便調試和版本兼容。

流量限制

人數多了，任何伺服器都扛不住，流量限制和登入限制能有效保護伺服器穩定。

Game:

單服有人數限制，可以通過GM後台設置擋牆，超過無法進入

Web:

限流器中間件，可以精確到服務控制流量

斷流，防止雪崩

Game:

遊戲沒有，也不需要這種概念，遊戲請求不會突然升高，即便有，也通過GM後台人為控制

Web:

斷流器中間件

服務發現

如何找到伺服器地址。

服務有變化時，通過Watch系統通知訂閱者更新本地緩存

伺服器沒有變化時，使用本地緩存找到服務地址

Game:

遊戲伺服器互相依賴復用只在很小的範圍內，因此無需在不同語言不同進程服務間獲得地址，大部分在配置文件中填寫各服務的IP及地址即可互相訪問。

早期遊戲自己編寫伺服器狀態及地址發現服務。

有用redis做服務發現

Web:

使用服務發現系統，分散式部署。無需依賴配置文件

網關需求

Game:

網關處理客戶端上下線通知，心跳，維持連接，轉發，廣播上下行封包

Web:

根據請求地址路由，無上下線概念，無心跳。廣播通過消息推送系統完成

由於筆者從事遊戲行業，對Web伺服器概念在逐漸熟悉中，若有錯誤和不足請各位大佬指出。

本人新書《Go語言從入門到進階實戰》，生動的語言，例子帶有各種彩蛋，輕鬆了解Go語言特性，更有cellnet框架剖析解密

各大網商電商均有銷售

京東鏈接：

- 商品搜索 - 京東?

search.jd.com

推薦閱讀：