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是可以按每一个模块单独配置自己的消息队列服务器的,因此在未来可以横向扩展