架构模式：单体架构
上下文
您正在开发服务器端企业应用程序。它必须支持各种不同的客户端，包括桌面浏览器，移动浏览器和本机移动应用程序。该应用程序还可能会公开供第三方使用的API。它还可以通过Web服务或消息代理与其他应用程序集成。应用程序通过执行业务逻辑来处理请求（HTTP请求和消息）;访问数据库;与其他系统交换消息;并返回HTML / JSON / XML响应。存在与应用程序的不同功能区域相对应的逻辑组件。
问题
应用程序的部署架构是什么？
关注点
- 有一组开发人员在开发应用程序
- 新团队成员必须快速提高工作效率
- 应用程序必须易于理解和修改
- 您希望实践应用程序的持续部署
- 您必须在多台计算机上运行多个应用程序实例才能满足可伸缩性和可用性要求
- 您希望利用新兴技术（框架，编程语言等）
结论
使用单片架构构建应用程序。例如：
- 单个Java WAR文件。
- Rails或NodeJS代码的单个目录层次结构
例子
让我们假设您正在构建一个电子商务应用程序，该应用程序接收来自客户的订单，验证库存和可用信用，并运送它们。该应用程序包含几个组件，包括实现用户界面的StoreFrontUI，以及用于检查信用，维护库存和装运订单的一些后端服务。
该应用程序部署为单个整体应用程序。例如，Java Web应用程序由单个WAR文件组成，该文件在Web容器（如Tomcat）上运行。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应用程序都具有单一体系结构。