构建可演进的软件系统是一种策略，而不是一种宗教。必须以开放的心态重新审视您的架构。
软件架构不像桥梁和房屋的架构那样。桥梁建成后，很难、甚至不可能改变它的建造方式。
软件则完全不同，一旦我们运行我们的软件，我们可能会得到关于工作负载的见解，而这些见解是我们在设计软件时没有的。
而且，如果我们一开始就意识到这一点，并选择了一个可进化的架构，我们就可以在不影响客户体验的情况下改变组件。
我的经验法则是，每增长一个数量级，你就应该重新审视你的架构，并确定它是否还能支持下一个数量级的增长。
一个很好的例子可以在Prime Video的工程团队写的两篇有洞察力的博客文章中找到：
第一篇描述了星期四晚上的足球直播是如何围绕分布式工作流架构构建的。
第二篇是最近的一篇文章，深入探讨了他们的流媒体监控工具的架构，以及他们的经验和分析如何促使他们将其作为一个单一的架构来实施。
没有一个放之四海而皆准的东西。我们总是敦促我们的工程师找到最好的解决方案，而且没有强制要求特定的架构风格。如果你雇用了最好的工程师，你应该相信他们能做出最好的决定。
我总是敦促架构师考虑他们的系统随着时间的推移而演变，并确保基础是这样的：你可以用最少的依赖性来改变和扩展它们。
事件驱动架构（EDA）和微服务在这方面是一个很好的匹配。然而，如果有一组服务总是有助于响应，具有完全相同的扩展和性能要求，相同的安全向量，而且最重要的是，由一个团队管理，那么就值得努力看看将它们结合起来是否能简化你的架构。
可演化的架构是我们在亚马逊从一开始就重视的东西。对我们的系统进行重新评估和重新架构，以满足我们客户不断增长的需求。你可以一直追溯到1998年，当时一群高级工程师撰写了《分布式计算宣言》，该宣言推动了亚马逊从单体到面向服务架构的发展。在此后的几十年里，事情一直在发展，我们转向了微服务，然后是共享基础设施上的微服务，以及我在re:Invent上谈到的EDA。
向解耦自足系统的转变是一种自然的进化。微服务更小，更容易管理，他们可以使用符合其业务要求的技术栈，部署时间更短，开发人员可以更快地提升，新组件的部署不会影响整个系统，最重要的是，如果一个部署导致一个微服务瘫痪，系统的其他部分继续工作。当服务重新上线时，它会重现它所错过的事件并执行。这就是我们所说的可进化的架构。它可以很容易地随着时间的推移而被改变。你从很小的东西开始，并允许它在复杂度上增长，以配合你的愿景。
S3是一个很好的例子，它的服务已经扩展了近40倍。自2006年推出仅有的几个微服务以来，S3已经发展到300多个，增加了新的存储方法、策略机制和存储类别。这只是因为架构的可发展性，这是设计系统时的一个重要考虑。
然而，我想重申，没有一种架构模式可以统治它们。你选择如何开发、部署和管理服务，总是由你所设计的产品、构建该产品的团队的技能、以及你想提供给客户的体验（当然还有成本、速度和弹性等因素）所驱动。
例如，一个有五个工程师的初创公司可能会选择一个单体架构，因为它更容易部署，而且不要求他们的小团队学习多种编程语言。
他们的需求与拥有几十个工程团队的企业根本不同，每个团队都在管理一个单独的子服务。这也没关系。
这是关于为工作选择正确的工具。
很少有单向的门。定期评估你的系统与首先建立它们同样重要，甚至更重要。
因为你的系统将比设计它们的时间长得多。
所以，单体并没有死（恰恰相反），但可演化的架构在不断变化的技术环境中发挥着越来越重要的作用，而这是云技术带来的可能。