我认为提供一个架构设计文档模板还是很有必要的，这样可以在你进行实际架构设计时更方便地编写相关文档。以下是以“二进制微博”消息队列为例，给出架构设计中最重要的两个文档模板和关键说明。这个案例文档仅展示一些关键内容供你参考，部分细节无法全面覆盖或完全保证准确

备选方案模板

1. 需求介绍

[需求介绍主要描述需求的背景、目标、范围等]

随着前浪微博业务的不断发展，系统拆分出的子系统越来越多。目前，系统间的调用都是同步调用，由此带来了一些明显的问题：

1. 性能问题：当用户发布一条微博后，微博发布子系统需要同步调用“统计子系统”、“审核子系统”、“奖励子系统”等共8个子系统，导致性能很低。

2. 耦合问题：当新增一个子系统时，例如新增“广告子系统”，广告子系统需要开发新的接口供微博发布子系统调用，增加了系统间的耦合。

3. 效率问题：每个子系统提供的接口参数和实现都有一些细微的差别，导致每次都需要重新设计接口和联调接口，开发团队和测试团队因此花费了大量重复工作。

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

2. 需求分析

需求分析主要全方位地描述需求相关的信息

5W

Who：消息队列系统主要由业务子系统使用，这些子系统负责发送消息或接收消息。

When：当子系统需要进行异步通知时，就需要使用消息队列系统。

What：需要开发一个消息队列系统。

Where：消息队列系统需要在开发环境、测试环境和生产环境中部署。

Why：消息队列系统用于解耦各子系统，将同步调用改为异步通知，从而提高系统性能和灵活性。

消息队列的 5W 分析如下：

• Who：消息队列系统主要是业务子系统来使用，子系统发送消息或者接收消息。

• When：当子系统需要发送异步通知的时候，需要使用消息队列系统。

• What：需要开发消息队列系统。

• Where：开发环境、测试环境、生产环境都需要部署。

• Why：消息队列系统将子系统解耦，将同步调用改为异步通知。

1H

[这里的 How 不是设计方案也不是架构方案，而是关键业务流程。消息队列系统这部分内容很简单，但有的业务系统 1H 就是具体的用例了，有兴趣的同学可以尝试写写 ATM 机取款的业务流程。如果是复杂的业务系统，这部分也可以独立成“用例文档”]

1. 业务子系统发送消息给消息队列

• 子系统在需要通知其他子系统时，将消息发送到消息队列。

• 消息队列接收消息并进行持久化存储，确保消息不丢失。

• 子系统从消息队列中获取消息并进行处理。

• 消息队列确保消息的有序性和可靠性，将消息按顺序推送给订阅者

8C

[8C 指的是 8 个约束和限制，即 Constraints，包括性能 Performance、成本 Cost、时间 Time、可靠性 Reliability、安全性 Security、合规性 Compliance、技术性 Technology、兼容性 Compatibility]

注：需求中涉及的性能、成本、可靠性等仅仅是利益关联方提出的诉求，不一定准确；如果经过分析有的约束没有必要，或成本太高、难度太大，这些约束是可以调整的。

性能：

• 系统需要达到 Kafka 的性能水平。

成本：

• 参考某公司的设计方案，服务器数量不超过 10 台。

时间：

• 期望在 3 个月内上线第一个版本，并在两个业务系统中试用。

可靠性：

• 根据业务需求，消息队列系统的可靠性需要达到 99.99%。

安全性：

• 消息队列系统仅在生产环境内网使用，无需考虑网络安全。如果消息中包含敏感信息，发送方需自行进行加密，消息队列系统本身不负责通用加密。

合规性：

• 消息队列系统的开发需要遵循公司现有的 DevOps 规范。

技术性：

• 由于团队的主要研发人员是 Java 开发人员，因此最好采用 Java 进行开发。

3. 复杂度分析

高可用性

对于微博子系统来说，如果消息丢失，导致未经过审核就发布消息，这将严重违反国家法律法规，后果非常严重。对于等级子系统来说，如果用户达到相应等级后未能及时获得奖品和专属服务，VIP 用户会非常不满，可能导致用户流失和收入损失。虽然等级子系统的情况也很关键，但相较于审核子系统丢消息的后果要轻一些。

因此，消息队列系统需要保证高可用性，确保消息写入、消息存储和消息读取都具有高可用性。

高性能

前浪微博系统用户每天发送 1000 万条微博，微博子系统每天会产生 1000 万条消息。假设每条消息有 10 个子系统读取，那么其他子系统每天的消息读取量大约为 1 亿次。按秒计算，一天内平均每秒写入消息数为 115 条，每秒读取消息数为 1150 条。考虑到系统读写并非完全均匀分布，设计目标应基于峰值计算。通常峰值取平均值的 3 倍，那么消息队列系统的 TPS（每秒事务处理数）为 345，QPS（每秒查询处理数）为 3450。为了预留系统容量以应对未来业务增长，设计目标设定为峰值的 4 倍，因此最终性能要求为：TPS 为 1380，QPS 为 13800。TPS 为 1380 并不算高，但 QPS 为 13800 已经比较高了，因此高性能读取是系统的一个复杂度。

可扩展性

消息队列的功能相对明确，基本不需要扩展，因此可扩展性不是这个消息队列系统的关键复杂度。

4. 备选方案

[备选方案设计，至少 3 个备选方案，每个备选方案需要描述关键的实现，无须描述具体的实现细节。]

备选方案 1：直接引入开源 Kafka

[此处省略方案描述]

备选方案 2：集群 + MySQL 存储

[此处省略方案描述]

备选方案 3：集群 + 自研存储

[此处省略方案描述]

5. 备选方案评估

[备选方案 360 度环评，注意备选方案评估的内容会根据评估会议的结果进行修改，也就是说架构师首先给出自己的备选方案评估，然后举行备选方案评估会议，再根据会议结论修改备选方案文档]

架构设计模板

[备选方案评估后会选择一个方案落地实施，架构设计文档就是用来详细描述细化方案的]

1. 总体方案

[总体方案需要从整体上描述方案的结构，其核心内容就是架构图，以及针对架构图的描述，包括模块或者子系统的职责描述、核心流程]

2. 架构总览

[架构总览给出架构图以及架构的描述]

• 采用数据分散集群架构，集群中的服务器被分成若干分组，每个分组负责存储部分消息数据。

• 每个分组包含一台主 MySQL 服务器和一台备 MySQL 服务器，分组内的主备服务器进行数据复制，但不同分组之间的数据不同步。

• 在正常情况下，分组内的主服务器负责对外提供消息的写入和读取服务，备服务器不对外提供服务；当主服务器宕机时，备服务器将负责对外提供消息读取服务。

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

3. 核心流程

消息发送流程

[此处省略流程描述]

消息读取流程

[此处省略流程描述]

4. 详细设计

[详细设计需要描述具体的实现细节]

高可用设计

消息发送可靠性

• 业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息。当某个分组的主服务器无法发送消息时，SDK 会挑选下一个分组的主服务器重新发送消息，依次尝试所有主服务器直到发送成功。如果所有主服务器都无法发送消息，SDK 可以选择缓存消息或直接丢弃消息，具体策略可以在启动 SDK 时通过配置指定。

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

消息存储可靠性

• 消息存储在 MySQL 中，每个分组有一台主 MySQL 服务器和一台备 MySQL 服务器，主备服务器之间进行消息复制以保证消息存储的高可用性。如果主备间出现复制延迟，且此时主 MySQL 服务器宕机导致数据无法恢复，则部分消息会永久丢失。对此情况不做特殊设计，DBA 需要监控主备间的复制延迟，当复制延迟超过 30 秒时，需要及时告警并进行处理。

消息读取可靠性

• 每个分组有一台主服务器和一台备服务器，主服务器支持消息的发送和读取，备服务器仅支持消息读取。当主服务器正常运行时，备服务器不对外提供服务；当备服务器检测到主服务器故障时，才会对外提供消息读取服务。

• 主备服务器的角色和分组信息通过配置指定，并通过 ZooKeeper 进行状态判断和决策。主备服务器启动时分别连接到 ZooKeeper，在 /MQ/Server/[group] 目录下创建 EPHEMERAL 节点。例如，分组名称为 group1，则主服务器节点为 /MQ/Server/group1/master，备服务器节点为 /MQ/Server/group1/slave。节点的超时时间可以配置，默认为 10 秒。

高性能设计

[此处省略具体设计]

可扩展设计

[此处省略具体设计。如果方案不涉及，可以简单写上“无”，表示设计者有考虑但不需要设计；否则如果完全不写的话，方案评审的时候可能会被认为是遗漏了设计点]

无

安全设计

消息队列系统权限控制功能

身份识别

• 消息队列系统为业务子系统分配身份标识和接入密钥。SDK 在建立连接时需要进行身份校验，消息队列服务器会中断未通过校验的连接。因此，任何业务子系统若想接入消息队列系统，必须首先申请身份标识和接入密钥，通过这种方式防止恶意系统随意接入。

队列权限控制

• 某些队列信息可能比较敏感，仅允许部分子系统发送或读取。消息队列系统将队列权限保存在配置文件中，当收到发送或读取消息的请求时，首先根据业务子系统的身份标识及配置的权限信息判断其是否有权限，若无权限则拒绝服务。

其他设计

开发语言及标准

• 消息队列系统需采用公司指定的开发语言，遵循公司标准。

运维集成

• 消息队列系统需接入公司已有的运维平台，通过运维平台进行发布和部署。

监控集成

• 消息队列系统需输出日志到公司现有的监控平台，通过监控平台监控系统健康状态，包括发送消息的数量、大小及积压消息数量等。详细监控指标将在后续设计方案中列出。

部署方案

硬件要求和服务器部署方式

• 消息队列系统的服务器和数据库服务器采取混合部署的方式，即在同一台服务器上部署同一分组的主服务器和主 MySQL，或者备服务器和备 MySQL。因为消息队列服务器主要是 CPU 密集型，而 MySQL 是磁盘密集型，所以两者混合部署时互相影响的几率不大。

硬件基本要求

• 32 核 CPU，48G 内存，512G SSD 硬盘。考虑到消息队列系统动态扩容的需求不高，且对性能要求较高，因此需要使用物理服务器，不采用虚拟机。

架构演进规划

分阶段实施

• 由于规划和设计的需求较为完善，但如果一次性全部完成，项目周期可能会很长，因此可以采取分阶段实施的方式。

实现计划

• 第一期：实现消息发送和权限控制功能，预计时间为 3 个月。

• 第二期：实现消息读取功能，预计时间为 1 个月。

• 第三期：实现基于 ZooKeeper 的主备切换功能，预计时间为 2 周。