单体架构的概念

单体架构是一种将系统所有功能耦合在一个应用的架构方式。它也被称为单体系统或单体应用。这种架构方式的特点是功能集中、代码和数据中心化，所有功能部署在同一进程中。

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

单体架构的优缺点
优点：
1.部署简单：只需部署一个应用，减少了部署多个应用的复杂度和成本。
2.技术单一：使用同一种技术和语言编写应用，易于维护和开发。
3.用人成本低：只需招聘同一技术栈的工程师，减少了跨技术招聘的成本。

缺点：
1.系统启动慢：应用较大，启动需要更长时间。
2.系统错误隔离性差、可用性差：所有功能都耦合在一个应用中，一个功能出问题会影响整个应用的可用性。
3.可伸缩性差：无法根据功能模块进行伸缩，只能整体进行伸缩。
4.线上问题修复周期长：由于代码库复杂，出现问题需要较长的时间进行定位和修复。
5.难以扩展：无法按需对系统进行扩展，只能整体扩展。
6.交付可靠的单体应用是一项挑战：由于代码库复杂，容易出现故障隔离问题，导致频繁的系统故障和宕机。

单体架构并不过时
软件架构与桥梁和房屋的架构有很大不同。 在桥梁建成后，改变它的建造方式是非常困难的，甚至是无法改变的。软件是完全不同的，一旦我们运行我们的软件，我们可能会获得一些在设计时未曾预料到的关于工作负载的认识。 而且，如果我们在一开始就意识到这一点，并且选择了一个可演进的架构，我们就可以在不影响客户体验的情况下更换组件。 我的经验法则是，随着每个数量级的增长，就应该重新审视架构，以确定它是否仍能支持下一个数量级的增长。

一个很好的例子可以从 Prime Video 的工程团队撰写的两篇颇有深度的博客文章中找到。 第一篇文章阐述了周四晚上橄榄球比赛直播是如何以分布式工作流架构为基础构建的。 第二篇是最近的一篇文章，详细探讨了他们的流媒体监控工具的架构，以及他们的经验和分析如何促使他们将其设计成一个单体架构。并不存在一种适用于所有情况的解决方案。 我们总是鼓励我们的工程师寻找最佳解决方案，并不强制遵循特定的架构风格。 如果你雇佣了最优秀的工程师，你应该相信他们有能力作出最佳决策。

我一直强烈建议开发者在构建系统时考虑到它们的系统随时间的推移而演进的需求，并确保这样的基础，可以用最少的依赖项来改变和扩展它们。 事件驱动架构 (EDA) 和微服务非常适合这一点。 但是，如果有一组服务始终参于到响应中，具有相同的扩展和性能要求、相同的安全风险，并且最重要的是，由一个团队管理，那么将它们合并以简化架构是非常值得尝试的。

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

向解耦的独立系统的转变是一种自然的演变。 微服务更小且更易于管理，它们可以使用满足其业务需求的技术栈，部署时间更短，开发人员可以更快地升级，可以在不影响整个系统的情况下部署新组件，最重要的是，如果其中一个微服务部署失败，系统的其余部分仍能正常工作。 当服务恢复上线时，它会重播它错过的事件并执行。 这就是我们所说的可演化架构。 随着时间的推移，它可以很容易地改变。 您可以从一个小型项目事开始，让它随着你的原景逐渐增长复杂性。

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

但是，我想重申，没有一种架构模式可以统治所有这些。 您选择如何开发、部署和管理服务将始终取决于您正在设计的产品、构建它的团队的技能以及您希望向客户提供的体验（当然还有成本、速度、 和弹性）。 例如，一家拥有五名工程师的初创公司可能会选择单体架构，因为它更容易部署，而且不需要他们的小团队学习多种编程语言。 他们的需求与拥有数十个工程团队的企业有着根本的不同，每个工程团队管理一个单独的子服务。 没关系。 这是关于为工作选择合适的工具。

单向门很少。 对系统进行定期评估与首次构建它们同样重要，甚至更重要。 因为系统运行时间比设计它们的时间要长得多。 因此，单体并没有消亡（恰恰相反），但可演进的架构在不断变化的技术格局中扮演着越来越重要的角色，这可能是因为云技术。

现在，去建造吧！