1. 项目背景与需求分析
业务背景
随着“星云严选”电商平台的业务版图不断扩张，为了支撑高并发与业务复杂性，我们将单体架构逐步拆分为微服务架构。目前，核心的“交易中心”与其他下游业务子系统之间仍采用**同步远程调用(RPC)的方式进行通信。
当前痛点这种强依赖的同步调用模式，在业务高峰期暴露出了以下三个核心架构瓶颈：
响应延迟（性能瓶颈）：目前用户完成一笔“下单”操作后，交易中心必须同步等待“库存中心”扣减、“风控中心”扫描、“积分中心”累积、“物流中心”履约等 8 个子系统全部返回成功响应。这导致用户端的下单接口响应时间（RT）过长，严重影响购物体验。
扩展受限（耦合瓶颈）：系统间存在高度紧耦合。例如，运营团队计划新增一个“实时大屏统计子系统”来监控大促数据，这要求交易中心必须修改核心代码并开发新接口来主动调用该系统。每新增一个下游业务消费者，核心交易链路就必须跟随变更，违反了“开闭原则”。
研发效能（效率瓶颈）：由于下游各子系统的接口定义（参数结构、协议标准）存在细微差异，交易中心团队需要针对每个子系统进行定制化的接口适配与联调。这种点对点的网状集成方式，导致开发与测试团队陷入了大量的重复性劳动，交付效率低下。
2. 需求分析
[需求分析主要全方位地描述需求相关的信息]
自研分布式消息中间件需求分析报告
1. 5W 维度分析
👥 Who (利益干系人/用户角色)
构建者： 基础架构研发团队（负责中间件的设计、开发与运维）。
使用者： 业务线研发团队（如交易中心、营销中心等，作为消息的生产者和消费者）。
赞助者： CTO 及技术委员会（关注技术战略落地与成本控制）。
⏰ When (触发时机/生命周期)
运行时： 当上游业务系统需要解耦非核心逻辑、进行流量削峰填谷，或实现跨系统数据最终一致性时触发使用。
项目节点： 需配合 Q3 季度的大型营销活动上线，作为底层支撑组件。
📦 What (产出物/交付成果)
核心服务端： 高可用、分布式的消息代理集群（Broker）。
客户端 SDK： 提供标准的 Java 客户端开发包，封装网络通信与序列化细节。
管理控制台： 用于Topic管理、消息轨迹追踪和集群监控的 Web 平台。
🌍 Where (应用场景/部署环境)
物理环境： 覆盖开发（Dev）、测试（Test）、预发布（Staging）及生产（Prod）全套环境。
网络环境： 仅限公司私有云内网（Intranet）部署，不暴露公网入口。
🎯 Why (核心驱动力/价值主张)
架构升级： 打破服务间的同步调用链，消除强耦合，降低系统雪崩风险。
提升吞吐： 通过异步化处理，显著降低核心链路的响应时间（RT），提升用户体验。
2. 1H 关键业务流程
本系统核心遵循 发布/订阅 (Publish/Subscribe) 模型，包含两个最基础的原子流程：
消息投递 (Publish)：
上游业务系统（Producer）将业务数据（如“订单已创建”）封装为标准消息体。
Producer 通过 SDK 与负载均衡策略，将消息发送至服务端（Broker）。
Broker 接收并持久化存储成功后，返回 ACK 确认。
消息消费 (Subscribe)：
下游业务系统（Consumer）启动时向 Broker 订阅感兴趣的话题（Topic）。
Consumer 从 Broker 拉取（Pull）或被推送（Push）消息。
业务逻辑处理完成后，Consumer 向 Broker 反馈消费成功状态，Broker 更新消费进度（Offset）。
3. 8C 约束与限制 (Constraints & Limitations)
基于当前资源与业务现状，项目组需严格遵守以下非功能性需求（NFR）：
| 维度 | 约束详情 | 设计考量与调整空间 |
| ⚡ 性能 (Performance) | 对标 Kafka：
|
|
| 💰 成本 (Cost) | TCO 控制：
|
|
| ⏳ 时间 (Time) | MVP 交付：
|
|
| 🛡️ 可靠性 (Reliability) | SLA 标准：
|
|
| 🔒 安全性 (Security) | 内网信任：
|
|
| ⚖️ 合规性 (Compliance) | 研发规范：
|
|
| 🛠️ 技术性 (Technology) | 技术栈统一：
|
|
| 🔌 兼容性 (Compatibility) | Greenfield 项目：
|
|
3. 复杂度分析
[分析需求的复杂度，复杂度常见的有高可用、高性能、可扩展等]
3.1 高可用性分级与策略
系统容灾等级的设定遵循“木桶效应”原则，即必须满足对稳定性要求最严苛的业务链路。基于对下游业务影响面的分析，我们得出以下结论：
一级风险管控（合规性红线）：以内容审核子系统为代表，该链路对消息丢失持有“零容忍”态度。一旦审核消息丢失导致违规内容发布，将直接触犯法律法规，引发严重的监管风险。
二级风险管控（资产与体验）：以“等级与奖励子系统”为代表，该链路涉及用户核心资产。虽然其故障后果主要体现为用户投诉与收入流失，严重程度略低于法律合规风险，但仍属于核心业务范畴。
🔴 架构决策：综合考虑，系统必须对标一级风险管控标准，构建全链路高可用架构。这意味着从消息接收（写入）、持久化存储、到消息分发读取)的每一个环节，都必须具备冗余容灾能力，确保数据不丢失、服务不中断。
3.2 性能估算与容量规划
基于现有业务规模，结合互联网流量的潮汐特性与未来增长预期，我们采用峰值倍率法进行容量测算。
1. 基础流量模型
写入量基准： 参考前浪微博目前的业务量级，每日产生的微博发布（写入）消息约为 1000 万条。
读写放大比： 平均每条消息需分发给 10 个下游子系统处理，因此每日的消息读取量约为 1 亿次。
2. 负载推演逻辑
平均负载： 若将全天流量平摊到每一秒，平均每秒的写入量（TPS）约为 115 次，读取量（QPS）约为 1150 次。
峰值负载（3倍）： 考虑到用户活跃时间的集中性（如晚高峰、热点事件），系统设计不能仅参考平均值。按照通用的 3 倍峰值系数计算，峰值 TPS 约为 345，峰值 QPS 约为 3450。
系统设计目标（4倍冗余）： 鉴于当前业务基数较低，且需预留空间应对未来的业务爆发，我们在峰值负载的基础上，进一步预留 4 倍的性能余量作为最终设计目标。
3. 最终性能指标 (SLA)基于上述推演，消息队列系统的最终交付标准确定为：
写入性能目标 (TPS)：1,380 (次/秒)
读取性能目标 (QPS)：13,800 (次/秒)
💡 复杂度评估：分析表明，TPS 1380 对主流中间件而言压力较小；但 QPS 13800 已达到较高的并发水位。“高读写比”是本系统的显著特征，因此，如何保证高并发下的读取效率（如优化缓存命中率、减少IO开销）将是架构设计的核心挑战。
可扩展
消息队列的功能很明确，基本无须扩展，因此可扩展性不是这个消息队列的关键复杂度。
4. 备选方案
针对前述的高可用与高性能需求，项目组初步制定了三套架构演进方向，具体如下：
备选方案一：成熟开源组件引入（基于 Kafka）
方案定义： 直接引入业界成熟的开源消息中间件 Kafka，进行适配性封装。
核心特征： 站在巨人的肩膀上。利用 Kafka 极高的吞吐量和完善的生态，快速满足性能需求，尽量减少重复造轮子。
[此处省略具体实施细节...]
📋 备选方案二：自研代理层 + 通用存储（Cluster + MySQL）
方案定义： 采用“计算与存储分离”架构。自研基于 Java 的消息代理集群（Broker）负责协议解析与流量分发，底层采用公司技术栈最成熟的 MySQL 作为持久化存储引擎。
核心特征： 架构可控性强，且极大降低了存储层的开发复杂度与运维门槛（直接复用现有的 DBA 运维能力）。
[此处省略具体实施细节...]
📋 备选方案三：完全自研分布式架构（Cluster + 自研文件存储）
方案定义： 深度自研方案。参考 Kafka 的日志存储模型，使用 Java 编写应用层，并直接针对文件系统（File System）开发专用的消息存储引擎，绕过通用数据库。
核心特征： 追求极致性能与完全自主可控，旨在从底层 I/O 层面进行针对性优化。
[此处省略具体实施细节...]
------架构设计模板-----
[备选方案评估后会选择一个方案落地实施，架构设计文档就是用来详细描述细化方案的]
1. 总体方案
[总体方案需要从整体上描述方案的结构，其核心内容就是架构图，以及针对架构图的描述，包括模块或者子系统的职责描述、核心流程]
2. 架构总览[架构总览给出架构图以及架构的描述]
分布式分片与分组模型
数据分散集群： 系统的存储层被逻辑划分为多个独立的数据分组。每个分组承载并存储全部消息数据的一个子集。
分组隔离性： 分组之间的数据存储和操作是完全独立的，数据不进行跨组同步。这种 Shared-Nothing 架构有助于系统的横向扩展（Scale-Out）能力和隔离故障。
存储结构： 每个数据分组是自包含的，由一对主/备 MySQL 实例构成，专门用于该分组的消息持久化存储。
高可用与读写分离策略
数据冗余： 在同一数据分组内部，主（Primary）MySQL 与 备（Secondary）MySQL 之间配置了实时数据复制（Master-Slave Replication）。这确保了分组内数据的持久性和高可用性。
正常运行状态：
主节点： 同时承担该分组内的全部消息写入和消息读取服务，保持读写活跃状态。
备节点： 处于热备状态，不主动对外提供服务。
故障转移策略（降级服务）：
当主节点发生宕机或不可用时，备节点将立即被激活并接管，对外提供消息读取服务，确保服务连续性。
注：消息写入服务的故障转移和数据恢复策略需另行设计（例如，需确保Primary宕机后的写入数据不会丢失）。
客户端负载均衡机制 (Client Load Balancing)
客户端（包含生产者 Producer 和消费者 Consumer）集成了内置的负载均衡逻辑：
访问策略： 客户端采用**轮询（Round-Robin）**策略，将消息写入请求分散到不同的数据分组的主节点，同时将消息读取请求分散到所有可用的主节点（及故障时的备节点）。
目标： 通过客户端级别的轮询机制，实现读写流量在整个分片集群中的均匀分布，避免出现热点分区，提升整体吞吐量。
3. 核心流程消息发送流程
[此处省略流程描述]
消息读取流程
[此处省略流程描述]
4. 详细设计
[详细设计需要描述具体的实现细节]
高可用设计
本消息队列系统的可靠性设计围绕消息发送、消息存储和消息读取三个核心环节展开，其特点是客户端多轮重试与部分风险交由外部运维（DBA）或业务方承担。
1. 消息发送可靠性 (Producer Reliability)
| 机制 | 描述 | 限制与责任归属 |
| 重试策略 |
|
SDK 本地缓存不保证持久性。
|
| 最终失败 |
|
|
2. 消息存储可靠性
| 机制 | 描述 | 限制与责任归属 |
| 高可用存储 |
|
不对复制延迟导致的数据丢失做系统设计。
|
3. 消息读取与服务高可用
| 机制 | 描述 | 限制与责任归属 |
| 主备模式 |
|
依赖外部协调服务。
|
| 故障判断 |
|
故障判断时间受 ZooKeeper 节点超时时间限制。 |
[此处省略具体设计]
可扩展设计
[此处省略具体设计]
安全设计
消息队列系统将权限控制设计为两层防护机制，以确保系统安全和数据隔离。
1. 身份认证（Authentication）
目标： 防止恶意或未经授权的系统接入。
机制： 系统为接入的业务子系统分配唯一的身份标识（ID）和接入密钥（Access Key）。
校验流程： SDK 必须在建立连接时进行身份校验。校验失败的连接将被服务器立即中断。
2. 队列权限控制（Authorization）
目标： 实现对敏感队列的精细化访问控制（谁能发、谁能读）。
机制： 队列的读写权限保存在配置文件中（基于身份标识）。
执行流程： 消息队列服务器在处理发送或读取消息的请求时，会根据子系统的身份标识实时查询配置权限，拒绝任何未经授权的操作。
其他设计
[其他设计包括上述以外的其他设计考虑点，例如指定开发语言、符合公司的某些标准等，如果篇幅较长，也可以独立进行描述]
部署方案
服务器部署策略：资源共置 (Resource Co-location)
部署方式： 采用混合部署策略。消息队列服务器（Broker）与其对应的 MySQL 数据库服务器将部署在同一台物理服务器上。
部署映射：
主节点组： 同一分组的主服务器（MQ Broker）与主 MySQL 实例部署在同一物理节点。
备节点组：备服务器（MQ Broker）与备 MySQL 实例部署在另一物理节点。
设计依据：
资源互补： 消息队列服务器的核心压力在计算资源（CPU 密集型）；而 MySQL 数据库的核心压力在磁盘 I/O 资源（I/O 密集型）。
效益： 这种互补性部署有助于最大化利用单台服务器的资源，理论上互相影响的几率较低。
硬件与环境要求 (Hardware Specification)
为满足系统的高性能和低延迟要求，对基础硬件进行如下规范：
服务器类型： 必须采用物理服务器（Bare-Metal Servers）部署，不使用虚拟化环境。
硬件规格要求：
CPU： 32 核心 (Cores)
内存： 48 GB RAM
存储： 512 GB SSD 硬盘 (必须是高性能固态硬盘)
选型依据：
性能要求： 核心业务对性能要求极高，选用物理服务器可以避免虚拟化带来的性能损耗和资源竞争。
动态扩容需求： 考虑到消息队列系统的动态缩扩容频率预计不高，使用物理机在性能上更具优势和稳定性。
5. 架构演进规划
[通常情况下，规划和设计的需求比较完善，但如果一次性全部做完，项目周期可能会很长，因此可以采取分阶段实施，即：第一期做什么、第二期做什么，以此类推]
整个消息队列系统分三期实现：
第一期：实现消息发送、权限控制功能，预计时间 3 个月。
第二期：实现消息读取功能，预计时间 1 个月。
第三期：实现主备基于 ZooKeeper 切换的功能，预计时间 2 周。