## 前言

终于，我们跨越了架构设计最艰难的阶段——备选方案的设计与抉择。当最终方案尘埃落定之后，许多架构师会不由自主地松一口气，以为大功即将告成。然而，真正的落地才刚刚开始。

如果说备选方案设计是勾勒宏伟蓝图，那么详细方案设计就是将这幅蓝图一笔一笔地描绘出来，每一个笔触都需要精准到位。这不再是天马行空的创造，而是脚踏实地的工程。架构师需要将方案涉及的关键技术细节确定下来，使得备选方案变成一个可以真正落地的设计方案。这，就是架构设计流程的第 4 步——也是将梦想变为现实的关键一步。

## 详细方案设计

### 细化：从抽象到具体

详细方案设计就是将方案涉及的关键技术细节给确定下来。这个阶段需要回答一系列具体的问题：

假如我们确定使用 **Elasticsearch** 来做全文搜索，那么就需要确定：

- Elasticsearch 的索引是按照业务划分，还是一个大索引就可以了？
- 副本数量是 2 个、3 个还是 4 个？
- 集群节点数量是 3 个还是 6 个？

假如我们确定使用 **MySQL 分库分表**，那么就需要确定：

- 哪些表要分库分表？
- 按照什么维度来分库分表？
- 分库分表后联合查询怎么处理？

假如我们确定引入 **Nginx** 来做负载均衡，那么就需要确定：

- Nginx 的主备怎么做？
- Nginx 的负载均衡策略用哪个？

### 技术选型与细节选择：轻量级的抉择

详细设计方案里面其实也有一些技术点和备选方案类似，但这里的技术方案选择是很轻量级的，我们无须像备选方案阶段那样操作，只需要简单根据这些技术的适用场景选择就可以了。

以 **Nginx 的负载均衡策略**为例：

| 策略 | 适用场景 |
|------|----------|
| 轮询（默认） | 每个请求按时间顺序逐一分配到不同的后端服务器，后端服务器分配的请求数基本一致，如果后端服务器"down 掉"，能自动剔除 |
| 加权轮询 | 根据权重来进行轮询，权重高的服务器分配的请求更多，主要适应于后端服务器性能不均的情况 |
| ip_hash | 每个请求按访问 IP 的 hash 结果分配，这样每个访客固定访问一个后端服务器，主要用于解决 session 的问题 |
| fair | 按后端服务器的响应时间来分配请求，响应时间短的优先分配，能够最大化地平衡各后端服务器的压力 |
| url_hash | 按访问 URL 的 hash 结果来分配请求，每个 URL 定向到同一个后端服务器，适用于后端服务器能够将 URL 的响应结果缓存的情况 |

这几个策略的适用场景区别还是比较明显的，根据我们的业务需要，挑选一个合适的即可。

### 详细设计阶段的陷阱：备选方案不可行

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行。一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

例如，曾经有一个项目，在备选方案阶段确定是可行的，但在详细方案设计阶段，发现由于细节点太多，方案非常庞大，整个项目可能要开发长达 1 年时间，最后只得废弃原来的备选方案，重新调整项目目标、计划和方案。

这种情况可以通过以下方式有效避免：

1. **架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解**。架构师选择了某个技术方案，前提必须是架构师自己对它的设计原理有深入的理解。

2. **通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度**。方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高。

3. **如果方案本身就很复杂，那就采取设计团队的方式来进行设计**。博采众长，汇集大家的智慧和经验，防止只有 1~2 个架构师可能出现的思维盲点或者经验盲区。

## 详细方案设计实战

让我们以"前浪微博"消息队列系统为例，来看一看备选方案 2 是如何被细化的。

### 细化设计点 1：数据库表如何设计？

数据库设计两类表：

- **日志表**（MQ_LOG）：用于消息写入时快速存储到 MySQL 中，包含字段：日志 ID、发布者信息、发布时间、队列名称、消息内容
- **消息表**（队列名称）：每个消息队列一张表，包含字段：消息 ID（递增生成）、消息内容、消息发布时间、消息发布者

业务系统发布消息时，首先写入到日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。业务系统读取消息时，从消息表中读取。

日志表需要及时清除已经写入消息表的日志数据，消息表最多保存 30 天的消息数据。

### 细化设计点 2：数据如何复制？

直接采用 MySQL 主从复制即可，只复制消息存储表，不复制日志表。

### 细化设计点 3：主备服务器如何倒换？

采用 ZooKeeper 来做主备决策，主备服务器都连接到 ZooKeeper 建立自己的节点：

- 主服务器的路径规则：`/MQ/server/分区编号/master`
- 备机的路径规则：`/MQ/server/分区编号/slave`
- 节点类型为 EPHEMERAL

备机监听主机的节点消息，当发现主服务器节点断连后，备服务器修改自己的状态，对外提供消息读取服务。

### 细化设计点 4：业务服务器如何写入消息？

消息队列系统设计两个角色：生产者和消费者，每个角色都有唯一的名称。

消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，SDK 采取轮询算法发起消息写入请求给主服务器。如果某个主服务器无响应或者返回错误，SDK 将发起请求发送到下一台服务器。

### 细化设计点 5：业务服务器如何读取消息？

SDK 从配置中读取所有消息队列系统的服务器信息，轮流向所有服务器发起消息读取请求。消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪条消息，当收到消息读取请求时，返回下一条未被读取的消息给消费者。

### 细化设计点 6：业务服务器和消息队列服务器之间的通信协议如何设计？

考虑到消息队列系统后续可能会对接多种不同编程语言编写的系统，为了提升兼容性，传输协议用 TCP，数据格式为 ProtocolBuffer。

## 总结

- 详细方案设计是将备选方案细化为可落地设计方案的关键阶段
- 详细设计阶段关注的是技术细节的确定，而非再次进行方案选型
- Nginx 等技术的负载均衡策略选择是轻量级的，根据适用场景选择即可
- 详细设计阶段可能发现备选方案不可行，需要有应对策略
- 架构师需要对关键技术有深入理解，不能只知其然而不知其所以然
- 分步骤、分阶段、分系统等方式可以降低方案复杂度
- 复杂方案需要设计团队来完成，博采众长
- 数据库表设计需要区分日志表和消息表
- ZooKeeper 是实现主备切换的常用方案
- SDK 封装可以简化业务系统与消息队列的交互
- 通信协议设计需要考虑多语言兼容性和性能

## 参考资料

- 软件架构基础

架构12：详细方案设计

## 前言

设计备选方案是架构设计中最具创造性的阶段，它考验的是架构师的想象力与技术积淀。然而，创造力只是起点，真正的挑战在于抉择。当我们手握三到五个各具特色的备选方案时，如何拨开迷雾，选择那条最适合当前业务发展的道路？这不是一道简单的算术题，而是一场关于权衡与取舍的艺术之旅。

为何评估和选择备选方案如此困难？因为每个方案都是可行的——如果不可行就根本不应该作为备选方案；没有哪个方案是完美的，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险；评价标准的主观性较强，容易陷入无谓的争论。

## 评估和选择备选方案

### 那些看似正确实则谬误的指导思想

**最简派**：设计师挑选一个看起来最简单的方案。例如，做全文搜索功能，MySQL 的查询功能比较简单，而 Elasticsearch 的倒排索引设计要复杂得多，所以干脆就挑选 MySQL 来做吧。这种做法忽略了长期的技术债务和未来的扩展需求。

**最牛派**：设计师会倾向于挑选技术上看起来最牛的方案。性能最高的、可用性最好的、功能最强大的，或者淘宝用的、微信开源的、Google 出品的。这种做法可能导致"杀鸡用牛刀"的浪费，或者引入团队无法驾驭的复杂技术。

**最熟派**：设计师基于自己的过往经验，挑选自己最熟悉的方案。这种做法虽然降低了风险，但也可能错失更优的解决方案。

**领导派**：列出备选方案后让领导来定夺。这种做法虽然规避了决策风险，但也失去了架构师应有的专业判断。

### 360 度环评法：正确打开方式

真正应该选择哪种方法来评估和选择备选方案？答案就是"**360 度环评**"！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点有：

- **性能**：系统处理请求的速度和能力
- **可用性**：系统持续提供服务的能力
- **硬件成本**：服务器、网络等基础设施投入
- **项目投入**：人力、时间、研发成本
- **复杂度**：方案的技术复杂程度和运维难度
- **安全性**：数据安全、访问控制等
- **可扩展性**：适应未来业务增长的能力

在评估这些质量属性时，需要遵循架构设计原则中的"合适原则"和"简单原则"，避免贪大求全。某个质量属性能够满足一定时期内业务发展就可以了。

例如，如果我们做一个购物网站，现在的 TPS 是 1000，如果我们预期 1 年内能够发展到 TPS 2000，在评估方案的性能时，只要能超过 2000 的都是合适的方案，而不是说淘宝的网站 TPS 是每秒 10 万，我们的购物网站就要按照淘宝的标准也实现 TPS 10 万。

### 按优先级选择：核心决策方法

完成方案的 360 度环评后，我们可以基于评估结果整理出环评表，一目了然地看到各个方案的优劣点。但 360 度环评表也只能帮助我们分析各个备选方案，还是没有告诉我们具体选哪个方案。

面临选择上的困难，有几种看似正确但实际错误的做法：

**数量对比法**：简单地看哪个方案的优点多就选哪个。这种方案主要的问题在于把所有质量属性的重要性等同，而没有考虑质量属性的优先级。

**加权法**：每个质量属性给一个权重，然后将每个方案的权重得分加起来。这种方案主要的问题是无法客观地给出每个质量属性的权重得分。

正确的做法是**按优先级选择**：架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。

### 评估和选择备选方案实战

回到"前浪微博"的场景。针对上期提出的 3 个备选方案，架构师组织了备选方案评审会议。

**备选方案 1：采用开源 Kafka 方案**

- 业务主管：倾向于采用 Kafka 方案，因为 Kafka 已经比较成熟
- 研发人员：部分支持使用 Kafka 能节省大量的开发投入；但部分人员认为 Kafka 可能并不适合我们的业务场景，因为 Kafka 的设计目的是为了支撑大容量的日志消息传输
- 运维代表：强烈反对！运维团队没有维护 Scala 语言开发的系统的经验，而且使用 Kafka 无法融入现有的运维体系
- 测试代表：倾向于引入 Kafka，因为 Kafka 比较成熟，无须太多测试投入

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

- 研发人员：认为这个方案比较简单，但部分研发人员对于这个方案的性能持怀疑态度
- 运维代表：赞同这个方案，因为可以融入到现有的运维体系中，可靠性有保障；但认为这个方案的成本比较高
- 测试代表：认为这个方案测试人力投入较大
- 业务主管：既不肯定也不否定

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

- 研发人员：部分认为这是一个很好的方案，能够展现技术实力；另外的研发人员认为这个方案复杂度太高
- 运维代表：不太赞成这个方案，因为运维之前遇到过类似存储系统故障导致数据丢失的问题
- 测试代表：赞同运维代表的意见，并且自研存储系统的测试难度也很高
- 业务主管：持保留意见

架构师经过思考后，给出了最终选择备选方案 2，原因有：

- **排除备选方案 1** 的主要原因是可运维性，因为再成熟的系统，上线后都可能出问题，如果出问题无法快速解决，则无法满足业务的需求；并且 Kafka 的主要设计目标是高性能日志传输，而我们的消息队列设计的主要目标是业务消息的可靠传输
- **排除备选方案 3** 的主要原因是复杂度，目前团队技术实力和人员规模无法支撑自研存储系统
- **备选方案 2** 的优点就是复杂度不高，也可以很好地融入现有运维体系，可靠性也有保障

针对备选方案 2 的缺点，架构师解释是：

- 性能方面，业务目前需要的性能并不是非常高，方案 2 能够满足，即使后面性能需求增加，方案 2 的数据分组方案也能够平行扩展进行支撑
- 成本方面，一个分组就需要 4 台机器，但实际上备机可以和其他系统并行部署在同一台机器上
- 技术上看起来并不很优越，但我们的设计目的不是为了证明自己，而是更快更好地满足业务需求

## 总结

- 360 度环评法是评估备选方案的有效方法，从多个质量属性维度综合评估
- 避免"最简派"、"最牛派"、"最熟派"、"领导派"等简单粗暴的决策方式
- 按优先级选择是核心决策方法，综合考虑业务、团队、技术等因素
- 方案选择和很多因素相关，并不单单考虑性能高低、技术是否优越
- 合适原则和简单原则是架构设计的重要指导原则
- 备选方案的选择需要充分讨论，综合考虑各方意见
- 架构设计的目标是更快更好地满足业务需求，而非证明技术实力
- 即使是同一个问题，不同的团队可能会做出不同的选择
- 评估过程中要充分听取研发、运维、测试、业务等各方意见
- 方案选择后需要对缺点进行合理解释和应对

## 参考资料

- 软件架构基础

架构11：评估备选方案

## 前言

当系统架构师完成了复杂度的识别，这意味着我们已经拨开了笼罩在系统之上的迷雾，明确了真正的挑战所在。然而，这仅仅是架构长征的起点——真正的考验才刚刚开始。

为何需要设计备选方案？因为架构设计从来不是一道只有一个标准答案的数学题。成熟的架构师需要对现有的技术版图了然于胸，对已经过无数场景验证的架构模式烂熟于心，然后根据对业务的深邃理解，挑选合适的架构模式进行精妙的组合，再对组合后的方案进行恰到好处的调整。这正是架构设计艺术性的体现——它既是科学，也是哲学，更是一种创造性的实践。

## 设计备选方案

### 组合创新的力量

软件技术历经数十年的飞速发展，新技术如雨后春笋般层出不穷。但经过时间大浪淘沙般的考验，已经被各种场景验证过的成熟技术其实更多。例如：

- **高可用领域**：主备方案、集群方案
- **高性能领域**：负载均衡、多路复用
- **可扩展领域**：分层架构、插件化技术

绝大部分时候，我们有了明确的目标后，按图索骥就能够找到可选的解决方案。只有当这种方式完全无法满足需求的时候，才会考虑进行方案的创新。而事实上，方案的创新绝大部分情况下也都是基于已有的成熟技术。

《技术的本质》一书对技术的组合有深刻的阐述：新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术。将技术进行功能性分组，可以大大简化设计过程，这是技术"模块化"的首要原因。技术的"组合"和"递归"特征，将彻底改变我们对技术本质的认识。

### 三种常见的架构设计误区

虽说基于已有的技术或者架构模式进行组合调整，大部分情况下就能够得到我们需要的方案，但这并不意味着架构设计是一件很简单的事情。因为可选的模式有很多，组合的方案更多。因此，如何设计最终的方案，并不是一件容易的事情，这个阶段也是很多架构师容易犯错的地方。

**第一种错误：设计最优秀的方案**

很多架构师在设计架构方案时，心里会默认有一种技术情结：我要设计一个优秀的架构，才能体现我的技术能力！例如，高可用的方案中，集群方案明显比主备方案要优秀和强大；高性能的方案中，淘宝的 XX 方案是业界领先的方案……

根据架构设计原则中"合适原则"和"简单原则"的要求，挑选合适自己业务、团队、技术能力的方案才是好方案；否则要么浪费大量资源开发了无用的系统，要么根本无法实现。

**第二种错误：只做一个方案**

很多架构师在做方案设计时，可能心里会简单地对几个方案进行初步的设想，再简单地判断哪个最好，然后就基于这个判断开始进行详细的架构设计了。

这样做有很多弊端：

- 心里评估过于简单，可能没有想得全面，只是因为某一个缺点就把某个方案给否决了，而实际上没有哪个方案是完美的
- 架构师再怎么牛，经验知识和技能也有局限，有可能某个评估的标准或者经验是不正确的
- 单一方案设计会出现过度辩护的情况，即架构评审时，架构师会竭尽全力去为自己的设计进行辩护

**第三种错误：备选方案过于详细**

有的架构师在写备选方案时，错误地将备选方案等同于最终的方案，每个备选方案都写得很细。这样做的弊端显而易见：

- 耗费了大量的时间和精力
- 将注意力集中到细节中，忽略了整体的技术设计
- 评审的时候其他人会被很多细节给绕进去，评审效果很差

正确的做法是备选阶段关注的是技术选型，而不是技术细节。

### 备选方案设计的黄金法则

架构师需要设计多个备选方案，但方案的数量可以说是无穷无尽的，架构师也不可能穷举所有方案。合理的做法应该遵循以下原则：

**数量法则**：备选方案的数量以 3 ~ 5 个为最佳。少于 3 个方案可能是因为思维狭隘，考虑不周全；多于 5 个则需要耗费大量的精力和时间，并且方案之间的差别可能不明显。

**差异法则**：备选方案的差异要比较明显。例如，主备方案和集群方案差异就很明显，或者同样是主备方案，用 ZooKeeper 做主备决策和用 Keepalived 做主备决策的差异也很明显。但是都用 ZooKeeper 做主备决策，一个检测周期是 1 分钟，一个检测周期是 5 分钟，这就不是架构上的差异，而是细节上的差异了。

**视野法则**：备选方案的技术不要只局限于已经熟悉的技术。很多架构师积累了一些成功的经验，出于快速完成任务和降低风险的目的，可能自觉或者不自觉地倾向于使用自己已经熟悉的技术，对于新的技术有一种不放心的感觉。就像那句俗语说的："如果你手里有一把锤子，所有的问题在你看来都是钉子"。

## 设计备选方案实战

让我们回到"前浪微博"的场景。通过"排查法"识别了消息队列的复杂性主要体现在：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。接下来进行第 2 步，设计备选方案。

**备选方案 1：采用开源的 Kafka**

Kafka 是成熟的开源消息队列方案，功能强大，性能非常高，而且已经比较成熟，很多大公司都在使用。

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

考虑到团队的开发语言是 Java，架构师选择基于 Netty 开发消息队列系统。由于系统设计的 QPS 是 13800，单台服务器支撑这么高的 QPS 还是有很大风险的，因此架构师选择采取集群方式来满足高性能消息读取。

对于"高可用存储"和"高可用读取"，架构师想到利用 MySQL 的主备复制功能来达到目的。具体方案：

- 采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据
- 每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步
- 正常情况下，分组内的主服务器对外提供消息写入和消息读取服务
- 客户端采取轮询的策略写入和读取消息

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

在备选方案 2 的基础上，将 MySQL 存储替换为自研实现存储方案，因为 MySQL 的关系型数据库的特点并不是很契合消息队列的数据特点，参考 Kafka 的做法，可以自己实现一套文件存储和复制方案。

可以看出，高性能消息读取单机系统设计这部分时并没有多个备选方案可选，备选方案 2 和备选方案 3 都采取基于 Netty 的网络库，用 Java 语言开发，原因就在于团队的 Java 背景约束了备选的范围。

## 总结

- 架构设计备选方案的核心是基于已有成熟技术的组合与调整，而非凭空创造
- 设计最优秀的方案是常见误区，应遵循"合适原则"和"简单原则"
- 备选方案数量以 3~5 个为最佳，过少思维狭隘，过多精力分散
- 备选方案之间的差异要明显，技术选型是关键，细节不是
- 不要局限于熟悉的技术，保持开放的技术视野
- 备选阶段关注技术选型，而非技术细节
- 架构师需要对关键技术有深入理解，不能成为"PPT 架构师"
- 设计备选方案需要结合业务、团队、技术能力等多方面因素
- 备选方案设计是架构设计中最具创造性的环节之一

## 参考资料

- 软件架构基础

架构10：设计备选方案

## 前言

架构设计的第一步是什么？是画架构图？是选技术栈？还是写设计文档？都不是。架构设计的第一步是识别复杂度——只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向。如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多、越离谱。

## 识别复杂度的重要性

架构设计的本质目的是为了解决软件系统的复杂性。在我们设计架构时，首先就要分析系统的复杂性。只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向。

例如，如果一个系统的复杂度本来是业务逻辑太复杂、功能耦合严重，架构师却设计了一个 TPS 达到 50000/秒的高性能架构，即使这个架构最终的性能再优秀也没有任何意义，因为架构没有解决正确的复杂性问题。

架构的复杂度主要来源于"高性能""高可用""可扩展"等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候架构都必须同时满足这三方面的要求。实际上**大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误**。

## 复杂度识别的常见问题

专栏前面提到过的"亿级用户平台"失败的案例很能说明问题。设计对标腾讯的 QQ，按照腾讯 QQ 的用户量级和功能复杂度进行设计，高性能、高可用、可扩展、安全等技术一应俱全，一开始就设计出了 40 多个子系统，然后投入大量人力开发了将近 1 年时间才跌跌撞撞地正式上线。

上线后发现之前的过度设计完全是多此一举，而且带来很多问题：

- 系统复杂无比，运维效率低下，每次业务版本升级都需要十几个子系统同步升级，操作步骤复杂，容易出错，出错后回滚还可能带来二次问题
- 每次版本开发和升级都需要十几个子系统配合，开发效率低下
- 子系统数量太多，关系复杂，小问题不断，而且出问题后定位困难
- 开始设计的号称 TPS 50000/秒的系统，实际 TPS 连 500 都不到

由于业务没有发展，最初的设计人员陆续离开，后来接手的团队无奈又花了 2 年时间将系统重构，合并成不到 20 个子系统，整个系统才逐步稳定下来。

这个案例的教训是：如果一开始没有正确识别复杂度，就会导致过度设计，而过度设计带来的复杂性反而会成为系统的负担。

## 正确的做法：逐个解决

对于按照复杂度优先级解决的方式，存在一个普遍的担忧：如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。

这个担忧理论上是可能的，但现实中几乎是不可能出现的，原因在于软件系统的可塑性和易变性。对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

即使架构师决定要推倒重来，这个新的方案也必须能够同时解决已经被解决的复杂度问题，一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。例如，Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。

正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，**优先解决当前面临的最主要的复杂度问题**，不要幻想一次架构重构解决所有问题。

## 识别复杂度实战：前浪微博消息队列

我们假想一个创业公司，名称叫"前浪微博"。前浪微博的业务发展很快，系统也越来越多，系统间协作的效率很低：

- 用户发一条微博后，微博子系统需要通知审核子系统进行审核，然后通知统计子系统进行统计，再通知广告子系统进行广告预测，接着通知消息子系统进行消息推送……一条微博有十几个通知，目前都是系统间通过接口调用的
- 用户等级达到 VIP 后，等级子系统要通知福利子系统进行奖品发放，要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理……

新来的架构师在梳理这些问题时，结合自己的经验，敏锐地发现了这些问题背后的根源在于架构上各业务子系统强耦合，而消息队列系统正好可以完成子系统的解耦。

### 背景信息

- 中间件团队规模不大，大约 6 人左右
- 中间件团队熟悉 Java 语言，但有一个新同事 C/C++ 很牛
- 开发平台是 Linux，数据库是 MySQL
- 目前整个业务系统是单机房部署，没有双机房

### 使用排查法识别复杂度

**第一步：排查是否需要高性能**

假设前浪微博系统用户每天发送 1000 万条微博，那么微博子系统一天会产生 1000 万条消息。假设平均一条消息有 10 个子系统读取，那么其他子系统读取的消息大约是 1 亿次。

1000 万和 1 亿看起来很吓人，但对于架构师来说，关注的不是一天的数据，而是 1 秒的数据，即 TPS 和 QPS。一天内平均每秒写入消息数为 115 条，每秒读取的消息数是 1150 条；再考虑系统的读写并不是完全平均的，设计的目标应该以峰值来计算。峰值一般取平均值的 3 倍，那么消息队列系统的 TPS 是 345，QPS 是 3450。

虽然根据当前业务规模计算的性能要求并不高，但业务会增长，因此系统设计需要考虑一定的性能余量。由于现在的基数较低，为了预留一定的系统容量应对后续业务的发展，我们将设计目标设定为峰值的 4 倍，因此最终的性能要求是：**TPS 为 1380，QPS 为 13800**。

TPS 为 1380 并不高，但 QPS 为 13800 已经比较高了，因此高性能读取是复杂度之一。

**第二步：排查是否需要高可用性**

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

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

**第三步：排查是否需要高可扩展性**

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

### 排查法复杂度识别函数

以下 Python 实现了一个通用的排查法复杂度识别函数：

```python
def analyze_complexity(system_name, features, peak_factor=3, design_factor=4):
    """
    使用排查法识别系统复杂度

    参数:
        system_name: 系统名称
        features: 功能列表，每个功能包含 (名称, 每日量, 读取倍数)
        peak_factor: 峰值倍数（默认3倍）
        design_factor: 设计余量倍数（默认4倍）
    """
    print(f"=== {system_name} 复杂度分析 ===")
    print("=" * 60)

    complexities = []
    total_daily_writes = sum(f[1] for f in features)

    # 计算平均 TPS/QPS
    avg_tps = total_daily_writes / (24 * 60 * 60)
    peak_tps = avg_tps * peak_factor
    design_tps = peak_tps * design_factor

    print(f"\n【步骤1: 排查高性能需求】")
    print(f"每日总写入: {total_daily_writes:,} 条")
    print(f"平均 TPS: {avg_tps:.1f}")
    print(f"峰值 TPS (×{peak_factor}): {peak_tps:.1f}")
    print(f"设计目标 TPS (×{design_factor}): {design_tps:.0f}")

    # 判断高性能复杂度
    if design_tps > 10000:
        complexities.append(("高性能写入", "高", f"TPS {design_tps:.0f} > 10000"))
        print(f"✓ 高性能写入是复杂度: TPS {design_tps:.0f} 较高")
    else:
        complexities.append(("高性能写入", "低", f"TPS {design_tps:.0f} 不高"))
        print(f"△ 高性能写入要求不高: TPS {design_tps:.0f}")

    # 计算总读取量
    total_daily_reads = sum(f[1] * f[2] for f in features)
    avg_qps = total_daily_reads / (24 * 60 * 60)
    peak_qps = avg_qps * peak_factor
    design_qps = peak_qps * design_factor

    print(f"\n每日总读取: {total_daily_reads:,} 次")
    print(f"平均 QPS: {avg_qps:.1f}")
    print(f"峰值 QPS (×{peak_factor}): {peak_qps:.1f}")
    print(f"设计目标 QPS (×{design_factor}): {design_qps:.0f}")

    # 判断高性能读取复杂度
    if design_qps > 10000:
        complexities.append(("高性能读取", "高", f"QPS {design_qps:.0f} > 10000"))
        print(f"✓ 高性能读取是复杂度: QPS {design_qps:.0f} 较高")
    else:
        complexities.append(("高性能读取", "低", f"QPS {design_qps:.0f} 不高"))
        print(f"△ 高性能读取要求不高: QPS {design_qps:.0f}")

    print(f"\n【步骤2: 排查高可用需求】")
    for name, daily_writes, read_multiplier in features:
        if "审核" in name or "支付" in name or "订单" in name:
            complexities.append(("高可用写入", "高", f"{name} 消息丢失不可接受"))
            print(f"✓ 高可用写入是复杂度: {name} 消息丢失不可接受")
            break
    else:
        print("△ 高可用写入要求一般")

    complexities.append(("高可用存储", "高", "消息存储不能丢失"))
    print(f"✓ 高可用存储是复杂度: 消息存储不能丢失")

    print(f"\n【步骤3: 排查可扩展性需求】")
    print("△ 可扩展性要求不高: 功能明确，无特殊扩展需求")

    # 按优先级排序
    print(f"\n【复杂度排序结果】")
    print("=" * 60)
    # 高复杂度排在前面
    complexity_order = []
    for name, level, reason in complexities:
        if level == "高":
            complexity_order.append((name, reason))

    for i, (name, reason) in enumerate(complexity_order, 1):
        print(f"{i}. {name}: {reason}")

    return complexity_order


# 前浪微博消息队列案例
features = [
    ("微博发布", 10_000_000, 10),  # 每日1000万条，10个子系统读取
    ("等级变化", 500_000, 5),      # 每日50万条，5个子系统读取
]

result = analyze_complexity("前浪微博消息队列系统", features)
```

**输出示例：**
```
=== 前浪微博消息队列系统 复杂度分析 ===
============================================================

【步骤1: 排查高性能需求】
每日总写入: 10,500,000 条
平均 TPS: 121.5
峰值 TPS (×3): 364.5
设计目标 TPS (×4): 1458

✓ 高性能写入是复杂度: TPS 1458 较高

每日总读取: 107,500,000 次
平均 QPS: 1244.2
峰值 QPS (×3): 3732.7
设计目标 QPS (×4): 14931

✓ 高性能读取是复杂度: QPS 14931 较高

【步骤2: 排查高可用需求】
✓ 高可用写入是复杂度: 微博发布 消息丢失不可接受
✓ 高可用存储是复杂度: 消息存储不能丢失

【步骤3: 排查可扩展性需求】
△ 可扩展性要求不高: 功能明确，无特殊扩展需求

【复杂度排序结果】
============================================================
1. 高性能读取: QPS 14931 较高
2. 高可用写入: 微博发布 消息丢失不可接受
3. 高可用存储: 消息存储不能丢失
```

这个示例展示了如何系统地使用排查法识别复杂度，最终确定前浪微博消息队列系统的复杂性主要体现在四个方面：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。

## 总结

- 架构设计第1步是识别复杂度，只有正确分析复杂度，后续方案才不会偏离方向；如果对复杂性判断错误，方案越完美越离谱
- 复杂度可能只有一个，也可能是两个，极少三个以上；如果同时需要解决三个以上的复杂度，要么说明系统之前设计有问题，要么架构师判断失误
- "亿级用户平台"过度设计教训：40+子系统→TPS 500都不到→重构为20个子系统；根源是一开始没有正确识别复杂度
- 正确的做法是将主要的复杂度问题列出来，按优先级排序，一个一个解决，不要幻想一次解决所有问题
- 软件系统的可塑性和易变性使得推倒重来几乎不可能发生，因为总有性价比更高的方案可以选择
- 前浪微博消息队列案例使用排查法分析：TPS=1380（不高），QPS=13800（较高），高可用（消息丢失不可接受）
- 复杂度排序结果：高性能读取 > 高可用写入 > 高可用存储 > 高可用读取
- 设计目标不一定要固定为峰值的4倍，不同业务可以是2倍或8倍，但一般不要设定在10倍以上，更不要一上来就按照100倍预估
- 新技术引入可以同时解决多个复杂度问题（如Hadoop解决高可用、高性能、大容量），但这是可遇不可求的
- 识别复杂度对架构师来说是一项挑战，有经验的架构师一看需求就知道复杂度大概在哪里，如果经验不足，只能采取排查法从不同角度逐一分析

## 参考

- 软件架构基础


架构9：设计流程：识别复杂度

## 前言

为什么有的架构师设计方案精美却最终失败？为什么技术最强的团队反而做不出最好的系统？答案藏在架构设计的三大原则之中：合适、简单、演化。这三个原则不是空洞的理论，而是大量成功与失败案例的总结。理解它们，才能真正做出好的架构设计。

## 架构设计的不确定性

编程的结果是确定的——同样的代码，无论谁写、何时执行，结果都应该一致。但架构设计截然不同：同样的系统，A 公司和 B 公司做出来的架构可能差异很大；同样的方案，A 设计师认为该这样做，B 设计师认为该那样做，看起来都有道理。架构设计没有像编程语言那样的语法约束，更多时候是面对多种可能性进行选择。

这种不确定性让架构师常常陷入两难：选最先进的技术还是团队最熟悉的技术？选 Angular 还是 React？选 MySQL 还是 MongoDB？淘宝的电商架构很完善，新做一个电商网站，是否照搬淘宝就可以了？这些困惑的背后，是因为架构设计领域并没有一套通用规范来指导架构师进行选择。

但通过研究架构设计的发展历史、多个公司的架构演进过程（QQ、淘宝、Facebook 等），我发现有几个共性原则隐含其中：**合适原则、简单原则、演化原则**。

## 原则一：合适原则

**合适原则宣言："合适优于业界领先"。**

优秀的技术人员都有很强的技术情结，做方案或架构时总想达到甚至优于业界领先水平——这样才显得优秀，才能在 KPI 总结里骄傲地写上"设计了 XX 方案，达到了和 Google 相同的技术水平"。但现实是，大部分这样想和这样做的架构，最后都以失败告终。

### 三个失败原因

**1. 将军难打无兵之仗**

大公司分工细，一个小系统可能就是一个小组负责。比如某个通信大厂做一个 OM 管理系统就有十几个人，阿里的中间件团队有几十个人。而大部分公司整个研发团队可能就 100 多人，某个业务团队可能就十几个人。十几个人的团队，想做几十个人的团队的事情，难度可想而知。没那么多人，却想干那么多活，是失败的第一个主要原因。

**2. 罗马不是一天建成的**

业界领先的方案并不是一堆天才某个时期灵机一动、加班加点就做出来的，而是经过几年时间的发展才逐步完善和初具规模的。阿里中间件团队 2008 年成立，发展到现在已经十几年了。我们只知道他们抗住了多少次"双 11"，做了多少优秀的系统，但经历了什么样的挑战、踩了什么样的坑，只有他们自己知道。没有那么多积累，却想一步登天，是失败的第二个主要原因。

**3. 冰山下面才是关键**

业界领先的方案其实都是"逼"出来的。业务发展到一定阶段，量变导致质变，出现了新的问题，已有的方式不能应对，需要用新方案来解决，通过创新和尝试，才有了业界领先的方案。GFS 为何在 Google 诞生，而不是在 Microsoft 诞生？因为 Google 有那么庞大的数据，而不是因为 Google 的工程师比 Microsoft 的工程师更聪明。没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。这也是很多 BAT 出来的架构师到了小公司或者创业团队反而做不出成绩的原因——没有了大公司的平台、资源、积累，只是生搬硬套大公司的做法，失败的概率非常高。

## 原则二：简单原则

**简单原则宣言："简单优于复杂"。**

软件架构设计是一门技术活。从历史上看，无论是瑞士的钟表、瓦特的蒸汽机、莱特兄弟发明的飞机，还是摩托罗拉发明的手机，无一不是越来越精细、越来越复杂。因此当我们进行架构设计时，会自然而然地想把架构做精美、做复杂，这样才能体现技术实力，也才能够将架构做成一件艺术品。

由于软件架构和建筑架构表面上的相似性，我们也会潜意识地将对建筑的审美观点移植到软件架构上。我们惊叹于长城的宏伟、泰姬陵的精美、悉尼歌剧院的艺术感、迪拜帆船酒店的豪华感，因此对于我们自己亲手打造的软件架构，我们也希望它宏伟、精美、艺术、豪华。

团队的压力也会促进我们走向复杂的方向，因为大部分人在评价一个方案水平高低时，复杂性是其中一个重要参考指标。例如设计一个主备方案，如果你用心跳来实现，可能大家都认为这太简单了。但如果你引入 ZooKeeper 来做主备决策，可能很多人会认为这个方案更加"高大上"。真正理解 ZAB 协议的人很少，但并不妨碍我们都知道 ZAB 协议很优秀。

这些原因会促使初出茅庐的架构师不自觉地追求架构的复杂性。然而，"复杂"在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，**复杂代表的是问题**。

### 结构复杂性

结构复杂的系统几乎毫无例外具备两个特点：组成复杂系统的组件数量更多，同时这些组件之间的关系也更加复杂。

以组件故障率为例，假设组件的故障率是 10%（有 10% 的时间不可用），那么有 3 个组件的系统可用性是 (1-10%) × (1-10%) × (1-10%) = 72.9%，有 5 个组件的系统可用性是 (1-10%) × (1-10%) × (1-10%) × (1-10%) × (1-10%) = 59%。两者可用性相差 13%。

结构复杂性还存在其他问题：某个组件改动会影响关联的所有组件，这些被影响组件会递归影响更多组件；定位问题比简单系统更加困难，因为组件多，每个组件都有嫌疑，而组件间关系复杂，表现故障的组件可能并不是真正问题的根源。

### 逻辑复杂性

除了结构复杂性，还有逻辑复杂性。如果某个组件的逻辑太复杂，一样会带来各种问题。逻辑复杂的组件，典型特征就是单个组件承担了太多的功能。以电商业务为例，常见的功能有：商品管理、商品搜索、商品展示、订单管理、用户管理、支付、发货、客服……把这些功能全部在一个组件中实现，就是典型的逻辑复杂性。

逻辑复杂几乎会导致软件工程每个环节都有问题：如果淘宝将这些功能全部在单一的组件中实现，系统会很庞大，可能是上百万、上千万的代码规模，"clone"一次代码要 30 分钟；几十、上百人维护这一套代码，某个"菜鸟"不小心改了一行代码，可能导致整站崩溃。

为什么复杂的电路意味着更强大的功能，而复杂的架构却有很多问题？根本原因在于电路设计好后进入生产就不会再变，复杂性只在设计时带来影响；而软件系统在投入使用后，后续还有源源不断的需求要实现，复杂性在整个系统生命周期中都有很大影响。

无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，**最好选择简单的方案**。《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则一样适用于架构设计。

## 原则三：演化原则

**演化原则宣言："演化优于一步到位"。**

软件架构从字面意思理解和建筑结构非常类似，维基百科对"软件架构"的定义中有一段话描述了这种相似性：从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。然而，字面意思上的相似性却掩盖了一个本质上的差异：建筑一旦完成（甚至一旦开建）就不可再变，而软件却需要根据业务的发展不断地变化。

古埃及的吉萨大金字塔，4000 多年前完成的，到现在还是当初的架构。中国的明长城，600 多年前完成的，现在保存下来的长城还是当年的结构。美国白宫，1800 年建成，200 年来进行了几次扩展，但整体结构并无变化。

对比一下 Windows 系统的发展历史：Windows 1.0（1985 年）和 Windows 8（2012 年），如果对比这两个系统的架构，会发现它们其实是两个不同的系统了。Android 的发展历史同样如此，Android 6.0 和 Android 1.6 的差异也很大。

对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。软件架构需要根据业务的发展而不断变化。设计 Windows 和 Android 的人都是顶尖的天才，即便如此，他们也不可能在 1985 年设计出 Windows 8，不可能在 2009 年设计出 Android 6.0。

如果没有把握"软件架构需要根据业务发展不断变化"这个本质，在做架构设计时就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。为了实现这样的目标，要么照搬业界大公司公开发表的方案，要么投入庞大的资源和时间来做预测和分析。无论哪种做法，后果都很明显：投入巨大，落地遥遥无期。

考虑到软件架构需要根据业务发展不断变化这个本质特点，软件架构设计其实更加类似于大自然"设计"一个生物，通过演化让生物适应环境，逐步变得更加强大：首先生物要适应当时的环境，其次生物需要不断地繁殖，将有利的基因传递下去，将不利的基因剔除或者修复。

## 可用性计算示例

以下 Python 示例展示了组件数量对系统可用性的影响：

```python
def calculate_availability(component_count, individual_availability=0.90):
    """计算系统整体可用性，假设每个组件可用性相同且独立"""
    return individual_availability ** component_count

# 示例：对比不同组件数量的系统可用性
print("组件故障率 10%，各组件独立")
print("=" * 40)

for n in [1, 2, 3, 5, 10]:
    avail = calculate_availability(n, 0.90)
    downtime = (1 - avail) * 365 * 24 * 60  # 年故障分钟数
    print(f"{n} 个组件: 可用性={avail:.2%}, 年故障约 {downtime:.0f} 分钟")

print()
print("对比: 单组件 99% vs 90% 可用性")
print("=" * 40)
for avail in [0.99, 0.90]:
    for n in [1, 3, 5]:
        result = calculate_availability(n, avail)
        print(f"单组件可用性 {avail:.0%}, {n} 个组件: 整体可用性={result:.4f}")
```

**输出示例：**
```
组件故障率 10%，各组件独立
========================================
1 个组件: 可用性=90.00%, 年故障约 52560 分钟
2 个组件: 可用性=81.00%, 年故障约 9878 分钟
3 个组件: 可用性=72.90%, 年故障约 14212 分钟
5 个组件: 可用性=59.00%, 年故障约 21504 分钟
10 个组件: 可用性=34.87%, 年故障约 32846 分钟

对比: 单组件 99% vs 90% 可用性
========================================
单组件可用性 99%, 3 个组件: 整体可用性=0.9703
单组件可用性 99%, 5 个组件: 整体可用性=0.9510
单组件可用性 90%, 3 个组件: 整体可用性=0.7290
单组件可用性 90%, 5 个组件: 整体可用性=0.5905
```

这个示例清楚说明了为什么简单原则强调组件数量越多系统可用性越低。在实际架构设计中，我们需要权衡功能拆分带来的独立性与可用性下降之间的矛盾。

## 总结

- 架构设计结果不确定，与编程的确定性形成鲜明对比，架构师需要学会在多种可能性中做出选择
- **合适原则**：优秀架构在企业当前人力、条件、业务约束下设计，能合理整合资源并快速落地，"将军难打无兵之仗、罗马不是一天建成、冰山下面才是关键"是三个主要失败原因
- **简单原则**：软件领域复杂代表问题而非先进，结构复杂性（组件越多故障率越高：3组件72.9% vs 5组件59%）和逻辑复杂性（单组件功能太多→上百万行代码）都会带来严重问题
- **演化原则**：建筑永恒而软件变化，Windows/Android 都经历了巨大演变，软件架构需跟随业务演化，无法一步到位
- 架构设计的本质目的是解决软件系统复杂度带来的问题，三大原则指导我们做出正确选择
- 不要试图一步到位设计完美架构，罗马不是一天建成的，架构需要在业务发展中逐步演进
- 合适原则优先考虑——先满足业务当前需求；简单原则次之——挑选简单方案快速落地；演化原则第三——适当预测业务发展
- 引入新技术或创造新技术是实现低成本的主要手段，但中小公司一般靠引入新技术，大公司才有可能自己创造新技术

## 参考

- 软件架构基础
- 《UNIX 编程艺术》，KISS 原则
- 淘宝技术发展历史
- QQ 亿级用户架构演进