为什么 AWS 不整合服务 - Two-Pizza Team 与服务分离的设计哲学
从 Bezos 的 API Mandate、Two-Pizza Team 组织原则和 Conway 定律的角度，解析 AWS 持续独立提供 200 多项服务的原因，并探讨服务分离带来的优势与代价。
为什么有这么多相似的服务
每个开始使用 AWS 的人都会产生这样的疑问：SQS 和 Kinesis 都处理消息，为什么要有两个？ECS 和 EKS 都运行容器，为什么不整合？CodeCommit、CodeBuild、CodeDeploy、CodePipeline 为什么不合并成一个工具？2006 年仅以 S3 和 EC2 起步的 AWS，如今提供 200 多项服务。这庞大的服务群并非偶然的产物，而是 Amazon 组织结构和设计思想所产生的必然结果。要理解其根源，需要追溯到 2002 年 Jeff Bezos 向公司内部发出的一封备忘录。
Bezos 的 API Mandate - 一切从这里开始
2002 年，Amazon 的代码库已成长为巨大的单体应用，团队间的依赖关系成为扩展的瓶颈。Bezos 针对这一问题向所有团队发出了明确的指令：(1) 所有团队必须通过服务接口公开自己的数据和功能。(2) 团队间的所有通信必须通过该接口进行。(3) 绝不允许直接访问其他团队的数据存储。(4) 不遵守者将被解雇。这一指令后来被称为"Bezos API Mandate"。重要的是，该指令要求所有接口都以可对外公开的质量进行设计。不允许因为是内部使用就降低标准。这一原则后来促成了将 Amazon 内部工具作为外部服务推出的 AWS 的诞生。S3 的原型是 Amazon 的内部存储服务，EC2 的基础是公司内部的计算资源管理机制。
Two-Pizza Team 与 Conway 定律
Bezos 引入的另一个组织原则是 Two-Pizza Team。一个团队的规模应控制在两个披萨能让所有人吃饱的程度，即 6 到 10 人左右。这个小团队对一项服务的设计、开发和运维承担全部责任。这里发挥作用的是 Conway 定律。1967 年 Melvin Conway 提出的这一定律观察到，组织设计的系统会反映该组织的沟通结构。Amazon 反向利用了这一定律——先定义理想的架构（松耦合的服务群），再据此设计组织结构。由于每个 Two-Pizza Team 拥有独立的服务，服务数量与团队数量成正比增长。SQS 和 Kinesis 分别存在，是因为各自有独立的团队负责，解决不同的客户问题。SQS 专注于异步消息传递的可靠性，Kinesis 专注于实时流处理的吞吐量。整合看似方便，但一个团队同时优化两种需求是困难的。
服务分离带来的三大优势
第一，发布速度的独立性。每个团队可以独立部署自己的服务，不依赖其他团队的发布计划。AWS 每年能发布数千项功能改进，正是因为有这种独立性。第二，故障爆炸半径的局部化。一项服务发生故障时，可将对其他服务的影响降到最低。2017 年的 S3 故障影响了许多服务，但这反而成为 S3 依赖过于集中的教训，此后 AWS 进一步推进了服务间依赖关系的松耦合设计改进。第三，为客户提供选择的粒度。需要全托管容器执行环境选 Fargate，需要 Kubernetes 生态兼容性选 EKS，简单的 Docker 执行环境够用选 ECS。整合为单一服务后，很难提供这种粒度的选择。
分离的代价 - 学习成本与集成复杂性
服务分离也有明确的代价。最显著的是学习成本的增加。开始新项目时，仅理解相似服务的差异并选择合适的服务就需要相当多的时间。定价体系也因服务而异，使成本估算变得复杂。服务间的协作也会产生摩擦。从 Lambda 调用 DynamoDB、将结果发送到 SQS、再由另一个 Lambda 处理这样的架构中，需要分别设计各服务的 IAM 权限、错误处理和重试策略。AWS 自身也认识到这一问题，采取了事后提供集成视图的方式。Application Composer 是可视化设计无服务器架构的工具，减轻了组合各个服务的复杂性。Step Functions 可以声明式地描述服务间的编排。也就是说，服务本身保持分离，在上层覆盖集成层的策略。
对自身系统设计的启示
AWS 的服务分离思想也为自身的系统设计提供启示。决定微服务粒度时，应以"独立团队能否承担责任"而非"技术上能否分割"为标准。将团队边界与服务边界对齐，就能让 Conway 定律成为助力。另一方面，小型组织以与 AWS 相同的粒度分割服务则过度了。3 人团队运维 20 个微服务时，分离的优势会被运维成本所超越。选择与组织规模匹配的分割粒度很重要。觉得 AWS 服务太多是自然的反应，但其背后有着将组织结构与架构对齐的一贯设计哲学。理解这一结构后，相似服务的选择标准也会变得清晰——每项服务试图解决的具体问题是什么，自己的用例与哪个问题解决方案最匹配，从这个视角来选择即可。 如果您想深入学习云架构的设计思想，相关书籍（Amazon）也可供参考。
总结
AWS 持续独立提供 200 多项服务而不整合的原因，根植于 2002 年的 Bezos API Mandate 和 Two-Pizza Team 组织原则。正如 Conway 定律所示，组织结构决定架构，小型独立团队各自拥有服务的体制，产生了发布速度的独立性、故障的局部化和客户选择粒度等优势。虽然存在学习成本和集成复杂性的代价，但 AWS 采取了通过 Application Composer 和 Step Functions 等集成层来补充的策略。