软件模式之单体架构介绍

MobotStone

已于 2022-01-28 15:23:23 修改

阅读量1.6k

点赞数

分类专栏：软件设计模式文章标签：架构 java 微服务 microservices

于 2022-01-26 11:14:06 首次发布

本文链接：https://blog.csdn.net/stone1290/article/details/122697812

版权

软件设计模式专栏收录该内容

12 篇文章 1 订阅

订阅专栏

背景

您正在开发服务器端企业应用程序。它必须支持各种不同的客户端，包括桌面浏览器、移动浏览器和本地移动应用程序。该应用程序还可能公开一个 API 供第 3 方使用。它还可以通过 Web 服务或消息代理与其他应用程序集成。应用程序通过执行业务逻辑来处理请求（HTTP 请求和消息）；访问数据库；与其他系统交换消息；并返回 HTML/JSON/XML 响应。有对应于应用程序不同功能区域的逻辑组件。

问题

应用程序的部署架构是什么？

限制

有一个开发团队正在开发该应用程序
新的团队成员必须迅速变得富有成效
应用程序必须易于理解和修改
您想练习应用程序的持续部署
您必须在多台机器上运行应用程序的多个实例以满足可伸缩性和可用性要求
您想利用新兴技术（框架、编程语言等）

解决方案

构建具有单体架构的应用程序。例如：

一个 Java WAR 文件。
Rails 或 NodeJS 代码的单个目录层次结构

例子

假设您正在构建一个电子商务应用程序，该应用程序从客户那里接收订单，验证库存和可用性，然后发货。该应用程序由几个组件组成，包括实现用户界面的 StoreFrontUI，以及一些用于检查信用、维护库存和运输订单的后端服务。

该应用程序被部署为单个应用程序。例如，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 语言编写的组件在您的单体架构中没有一席之地。此外，如果您的应用程序使用的平台框架随后变得过时，那么将应用程序逐步迁移到更新和更好的框架可能具有挑战性。