亚马逊CTO：单体架构并不过时
原文：Monoliths are not dinosaurs（2023/05/05），译：单体架构并不过时
亚马逊CTO Werner Vogels 的 Blog：https://www.allthingsdistributed.com/
构建可演进的软件系统是一种策略，而非信仰。 必须以开放的心态重新审视你的架构。
单体并不过时
软件架构与桥梁和房屋的架构有很大不同。 在桥梁建成后，改变它的建造方式是非常困难的，甚至是无法改变的。软件是完全不同的，一旦我们运行我们的软件，我们可能会获得一些在设计时未曾预料到的关于工作负载的认识。 而且，如果我们在一开始就意识到这一点，并且选择了一个可演进的架构，我们就可以在不影响客户体验的情况下更换组件。 我的经验法则是，随着每个数量级的增长，就应该重新审视架构，以确定它是否仍能支持下一个数量级的增长。
一个很好的例子可以从 Prime Video 的工程团队撰写的两篇颇有深度的博客文章中找到。 第一篇文章阐述了周四晚上橄榄球比赛直播是如何以分布式工作流架构为基础构建的。 第二篇是最近的一篇文章，详细探讨了他们的流媒体监控工具的架构，以及他们的经验和分析如何促使他们将其设计成一个单体架构。并不存在一种适用于所有情况的解决方案。 我们总是鼓励我们的工程师寻找最佳解决方案，并不强制遵循特定的架构风格。 如果你雇佣了最优秀的工程师，你应该相信他们有能力作出最佳决策。
我一直强烈建议开发者在构建系统时考虑到它们的系统随时间的推移而演进的需求，并确保这样的基础，可以用最少的依赖项来改变和扩展它们。 事件驱动架构 (EDA) 和微服务非常适合这一点。 但是，如果有一组服务始终参于到响应中，具有相同的扩展和性能要求、相同的安全风险，并且最重要的是，由一个团队管理，那么将它们合并以简化架构是非常值得尝试的。
从一开始就，亚马逊就非常重视可演进架构。 我们不断重新评估和重新设计我们的系统，以满足客户不断增长的需求。 这种理念可以一直追溯到 1998 年，当时一群高级工程师起草了《分布式计算宣言》，推动了亚马逊从单一架构向面向服务架构的转变。从那以后的几十年里，随着我们转向微服务，然后是共享基础设施上的微服务，正如我在 re:Invent 大会上所讲，EDA（事件驱动架构）也应运而生。
向解耦的独立系统的转变是一种自然的演变。 微服务更小且更易于管理，它们可以使用满足其业务需求的技术栈，部署时间更短，开发人员可以更快地升级，可以在不影响整个系统的情况下部署新组件，最重要的是，如果其中一个微服务部署失败，系统的其余部分仍能正常工作。 当服务恢复上线时，它会重播它错过的事件并执行。 这就是我们所说的可演化架构。 随着时间的推移，它可以很容易地改变。 您可以从一个小型项目事开始，让它随着你的原景逐渐增长复杂性。
Amazon S3 一个很好的例子，展示了一项扩展了近 40 倍的服务。 自 2006 年推出时仅有几个微服务，现在已经发展到 300 多个，引入了新的存储方法、策略机制和存储类别。 这种发展得益于架构的可演进性，这在设计系统时是一个至关重要的考虑因素。
但是，我想重申，没有一种架构模式可以统治所有这些。 您选择如何开发、部署和管理服务将始终取决于您正在设计的产品、构建它的团队的技能以及您希望向客户提供的体验（当然还有成本、速度、 和弹性）。 例如，一家拥有五名工程师的初创公司可能会选择单体架构，因为它更容易部署，而且不需要他们的小团队学习多种编程语言。 他们的需求与拥有数十个工程团队的企业有着根本的不同，每个工程团队管理一个单独的子服务。 没关系。 这是关于为工作选择合适的工具。
单向门很少。 对系统进行定期评估与首次构建它们同样重要，甚至更重要。 因为系统运行时间比设计它们的时间要长得多。 因此，单体并没有消亡（恰恰相反），但可演进的架构在不断变化的技术格局中扮演着越来越重要的角色，这可能是因为云技术。
现在，去建造吧！
