微服务构架-单体架构

一、上下文

您正在开发服务器端企业应用程序。它必须支持各类不一样的客户端，包括桌面浏览器，移动浏览器和本机移动应用程序。该应用程序还可能会公开供第三方使用的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语言编写的组件在单片体系结构中没有位置。此外，若是您的应用程序使用随后变得过期的平台框架，那么将应用程序逐步迁移到更新更好的框架可能具备挑战性。