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是能夠按每個模塊單獨配置本身的消息隊列服務器的,所以在將來能夠橫向擴展