本文为消息队列中间件详细架构设计文档，用于指导自主研发消息队列的后续开发、测试和运维。

业务背景

随着系统业务复杂度的增加，微服务/子系统数量逐渐增多且交互过程复杂。目前各服务间均是直接互相同步调用，系统耦合度过高，统一接口开发成本高，同时运维也较困难。可以引入消息中间件支持异步调用，将一些可以异步处理的逻辑使用消息中间件处理，可以帮助解耦系统，优化系统处理延迟，且将模块间的沟通标准化。

当前系统：

使用消息中间件：

约束和限制

• 必须在 2022 年 3 月 30 日前投入生产运行。

• 成本不超过 1000 万。

• 符合 ISO/IEC PRF 20922 标准。

总体架构方案

架构分析

• 高可用

需要保证消息写入，读取，存储的高可用，保证信息审核，用户奖励等机制运作正常。需要避免消息丢失，同时服务接口可用性达到 99.9%以上。

• 高性能

需要支撑 10 万 QPS。95%延迟在 100ms 以内。

(作业注: 此处基于虚拟业务场景假设，非实际数据)

• 可维护性

保证开发，扩展和运维可行性，符合现有系统整体运行方案和团队技术实力，现有运维团队较熟悉 HBase。

• 实现成本

开发人员及运维团队相关存储系统经验丰富，测试需要测试一个新系统，但存储部分不需要过多测试投入。

• 业务场景

可以支持业务定制化开发，如定制权限和定制预警系统。

总体架构设计

主备多集群。使用 HBase 存储数据。轮询服务器进行消息写入和读取。

详细设计

核心功能

• 消息写入

• 消息读取

关键设计

• 消息发送可靠性

业务服务器中使用消息队列系统 SDK，轮询发送消息。依次尝试所有主服务器直到发送成功；如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

*如果 SDK 缓存了一些消息未发送，同时业务服务器刚好重启，则所有缓存的消息将永久丢失，针对此情况业务方需要针对某些非常关键的消息自己实现永久存储的功能。或在消息失败时使原请求失败并重试。*

• 消息存储可靠性

HBase 存储消息，分多组处理请求和分别存储。每个分组有一主一备两台，主备之间复制消息。如果主备间出现复制延迟，且主服务器宕机导致数据无法恢复，则部分消息会永久丢失。需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

• 消息存储结构

每个消息队列对应一张表，表名为消息队列名，表结构为:

MessageId(主键 String) + Payload(消息内容) + DeliverTimestamp + LastConsumedTimstamp(读取时间)

（*DeliverTimestamp 在初步版本只使用消息创建时间，类似 CreationTimestamp，由消息队列服务器接口及逻辑控制。后续演进可考虑支持设置生效时间。)

设计规范

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

• 提供 HTTP 接口

• TCP 包首部结构:

• 源端口 Source Port

• 目的端口 Dest Port

• 序号 Seq Number

• 确认号 Ack

• 数据偏移 Offset

• 保留 Reserved

• 标志位 Tcp Flags

• 窗口 Window Size

• 校验和 Checksum

• 紧急指针 Urgent Pointer

• TCP 选项 TCP Options

质量设计

可观测性

• 监控消息队列服务器的请求收发情况，各队列的消息发送和消费速率，消息总存储。

• 操作日志。

可维护性

• 权限管理及配置管理。

• 消息队列维护工具，用于清理特定消息。

可测试性

• 消息队列本身需由完整单元测试及集成测试及压力测试覆盖。

• 提供标准集成测试接口，确保业务系统使用消息队列时能够方便进行集成测试。

成本

开发团队: 10 人。开发时间: 6 个月。

演进规划

• 一期版本

提供基本的消息收发及存储，高可用。

• 二期及后续版本

提供消息队列管理后台。支持设置消息发送(生效)时间。确保高性能。