mqant架構概述

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

mqant經過4個月的發展,目前已在github上獲得了300多的star，相信在大家的努力下mqant將在未來更加光彩

現如今只有多進程的架構才能達到支撐較多線上使用者,降低伺服器壓力,降低單點故障所帶來的影響等要求,因此一個真正高可擴充的遊戲運行架構必須是多進程的。

然而在遊戲的開發和運營也是按步驟階段性進行的,尤其是現如今伺服器硬體裝置配置也越來越高的前提下,在遊戲剛開始運營時單台伺服器就足夠支撐了,況且多進程部署所帶來的營運成本也相對較高。

mqant的設計思想是在能用單台伺服器時能讓充分挖掘伺服器的效能,而在需要多進程時再通過簡單的配置就可以實現分布式部署。

mqant遊戲伺服器的運行架構

mqant伺服器是按模組來劃分功能模組的,例如 使用者管理,線上聊天,戰鬥平台等等都應該劃分為獨立的模組

模組之間通過RPC通訊,mqant底層會根據實際情況選擇rpc資料互動的通訊渠道,在調用模組在同一個進程的情況下直接使用golang chan通訊,因此同進程內模組通訊效能不受影響。

每一個模組可以註冊多個處理器(handler), 處理器分為 backend/frontend 兩種模式

frontend 提供給用戶端調用的

backend 提供個後端模組之間相互調用的

frontend的約定

frontend與backend實際上是相同的,唯一的不同是我們約定frontend命名已"HD_"開通,同時frontend函數的參數類型也固定

mqant遊戲伺服器架構

模組間通訊RPC

mqant中的RPC被封裝為通用介面,底層可以根據需求在切換為如grpc,zerorpc等其他RPC通道,但目前mqant預設使用的遠程通訊通道是rabbitmq訊息佇列。

為什麼這樣選擇?

選擇訊息佇列而不選擇傳統的tcp/socket rpc的主要考慮是傳統的基於點對點service/client模式的串連比較難於維護和統計,假如伺服器存在100個模組和伺服器的話進一個進程所需要維護的client串連就>100個(計算可能不太準確(^—^)).

而選擇訊息佇列的話每一個進程對每一個模組只需要維護一條串連即可,同時rabbitmq有完善的監控,警示工具,可以隨時監控模組的處理效能和即時性。

另外關於訊息佇列可能面臨訊息轉寄出現瓶頸的問題,mqant是可以按每一個模組單獨配置自己的訊息佇列伺服器的,因此在未來可以橫向擴充