备选方案模板
- 需求介绍
- 需求分析
- - 5W
  - 1H
  - 8C
- 复杂度分析
- - 高可用
  - 高性能
  - 可扩展
- 备选方案
- 备选方案评估
架构设计模板
- 总体方案
- 架构总览
- 核心流程
- 详细设计
- - 高可用设计
  - 高性能设计
  - 可扩展设计
  - 安全设计
  - 其他设计
  - 部署方案
架构演进规划

以类微博功能的消息队列为例，给出架构设计中最重要的两个文档的模板和关键说明。这个案例文档仅给出一些关键内容供参考，部分细节无法全面覆盖或者完全保证正确。

备选方案模板

需求介绍

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

随着业务的不断发展，业务上拆分的子系统越来越多，目前系统间的调用都是同步调用，由此带来几个明显的系统问题：

性能问题：当用户发布了一条微博后，微博发布子系统需要同步调用统计子系统、审核子系统、奖励子系统等共 8 个子系统，性能很低；
耦合问题：当新增一个子系统时，例如如果要增加广告子系统，那么广告子系统需要开发新的接口给微博发布子系统调用；
效率问题：每个子系统提供的接口参数和实现都有一些细微的差别，导致每次都需要重新设计接口和联调接口，开发团队和测试团队花费了许多重复工作量。

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

需求分析

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

5W

5W 指 Who、When、What、Why、Where。

Who：需求利益干系人，包括开发者、使用者、购买者、决策者等。
When：需求使用时间，包括季节、时间、里程碑等。
What：需求的产出是什么，包括系统、数据、文件、开发库、平台等。
Where：需求的应用场景，包括国家、地点、环境等，例如测试平台只会在测试环境使用。
Why：需求需要解决的问题，通常和需求背景相关

消息队列的 5W 分析如下：
Who：消息队列系统主要是业务子系统来使用，子系统发送消息或者接收消息。
When：当子系统需要发送异步通知的时候，需要使用消息队列系统。
What：需要开发消息队列系统。
Where：开发环境、测试环境、生产环境都需要部署。
Why：消息队列系统将子系统解耦，将同步调用改为异步通知。

1H

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

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

业务子系统发送消息给消息队列。
业务子系统从消息队列获取消息。

8C

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

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

消息对列的约束限制如下：

性能：需要达到 Kafka 的性能水平。
成本：参考 XX 公司的设计方案，不超过 10 台服务器。
时间：期望 3 个月内上线第一个版本，在两个业务尝试使用。
可靠性：按照业务的要求，消息队列系统的可靠性需要达到 99.99%。
安全性：消息队列系统仅在生产环境内网使用，无需考虑网络安全；如消息中有敏感信息，消息发送方需要自行进行加密，消息队列系统本身不考虑通用的加密。
合规性：消息队列系统需要按照公司目前的 DevOps 规范进行开发。
技术性：目前团队主要研发人员是 Java，最好用 Java 开发。
兼容性：之前没有类似系统，无需考虑兼容性。

实际操作的时候每个约束和限制都要有详细的逻辑推导，避免完全拍脑袋式决策

复杂度分析

分析需求的复杂度，复杂度常见的有高可用、高性能、可扩展等

识别复杂度

高可用

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

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

高性能

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

可扩展

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

备选方案

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

备选方案 1：直接引入开源 Kafka
此处省略方案描述
备选方案 2：集群 + MySQL 存储
此处省略方案描述
备选方案 3：集群 + 自研存储
此处省略方案描述

备选方案评估

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

备选方案及评估

架构设计模板

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

总体方案

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

架构总览

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

核心流程

消息发送流程
此处省略流程描述
消息读取流程
此处省略流程描述

详细设计

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

高可用设计

消息发送可靠性
此处省略具体设计内容
消息存储可靠性
此处省略具体设计内容
消息读取可靠性
此处省略具体设计内容

高性能设计

此处省略具体设计

可扩展设计

此处省略具体设计

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

安全设计

消息队列系统需要提供权限控制功能，权限控制包括两部分：身份识别和队列权限控制。

身份识别
省略具体内容
队列权限
省略具体内容

其他设计

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

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

部署方案

部署方案主要包括硬件要求、服务器部署方式、组网方式等。例如：

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

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

架构演进规划

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

整个消息队列系统分三期实现：
第一期：实现消息发送、权限控制功能，预计时间 3 个月。
第二期：实现消息读取功能，预计时间 1 个月。
第三期：实现主备基于 ZooKeeper 切换的功能，预计时间 2 周。

--------来源《极客课程》∙ 学习摘要

架构设计文档模板参考相关推荐

架构实战：架构设计文档模板
在前面的专栏里,有同学留言说想看看具体的架构设计文档.由于信息安全的原因,再加上稍微复杂的系统,设计文档都是几十页,因此专栏无法直接给出详细的文档案例.但我认为提供一个架构设计文档模板还是很有必要的, ...
架构设计文档模板之1：备选方案模板
备选方案模板 1.需求介绍 [需求介绍主要描述需求的背景.目标.范围等] 随着前浪微博业务的不断发展,业务上拆分的子系统越来越多,目前系统间的调用都是同步调用,由此带来几个明显的系统问题: 性能问题: ...
深入浅出MFC文档/视图架构之文档模板
在"文档/视图"架构的MFC程序中,提供了文档模板管理者类CDocManager,由它管理应用程序所包含的文档模板.我们先看看这个类的声明: / // CDocTemplate m ...
【其他】接口设计文档模板
前言后端接口设计文档,个人认为需要告知接口调用者的内容博客地址:芒果橙的个人博客 [http://mangocheng.com] 接口设计说明-xx系统修改记录本次修改记录,每次更新后删除,只 ...
服务器架构设计文档,架构设计文档
很多同学问做架构设计,怎么才能写出比较好的文档.其实很简单,都是有套路的,今天刚好借这个机会,和大家分享下一般做架构设计该怎么写文档. 背景首先介绍下项目背景.基于什么原因需要需求. 如果是新产品, ...
论坛通用架构设计文档
1.解决方案概述 1.1 假设条件: 考虑本论坛的快速发展, 按最理想情况, 可能三年内总主题, 会到接近千万水平. 为保证架构的扩展性, 本项目假设主题数为最大值的十倍, 作为架构设计参考数据量. ...
魔力魔力哟架构设计文档
巴渝工匠比赛教学管理系统架构设计(样题) 2021年07月文件状态: [ ] 草稿 [√] 正式发布 [ ] 正在修改文件标识: 当前版本: V1.2 作者: xxx 完成日期: 2 ...
架构设计文档提纲简描
提纲很简单的: 一.概述二.目的三.项目背景四.系统建设目标五.参考资料六.架构设计 6.1 架构分析 6.2 设计思想 6.3 架构体系 6.4 系统视图 6.5 模块划分 6.5.1 模 ...
10 架构设计文档-致远OA
架构设计一:现状 1. 致远代码的运行环境:只有spring mvc ,没有spring boot/spring cloud 场景行号技术名称备注 1 spring 版本 4.3.29.REL ...

架构设计文档模板参考

目录