前言

• 本文是游戏业务线消息队列中间件详细架构设计文档，用于指导消息队列后续的开发、测试和运维。

词汇表

• Reactor：一种主流的网络编程模式，是事件驱动架构的一种实现。

• Netty：一个异步 I/O 客户端服务器框架，主要用于开发 Java 网络应用程序，如协议服务器和客户端。

• MySQL：一个开源关系型数据库，世界上应用面最广的数据库之一。

• ZooKeeper：一个开源的分布式决策中心，为大型分布式计算提供分布式配置服务、同步服务和命名注册。

一、业务背景

1.1 - 业务背景

2014 年左右，游戏业务发展很快，系统也越来越多，系统间协作的效率很低。例如以下两个场景：

• 游戏新版本发布了：

• 游戏厂家更新游戏版本后，运营人员获取最新的游戏包，更新版本信息。

• 然后上传包到包管理系统打测试包，运营人员进行基本测试。

• 运营子系统通知论坛有新的包将要发布，进行预热。

• 测试完成后，运营管理子系统要通知包管理系统进行打包 。

• 游戏准点正式发布的时候，运营子系统要通知 App、Web 站点等即时更新到新版本。

• 玩家充钱了：

• 玩家进行充值，充值完成后充值子系统通知 VIP 子系统。

• VIP 子系统判断玩家等级，达到 VIP 后，等级子系统要通知福利子系统进行奖品发放。

• 要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理。

• 等级子系统的开发人员也是不胜其烦。

1.2 - 旧系统架构的问题

随着游戏业务发展，旧的架构也暴露出如下问题：

• 性能问题：

• 系统之间交互很多，交互的效率很低。

• 一旦有依赖于几个子系统的请求出现（例如版本上新）则运营子系统需要逐个调用子系统。

• 如若中间出错，还需要有重试机制。

• 耦合问题：

• 当新增一个子系统时，该子系统需要开发给各个其他服务调用的接口。

• 又因为子系统之间协议不统一，可能导致整体系统变得更复杂。

• 效率问题：

• 每个子系统提供的接口参数和实现都有一些细微的差别。

• 开发时每次都需要重新设计接口和联调接口。

• 开发团队和测试团队花费了许多重复工作量。

1.3 - 引入消息队列的目标

基于以上背景，我们需要引入消息队列进行系统解耦，将目前的同步调用改为异步通知。

• 系统解耦：

• 系统之间虽然仍相互依赖，但不进行直接调用。

• 由消息队列分发消息，各个子系统处理自己负责的队列话题中的消息。

• 提升开发效率：

• 统一协议，统一消息格式，每个子系统面向定好的协议与消息格式开发。

• 提高可维护性：

• 清楚消息传递的边界。

• 生产环境中是哪个子系统出问题，或者是消息队列出问题，均可第一时间发现并解决。

• 提高性能：

• 不是核心需求，但引入消息队列在解耦的基础上避免了发起请求的业务系统长时间的同步等待。

• 性能越高，请求发出之后业务系统需要等待的时间越少。

二、约束和限制

2.1 - 投资方、使用方的要求

• 首先，业务必须优先提供可用性。

• 其次，消息队列系统必须保证可维护性：维护操作要方便，例如收发消息情况、权限控制、上下线等 。

• 最后，开发成本不能太高。

2.2 - 团队技术选型硬性要求

• 中间件团队规模不大，大约六人左右。

• 中间件团队熟悉 Java 语言，有一个成员 C/C++ 很牛。没有人熟悉 Scala 或 JVM 平台的其他新兴语言，没有人熟悉 Erlang 语言。

• 业务方、中间件团队均对 MySQL 很熟悉。开发平台是 Linux，数据库是 MySQL 主备架构。

• 目前整个业务系统是单机房部署，没有双机房。

三、总体架构

3.1 - 架构分析

3.1.1 - 高可用性

• 消息队列中的储存层采用 MySQL，是业界成熟稳定的方案。同时我们采用主备方案保证数据可用性。

• 消息队列的服务层是本项目重点需要开发、测试的代码层。中间件团队熟悉 Java 语言与 MySQL 的开发流程。本身 Java + MySQL 的技术栈也是业界验证的成熟稳定方案。

3.1.2 - 性能

• Java 服务层的性能也是业界验证过的，语言本身在性能方面可以说仅次于 C/C++/Rust 等底层语言，属于第一梯队。

• 使用 MySQL 保存消息可能速度上不如 Kafka 那样用文件系统 append 那么极致，但是在 MySQL 中保存的表非常简单，基本上属于一个 Key-Value 性质的设计，速度不会慢太多。

3.1.3 - 成本

• 研发实现成本应该较低，逻辑本身不复杂。测试人力投入可能较大，但测试主要集中在消息队列的服务层。MySQL 层不需要太多测试。

• 由于只有服务层需要研发，存储层是直接利用 MySQL，开发过程中团队可以专注于一个层级。

• 硬件成本比较高，一个数据分组就需要 4 台机器，其中 2 台服务器，2 台数据库服务器。

3.1.4 - 可维护性

• 方案可以融入到现有的运维体系中，而且使用 MySQL 存储数据，可靠性有保证，运维团队也有丰富的 MySQL 运维经验。

• 由于以后业务也是基于 MySQL，中间件如果出现问题由中间件团队负责，但可以有更多的人力资源在开发、测试阶段利用已有经验。

3.1.5 - 可拓展性

• 消息队列的功能基本明确，无需扩展。

3.1.6 - 业务场景

• 可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。

3.1.7 - 技术声誉

• 有一定的风险，但是中间件团队对这个项目有信心，也有足够多的开发经验来支撑。

3.2 - 总体架构

• 总体架构设计如下图所示。

3.2.1 - 系统边界图

• 下图为系统边界图，既消息队列系统在后台服务中的层级。

• 消息队列系统内部只有两个主要子系统，既服务器层和存储层。

• 默认消息队列系统和外部的所有信息交换均由服务器层完成，故此不再展开。

• 消息队列管理系统是一个附加系统，它是消息队列系统的配置服务。

• 它不影响整体复杂度，反而能降低运维难度。

3.2.2 - 系统架构图

• 下图为系统架构图，既体现消息队列系统的内部组成和关系。

• 采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据。

• 每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步。

• 正常情况下，分组内的主服务器对外提供消息写入和消息读取服务，备服务器不对外提供服务。

• 主服务器宕机的情况下，备服务器对外提供消息读取的服务。

• 客户端采取轮询的策略写入和读取消息。

四、详细设计

实现机制：

• Java 语言编写消息队列服务器。

• 消息存储采用 MySQL 主备架构。

• SDK 轮询服务器进行消息写入。

• SDK 轮询服务器进行消息读取。

• MySQL 双机保证消息尽量不丢。

• 使用 Netty 自定义消息格式，并且支持 HTTP 接口。

4.1 - 核心功能

4.1.1 - 消息发布流程

• 消息队列系统设计两个角色：生产者和消费者，每个角色都有唯一的名称。

• 消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，SDK 采取轮询算法发起消息写入请求给主服务器。

• 如果某个主服务器无响应或者返回错误，SDK 将请求发送到下一台主服务，相当于在客户端实现了分片功能。

4.1.2 - 消息读取流程

• 消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，轮流向所有服务器发起消息读取请求。

• 消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪条消息，当收到消息读取请求时，返回下一条未被读 取的消息给消费者。

• 默认情况下主服务器提供读写服务，当主服务器挂掉后，从服务器提供读消息服务。

4.1.3 - 服务器主从切换

• 同一组的主从服务器配置相同的 Group 名称，在 ZooKeeper 建立对应的 PERSISENT 节点。

• 主从服务器启动后，在 ZooKeeper 对应的 Group 节点下建立 EPHEMERAL 节点，名称分为为 Master 和 Slave.

• 从服务器监控主服务器的 Master 节点状态，当 Master 节点超时被删除后，从服务器接管读消息，收到客户端 SDK 的读消息请求后返回消息，收到客户端 SDK 的写请求直接拒绝。

4.2 - 关键设计

4.2.1 - 消息发送可靠性

• 业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息。

• 当某个分组的主服务器无法发送消息时，SDK 挑选下一个分组主服务器重发消息，依次尝试所有主服务器直到发送成功。

• 如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

• 如果 SDK 缓存了一些消息未发送，此时恰好业务服务器又重启，则所有缓存的消息将永久丢失，这种情况 SDK 不做处理，业务方需要针对某些非常关键的消息自己实现永久存储的功能。

4.2.2 - 消息存储可靠性

• 消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。

• 如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计。

• DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

4.2.3 - 消息如何存储

• 每个消息队列对应一个 MySQL 表，消息队列名就是表名。

• 消息最主要的字段是：自增主键（按顺序插入、读取消息的关键）、payload（消息本身）、acknowledged（消息是否确认已被消费）

• 可以增加的字段是：resource_id（定位业务资源的 ID）、action（消息的操作是什么）等。

• 消息队列表应该保持简单：

• 类似于一个 Key-Value 的模式。

• 非常有必要分开的字段才分开。

• 不和其他表进行 join 操作。

• 字段设计如下，实际开发中根据业务调整，但是保持上述简单原则。

CREATE TABLE `t_queue_XXXXX` (    `id` bigint(18) NOT NULL AUTO_INCREMENT COMMENT '主键',    `resource_id` NOT NULL text COMMENT '根据业务，消息做的操作需要能够定位到一个内部或外部资源，此为该资源的 ID',    `action` text NOT NULL COMMENT '根据业务，消息做的操作到底是什么，对内例如增删改查，对外例如 HTTP 动词',    `payload` text NOT NULL COMMENT '消息内容，应该是一个JSON Object，但是14年的版本不支持，所以使用 text 类型',    `acknowledged` BOOLEAN NOT NULL DEFAULT false COMMENT '消息消费确认，若客户端确认消息已经被成功消费，则设置为 true，30 天过期系统自动清除',    `created_at` datetime NOT NULL DEFAULT '1970-01-01 10:10:10',    `updated_at` datetime NOT NULL DEFAULT '1970-01-01 10:10:10',    PRIMARY KEY (`id`),    KEY `created_at` (`created_at`),    KEY `acknowledged` (`acknowledged`)) ENGINE=InnoDB  DEFAULT CHARSET=utf8

4.3 - 设计规范

• 消息队列服务器使用 Spring Boot + Netty 开发。

• SDK 采用独立 Jar 包，可以集成到客户端项目中。

• 服务器基于 Netty 开发，采用 Reactor 网络模型。

• 两台服务器组成一个分区，整个系统可以多个分区，每个分区包含一主一从两台服务器。

• 服务器基于 ZooKeeper 进行主从切换。

• 客户端与服务端采用 TCP 连接，采用 JSON 传递数据。

• 为了兼容非 Java 系统，服务端同时提供 HTTP 接口。

• MySQL 使用 InnoDB 存储引擎。

• MySQL 采用主从同步。

• 消息表最多存储 30 天内的消息，过期的自动清除。

• 直接用 MySQL 的主从复制来实现数据复制。

五、质量设计

• 可测试性：

• 单元测试覆盖。

• 集成测试覆盖。

• 详细的代码文档、测试文档，方便测试团队使用。

• 可维护性：

• 手动上线、下线、切换主备服务器。

• 消息队列管理系统查询服务状态、停用成员队列。

• 消息队列管理系统可以下发配置、热更新配置。

• 可观测性：

• 消息队列管理系统检测消息队列的状态并上报展示。

• 消息队列管理系统提供信息查询。

• 全量日志可查询初期在基本监控系统，后期接入现有日志系统。

• 成本/安全：

• 开发团队人力资源六人，第一期工期三个月。

• 两台服务器组成一个分区，整个系统可以多个分区，每个分区包含一主一从两台服务器。

• 内部系统，消息队列服务只有在内网防火墙以内才可以访问。

• 同时，消息队列数据库采取网络隔离的方式也只能对内访问。

六、演进规划

• 消息队列一期：

• 开发基本消息队列功能，服务端和 SDK 能满足消息发送、读取的功能。

• 确保系统的可用性，做好基本的监控。

• 消息队列二期：

• 扩展其他的业务功能，例如延迟队列、多次消费。

• 整体接入现有的监控系统，继续提升系统的可用性。

• 消息队列三期：

• 完善消息队列管理系统，权限管理、配置管理与业务完全对接。

• 并继续提升系统的可用性。