架构实战营 - 详细架构设计文档

前言

• 本文档是关于在线游戏消息队列设计详细架构设计文档，用于指导消息队列的开发、测试和运维

• 基于前期与业务的讨论以及架构委员会的讨论，最终决定使用方案二：自研 + MySQL 存储方案【决策者：华仔，2020 年 4 月 30 日】

1. 业务背景

• 【存在的问题】由于游戏业务量迅速增加，业务拆分的服务越来越多，系统之间的调用采用服务之间直接调用的方式，造成了大量的问题：

• 性能较差：当用户发布一条微博后，需要同时更新多个系统，造成性能低，影响了业务和用户的体验

• 系统耦合严重，系统之间调用复杂，造成了业务迭代和演进效率变差

基于以上原因，我们决定采用消息中间件的方式，进行系统间解耦，将同步的调用改为异步通知

• 【价值】通过消息中间件的方式，可以提高系统性能，提高用户的体验；系统间耦合减少，增加了团队快速响应业务变化的需要

• 【目标】创建自己的消息中间件，来帮助业务完成这个任务：

• 性能足够支撑现有业务未来两年的需求

• 易于维护

• 成本相对低

2. 约束和限制

• 需要使用 Java 语言（团队成员主要语言为 Java）

• 需要符合集团的安全要求

• RPO < 20 Minutes, RTO < 1 Hour

• 不能使用 Oracle

3. 总体架构

3.1 架构分析

• 高可用性：消息涉及到玩家的金钱结算，所以需要保证消息不能丢失；如果发生宕机，对其它业务影响非常大

• 可维护性：维护操作方便，便于运维团队维护

• 成本：开发成本不能太高

3.2 总体架构

• 采用数据分散集群架构，每个分组存储一部分数据

• 每个分组的数据库，采用主备方式，保证数据的高可用。组之间数据不需要同步

• 客户端采用随机策略写入和读取消息

4. 详细设计

4.1 消息发送流程

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

2. 消息队列系统提供 SDK 给业务系统使用，SDK 从配置读取信息推送信息给消息服务器

3. 如果某个消息服务器没有响应或者返回错误，则将请求发送给下一个服务器
   

4.2 消息消费流程

1. 消息队列系统提供 SDK 给业务系统使用，用来从配置队列读取消息，轮询所有服务器发起消息读取请求

2. 消息队列服务器记录每个消费者的消费状态，当收到消息请求时，返回下一条未被读取的消息给消费者

3. 默认主服务器提供读写服务，主服务器挂掉后，从服务器提供消息存储服务

4.3 消息发送可靠性保障

1. 同一组的主从服务器配置相同的 group，使用 zookeeper 建立对应的节点

2. 在 zookeeper 对应的 group 节点下，名称分别为 master 和 slave

3. 如果发送失败，sdk 缓存信息，持续发送

4.4 消息存储可靠性

1. 数据库采用主备模式保证数据库高可用

2. 数据库进行告警设置，如果出现复制延迟，30s 以上，就告警并人工处理

4.5 消息如何存储

1. 每个消息队列对应一个 mysql 表，消息队列就是表名

2. 表结构设计中，id 对应消息 id，消息不可重复

3. 数据有效性为一个月，一个月后，数据将被迁移到备份存储中，用来提高 mysql 的性能

4.6 设计规范

1. Spring Boot

2. Netty

3. MySQL Innodb

4. React + fusion

5. 质量设计

1. 成本：小而美，sdk 先覆盖 java 技术栈，降低成本

2. 安全：内网访问，访问前需求鉴权，避免错用

3. 可测试性：写单元测试和自动化测试脚本，降低测试成本

6. 演进计划

1. 消息服务搭建，同步方式 sdk

2. 异步批量 sdk

3. 后台管理系统