参考推荐：架构设计文档模板结构

备选方案模板

1.需求介绍

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

随着XX微博业务的不断发展，业务上拆分的子系统越来越多，目前系统间的调用都是同步调用，存在如下问题：

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

耦合问题：当新增一个子系统时，例如如果要增加“广告子系统”，那么广告子系统需要开发一个新的接口给微博发布子系统调用

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

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

2.需求分析

[需求分析主要全方位描述需求相关信息]

5W

[5W指Who、When、What、Why、Where]

Who：需求利益干系人，包括开发者、使用者、购买者、决策者等。

When：需求使用时间，包括季节、时间、里程碑等

What：需求的产出是什么，包括系统、数据、文件、开发库、平台等

Where：需求的应用场景，包括国家、地点、环境等，例如测试平台只会在测试环境使用

Why：需求需要解决的问题，通常和需求背景相关

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

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

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

What：需要搭建消息队列系统

Where：开发、测试、预发、生产都要搭建

Why：消息系统将子系统解耦，将同步调用改为异步调用

1H

[这里的How不是设计方案也不是架构方案，而是关键业务流程，如一个系统怎么发消息给另一个系统，比如在什么情况下发消息，这部分可以独立成“用例文档”]

消息队列有两大核心功能：

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

业务子系统从消息队列获取消息

8个约束限制

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

性能：达到RocketMQ的性能水平

成本：参考XX公司的设计方案，不超过10台服务器

时间：希望3个月内上线第一个版本，在两个业务尝试使用

可靠性：按照业务的要求，消息队列系统的可靠性需要达到99.99%

安全性：消息队列系统在内网使用，不用考虑网络安全问题

合规性：消息队列系统需要按照公司目前的DevOps规范进行开发

技术性：目前团队开发主要人员是Java，最好用Java开发

兼容性：之前没有类似系统，无需考虑兼容性

3.复杂度分析

[分析需求的复杂度，复杂度常见的有高可用、高性能、可扩展等，具体分析方法mindmap]

高可用

对于微博子系统来说，如果消息丢失了，导致没有审核，然后触犯了国家法律法规，则是非常严重的事情；对于等级子系统来说，如果用户达到相应等级后，系统没有给他奖品和专属服务，则VIP用户会很不满意，导致用户流失，从而损失收入，虽然也比较关键，但没有审核子系统丢失消息那么严重。

综合来看，消息队列需要高可用，包括消息写入，消息存储，消息读取，都需要高可用性。

高性能

微博系统用户每天发送1000万条微博，那么微博子系统一天会产生1000万条消息，平均一个消息有10个子系统读取，那么其他子系统读取的消息大约是1亿次。将数据按照秒来计算，平均没秒写入消息115条，读取1150条，再考虑系统的读写并不是完全平均的，设计的目标应该是以峰值来计算。峰值一般是平均值的3倍，则消息系统的TPS是345，QPS是3450，考虑一定的性能余量。为了预留一定的系统容量应对后续业务的发展，我们将设计目标定位峰值的4倍。因此最终的性能要求是：TPS1380，QPS13800。TPS为1380并不高，但QPS13800已经很高了，因此高性能读取是复杂度之一。

可扩展

消息队列的功能很明确，基本无需扩展，因此扩展性不是这个消息队列的关键复杂度。

4.备选方案

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

备选方案1：引入RocketMQ

[此处省略方案描述]

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

[此处省略方案描述]

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

[此处省略方案描述]

5.备选方案评估

架构设计模板

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

1、总体方案

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

2、架构总览

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

3.核心流程

消息发送流程

[此处省略流程描述]

消息读取流程

[此处省略流程描述]

4.详细设计

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

高可用设计

消息发送可靠性

[略]

消息存储可靠性

[略]

消息读取可靠性

[略]

高性能设计

[略]

可扩展设计

[略]

其他设计

[其他设计包括上述以外的其他设计考虑点，例如指定开发语言、符合公司的某些标准等，如果篇幅较长，也可以独立进行描述]

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

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

部署方案

[部署方案主要包括硬件要求、服务器部署方式、组网方式等]

5.架构演进规则

[通常情况下，规划和设计的需求比较完善，但如果一次性全部做完，项目周期可能会很长，因此可以采取分阶段实施，即：第一期做什么、第二期做什么，以此类推]

整个消息队列系统分为三期实现：

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

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

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