#经典架构决策案例

架构决策的价值不在于「做对了什么」，而在于「为什么做」和「代价是什么」。通过分析真实的架构决策案例，我们可以学习决策者面临的约束、权衡的过程、最终的选择以及事后的复盘。

本章选取四个不同类型的架构决策案例：Netflix 的微服务拆分、Amazon 的 API 声明、某电商团队的数据库选型、某金融公司的消息队列选型。这些案例覆盖了从互联网巨头到中小型团队的不同场景，展示了架构决策的多样性和权衡思维的重要性。

#案例 1：Netflix 选择微服务架构（ADR-N001）

#背景

2009 年，Netflix 是一家提供 DVD 租赁服务的公司，正在经历快速扩张。当时 Netflix 的系统是一个典型的单体架构：所有功能都在一个大应用中，共享一个数据库。

这个架构在 DVD 时代工作得很好。但 Netflix 决定转型流媒体业务时，问题出现了：

• 流媒体业务需要更高的可用性：用户不能忍受视频卡顿
• 流媒体业务需要更好的扩展性：高峰期的流量是平峰期的 10 倍
• 流媒体业务需要更快的迭代速度：竞争对手 YouTube 每周都在发布新功能

当时 Netflix 的单体系统每次部署都需要整个团队参与，发布周期是季度级别。这意味着 Netflix 在与 YouTube 的竞争中处于劣势。

#决策

Netflix 在 2009 年做出了一个大胆的决定：开始从单体架构迁移到微服务架构。

但 Netflix 没有选择当时流行的 SOA（面向服务架构），而是选择了更激进的微服务方案：每个服务只负责一个业务功能，服务之间通过 API 通信，服务独立部署、独立扩展。

这个决策有几个关键点：

1. 服务边界：按照业务能力划分服务，每个服务对应一个独立的业务域
2. 通信协议：选择 REST over HTTP 作为服务间通信协议，而不是当时流行的 SOAP 或 ESB
3. 数据管理：每个服务拥有自己的数据库，服务间不允许跨库访问
4. 部署模式：所有服务部署在云端（AWS），而不是自建数据中心

#权衡分析

为什么选择微服务而不是 SOA？

SOA 和微服务的区别在于粒度：SOA 的服务通常较大，一个服务可能包含多个业务能力；微服务的服务粒度更细，一个服务只对应一个业务能力。

Netflix 选择微服务的原因是：

• 更细的粒度意味着更高的灵活性：一个服务可以快速迭代，不影响其他服务
• 更细的粒度意味着更好的隔离性：一个服务故障不会扩散到其他服务
• REST over HTTP 的简单性：不需要复杂的 ESB，降低了复杂度

但代价是：

• 分布式系统的复杂性：服务间通信、网络延迟、分布式事务都是新问题
• 运维复杂度倍增：需要服务发现、负载均衡、熔断限流等基础设施
• 数据一致性挑战：跨服务的数据一致性需要额外设计

为什么选择 AWS 而不是自建数据中心？

Netflix 选择 AWS 的原因是：当时 Netflix 没有数据中心运维能力，而 AWS 提供了弹性的基础设施。

但这个决策带来了另一个权衡：Netflix 变成了 AWS 的深度用户，后来成为了 AWS 最大的客户之一。这个决策在当时是合理的，但让 Netflix 承担了厂商锁定的风险。

#后果

Netflix 的微服务迁移从 2009 年开始，一直持续到 2016 年才基本完成。最终拆分成 800 多个微服务。

收益：

• 发布周期从季度级别提升到周级别，甚至每天多次发布
• 系统可用性从 99.9% 提升到 99.99%（四个 9）
• 成功支撑了从 DVD 到流媒体的转型

挑战：

• 2011 年圣诞期间，微服务故障导致服务中断 3 天，数百万用户受到影响
• 运维复杂度远超预期，需要大量投资在基础设施建设上
• 服务间调用链路复杂，故障排查困难

学到的东西：

Netflix 后来开源了微服务治理的工具，如 Eureka（服务发现）、Hystrix（熔断器）、Zuul（网关），这些工具后来成为 Spring Cloud 的核心组件。

这个案例告诉我们：微服务不是银弹。它带来的灵活性是有代价的，运维复杂度是最大的挑战。在选择微服务之前，需要确保团队有能力建设配套的基础设施。

#案例 2：Amazon 的「API 声明」

#背景

2002 年，Amazon 还是一家在线书店，但贝索斯（Jeff Bezos）看到了亚马逊成为「万货商店」的可能性。他开始思考：如何让亚马逊的技术架构支撑业务的快速扩张？

当时亚马逊的系统和很多公司一样，是单体架构。不同团队共享代码库，一个团队的功能变更可能影响另一个团队。这种耦合让发布变得困难，也让新功能的开发速度受限。

贝索斯意识到，如果亚马逊要成为平台型公司，需要让每个团队都能独立运作，不被其他团队拖累。

#决策

2002 年，贝索斯发布了著名的「API 声明」（Mandate），要求亚马逊内部的所有团队：

1. 所有团队必须通过 API 进行通信
2. 不允许通过共享数据库或其他方式直接访问其他团队的数据
3. 所有 API 必须设计得像面向外部客户的 API 一样严格

这个决策后来成为亚马逊「服务导向架构」的基础。

#权衡分析

「API 声明」的代价：

• 增加了开发复杂度：每个功能都需要封装成 API
• 增加了运维成本：需要维护大量的 API 服务
• 增加了系统延迟：跨团队调用变成了网络调用

「API 声明」的收益：

• 团队可以独立开发和部署：不再需要跨团队协调发布
• 系统更加健壮：一个团队的故障不会扩散到其他团队
• 数据更加安全：团队之间的数据访问有了明确的边界

「API 声明」与微服务的区别：

Amazon 的「API 声明」比特拉华州 Netflix 的微服务更早，也更严格。Amazon 不是从「我要做微服务」出发的，而是从「我要解决团队耦合问题」出发的。

这个决策为亚马逊后来推出 AWS 奠定了基础：AWS 的服务（如 S3、EC2）本质上是亚马逊内部 API 的外部化。当亚马逊把内部团队用的服务变成云服务时，发现这些服务对外部客户也有价值。

#后果

Amazon 的「API 声明」奠定了亚马逊成为平台型公司的技术基础。

直接收益：

• 团队可以独立扩展：每个服务可以根据自己团队的负载独立扩展
• 故障隔离：一个服务故障不会导致整个系统崩溃
• 业务灵活性：可以快速组建新团队，开发新功能

长期收益：

• AWS 的诞生：AWS 的服务本质上就是亚马逊内部服务的外部化
• 亚马逊成为「API 公司」：无论是电商、Kindle 还是 Alexa，都建立在统一的技术架构上

学到的东西：

Amazon 的案例告诉我们：架构决策往往源于业务需求，而不是技术理想。贝索斯做「API 声明」不是为了「用微服务」，而是为了「解决团队耦合问题」。

好的架构决策是业务驱动的，而不是技术驱动的。

#案例 3：某电商团队选择分区而非分库分表

#背景

2019 年，某中型电商团队的主订单表数据量达到了 1000 万行。当时团队面临一个常见问题：单表数据量太大，查询性能开始下降。

团队开始评估数据库扩展方案。主流方案有两种：

• 分库分表：将数据分散到多个数据库实例和表中，需要修改应用代码
• 分区（Partition）：在同一数据库实例内将数据分散到多个分区，对应用代码透明

#决策

团队选择了分区方案，而不是分库分表。

具体决策：

1. 选择 MySQL 原生分区（Range Partition），按月份分区
2. 保留原有单库架构，不做水平拆分
3. 定期归档历史分区，保留最近 24 个月的数据
4. 如果单分区数据量超过 500 万行，再评估分库分表

#权衡分析

为什么选择分区而不是分库分表？

团队选择的核心理由：

• 团队只有 3 个人，没有 DBA，分库分表的运维复杂度超出团队能力
• 当前数据量 1000 万行，预计 3 年内不会超过 5000 万行
• 分区方案的查询能力仍然很强，不需要跨库 join

接受的代价：

• 单库性能上限有限：预估单机 MySQL 可以支撑 5000 万行数据
• 如果业务超预期增长，可能需要再次迁移

#后果

正面结果：

• 实施成本低：只用了 2 周时间就完成了分区改造
• 查询性能恢复：分区后查询延迟从 500ms 恢复到 50ms
• 运维简单：不需要额外的运维工具和流程

潜在风险：

• 2022 年数据量达到 4000 万行，接近预估上限
• 团队扩张到 8 人，有了专职 DBA，开始评估分库分表方案

复盘结论：

分区方案在当时的决策是正确的。团队用最小的成本解决了性能问题，并且在这个过程中积累了数据库优化的经验。

但这个决策是有时限的。当业务增长超过预估时，团队需要重新评估。ADR 的价值在于记录了当时的决策依据，让后续的决策有据可查。

#案例 4：某金融公司选择 RabbitMQ 而非 Kafka

#背景

2020 年，某金融科技公司的交易系统需要引入消息队列来处理交易完成后的异步通知。当时每天的消息量约 10 万条，高峰期 QPS 约 100。

团队有 5 个人，技术栈是 Java + Spring Boot。团队评估了两个主流的消息队列：Kafka 和 RabbitMQ。

#决策

团队选择了 RabbitMQ，而不是 Kafka。

具体决策：

1. 选择 RabbitMQ 单机部署模式，使用默认配置
2. 使用 Spring AMQP 进行集成
3. 不引入额外的消息追踪系统，先用日志记录消息流转
4. 3 个月后复盘，如果性能不足再评估集群模式或迁移到 Kafka

#权衡分析

为什么选择 RabbitMQ 而不是 Kafka？

团队选择的核心理由：

• 业务规模匹配：每天 10 万条消息，RabbitMQ 绰绰有余
• 团队能力匹配：5 人小团队，运维简单更重要
• 功能需求匹配：需要延迟消息和死信队列，RabbitMQ 原生支持

接受的代价：

• Kafka 的吞吐量优势用不上：当前 10 万条/天的消息量，RabbitMQ 完全满足
• 如果未来需要处理日志、大数据场景，RabbitMQ 不合适

#后果

正面结果：

• 实施顺利：只用了 1 周就完成了 RabbitMQ 集成
• 运维简单：团队很快掌握了 RabbitMQ 的监控和运维
• 专注业务：没有在基础设施上花费太多精力

潜在风险：

• 2022 年业务增长，消息量达到 100 万条/天，RabbitMQ 出现瓶颈
• 团队开始评估 Kafka 迁移方案

学到的东西：

很多团队在技术选型时追求「最好的方案」，但忽略了「当前阶段是否需要」。

Kafka 确实是更好的消息队列，但它是为大规模场景设计的。在小规模场景下，Kafka 的优势无法发挥，反而带来了不必要的复杂度。

选择「够用」的方案，把精力放在业务上，是小团队的务实选择。

#四个案例的共同启示

四个案例看似不同，但都在回答同一个问题：我们愿意牺牲什么来换取什么？

这些案例告诉我们：

1. 架构决策必须匹配业务阶段和团队能力

Netflix 可以投入 10 年时间建设微服务基础设施，但小团队没有这个能力。选择架构不是选「最好的」，而是选「最适合当前阶段的」。

2. 架构决策必须记录权衡过程

4 个案例中，决策者都面临过「选简单方案还是复杂方案」的抉择。关键不是选哪个，而是为什么选。记录权衡过程，才能让后来者理解决策的上下文。

3. 架构决策是有时限的

每个决策都基于当时的假设。当假设不成立时，决策就需要重新评估。ADR 不是「写完就结束」，而是需要定期复盘。

4. 失败不可怕，可怕的是不知道为什么会失败

Netflix 在 2011 年经历了大规模故障，但这个故障让 Netflix 认识到微服务治理的重要性，后来才有了 Hystrix 等开源工具。ADR 记录了决策过程，让复盘有了依据。

#总结

架构决策是团队最重要的技术工作之一。好的决策需要清晰的思考、充分的讨论和完整的记录。

从这四个案例中，我们可以学到：

• 业务驱动：架构决策服务于业务目标，而不是技术理想
• 匹配性：方案必须匹配业务阶段和团队能力
• 权衡思维：每个选择都有代价，关键是找到当前阶段的最佳平衡点
• 记录价值：ADR 的价值不在于文档本身，而在于决策过程的可追溯性

架构决策没有标准答案。Netflix 的微服务在 Netflix 是正确的，但照搬到小团队可能是灾难。关键是理解决策背后的逻辑，而不是盲目模仿结果。