该应用程序被部署为单个应用程序。例如，Java Web 应用程序由一个在 Web 容器（如 Tomcat）上运行的 WAR 文件组成。Rails 应用程序由单个目录层次结构组成，使用例如 Apache/Nginx 上的 Phusion Passenger 或 Tomcat 上的 JRuby 部署。您可以在负载均衡器后面运行应用程序的多个实例，以扩展和提高可用性。
结果上下文
这个解决方案有很多好处：
易于开发 - 当前开发工具和 IDE 的目标是支持单片应用程序的开发易于部署 - 您只需在适当的运行时部署 WAR 文件（或目录层次结构）易于扩展 - 您可以通过在负载均衡器后面运行应用程序的多个副本来扩展应用程序但是，一旦应用程序变大并且团队规模扩大，这种方法就会有许多缺点，这些缺点变得越来越明显：
庞大的单体代码库吓倒了开发人员，尤其是团队新手。该应用程序可能难以理解和修改。因此，开发速度通常会放缓。此外，由于没有硬模块边界，模块化会随着时间的推移而分解。此外，由于很难理解如何正确实施更改，因此代码的质量会随着时间的推移而下降。这是一个向下的螺旋。IDE 过载 - 代码库越大，IDE 越慢，开发人员的生产力就越低。重载的 Web 容器 - 应用程序越大，启动所需的时间就越长。这对开发人员的生产力产生了巨大的影响，因为等待容器启动的时间被浪费了。它也影响部署。持续部署很困难——大型单体应用程序也是频繁部署的障碍。为了更新一个组件，您必须重新部署整个应用程序。这将中断后台任务（例如 Java 应用程序中的 Quartz 作业），无论它们是否受到更改的影响，并可能导致问题。尚未更新的组件也有可能无法正确启动。因此，与重新部署相关的风险会增加，从而阻碍频繁更新。这对于用户界面开发人员来说又是一个问题，因为他们通常需要快速迭代并频繁重新部署。扩展应用程序可能很困难 - 单体架构是它只能在一个维度上扩展。一方面，它可以通过运行更多的应用程序副本随着交易量的增加而扩展。一些云甚至可以根据负载动态调整实例数量。但另一方面，这种架构无法随着数据量的增加而扩展。应用程序实例的每个副本都将访问所有数据，这会降低缓存效率并增加内存消耗和 I/O 流量。此外，不同的应用程序组件具有不同的资源需求——一个可能是 CPU 密集型的，而另一个可能是内存密集型的。使用单体架构，我们无法独立扩展每个组件扩展开发的障碍 - 单体应用程序也是扩展开发的障碍。一旦应用程序达到一定规模，就可以将工程组织划分为专注于特定功能领域的团队。例如，我们可能希望拥有 UI 团队、会计团队、库存团队等。单体应用程序的问题在于它阻止了团队独立工作。团队必须协调他们的开发工作和重新部署。团队做出改变和更新产品要困难得多。需要对技术堆栈做出长期承诺——单体架构迫使您与您在开发之初选择的技术堆栈（在某些情况下，与该技术的特定版本）结合。对于单体应用程序，可能难以逐步采用更新的技术。例如，假设您选择了 JVM。您可以选择一些语言，因为除了 Java 之外，您还可以使用与 Java 很好地互操作的其他 JVM 语言，例如 Groovy 和 Scala。但是用非 JVM 语言编写的组件在您的单体架构中没有一席之地。此外，如果您的应用程序使用的平台框架随后变得过时，那么将应用程序逐步迁移到更新和更好的框架可能具有挑战性。相关模式微服务架构(我们将在接下来的讲解会介绍微服务架构模式)是解决单体架构局限性的另一种模式。
已知案例Netflix、Amazon.com 和 eBay 等知名互联网服务最初采用单体架构。作者开发的大多数 Web 应用程序都采用单体架构。
目前很少有企业使用单体模式
敬请期待下一遍：软件模式之微服务架构介绍
关注我本站所有文章和资源仅为个人工作和学习中的记录，部分观点有一定主观性，若有不妥，欢迎斧正。
欢迎指出网站中有问题的地方，我会尽快修正，谢谢！
欢迎转载谢谢！
