亚马逊CTO：单体架构并没过时

李鹏 分布式实验室 2023-05-06 16:45 发表于北京

构建可演进的软件系统是一种策略，而非信仰。必须以开放的心态重新审视你的架构。

软件架构与桥梁和房屋的架构有很大不同。在桥梁建成之后，改变其建造方式是困难的，甚至是不能改变的。但是，软件却截然不同。当我们运行软件时，我们可能会获得一些在设计时未曾预料到的关于工作负载的认识。如果我们在一开始就意识到这一点，并选择了一个可演进的架构，我们就可以在不影响客户体验的情况下更换组件。

我的经验法则是：每当业务增长一个数量级，就应该重新审视架构，以确定它是否仍能支持下一个数量级的增长。

一个很好的例子可以从 Prime Video 工程团队撰写的两篇颇有深度的博客中找到。第一篇文章阐述了周四晚间橄榄球比赛直播是如何以分布式工作流架构为基础构建的。第二篇则是一篇最近的文章，详细探讨了他们的流媒体监控工具的架构，以及他们的经验和分析如何促使他们将其设计成一个单体架构。

并不存在一种适用于所有情况的解决方案。我们总是鼓励我们的工程师寻找最佳解决方案，而不强求遵循特定的架构风格。如果你雇佣了最优秀的工程师，你应该相信他们有能力作出最佳决策。

我一直强烈建议开发者在构建系统时要考虑到它们随时间演进的需求，并确保所打下的基础能够在依赖最少的前提下进行修改和扩展。事件驱动架构（EDA）和微服务就是一个很好的选择。然而，如果有一组服务始终参与到响应中，具有相同的扩展和性能要求、相同的安全风险，并且最重要的是，由同一个团队管理，那么将它们合并以简化架构是非常值得尝试的。

从一开始，亚马逊就非常重视可演进架构。我们不断重新评估和改进我们的系统，以满足客户日益增长的需求。这种理念可以追溯到 1998 年，当时一群高级工程师撰写了《分布式计算宣言》，为亚马逊从单体架构转向面向服务的架构奠定了基础。在过去的几十年里，事物不断发展，我们转向微服务，然后是共享基础设施上的微服务，正如我在 re:Invent 大会上所讲的，EDA（事件驱动架构）也应运而生。

向解耦的自包含系统转变是一种自然的演进。微服务更小、更易于管理，它们可以使用符合业务需求的技术栈，部署时间更短，开发人员可以更快地投入工作，新组件可以在不影响整个系统的情况下进行部署。最重要的是，如果一个微服务在部署过程中出现故障，系统的其他部分仍可正常运行。当服务恢复上线时，它会回放错过的事件并执行。这就是我们所说的可演进架构。它可以随着时间的推移轻松地进行更改。你可以从一个小型项目开始，让它随着你的愿景逐渐增长复杂性。

S3 是一个很好的例子，展示了一项几乎扩大了 40 倍的服务。S3 在 2006 年推出时仅有几个微服务，现在已经发展到拥有超过 300 个微服务，引入了新的存储方式、策略机制和存储类别。这种发展得益于架构的可演进性，这在设计系统时是一个至关重要的考虑因素。

但是，我想再次强调，并没有一种架构模式可以适用于所有场景。你选择如何开发、部署和管理服务，始终取决于你所设计的产品、开发团队的技能和你希望为客户提供的体验（当然，还包括成本、速度和弹性等因素）。

例如，一个有五名工程师的初创公司可能会选择单体架构，因为它部署起来更简单，而且不需要他们的小团队学习多种编程语言。他们的需求与一个拥有数十个工程团队的大型企业有本质上的不同，后者每个团队都负责管理一个独立的子服务。这是完全可以理解的。重要的是为工作选择合适的工具。

几乎没有单向门（one-way door）。定期评估你的系统非常重要，甚至比最初构建它们时更加重要，因为你的系统将运行比设计它们所花费的时间更长。因此，单体架构并没有过时（相反，它们仍然非常重要），但是可演进的架构在不断变化的技术环境中扮演着越来越重要的角色，而这得益于云技术的出现。