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是能够按每个模块单独配置本身的消息队列服务器的,所以在将来能够横向扩展