[译]一体化架构(Monolithic Architecure)

This a translation of an article ( http://microservices.io/patterns/monolithic.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

模式：一体化架构

背景

假设你在开发一个服务端应用。该应用必须支持各类各样的客户端，包括桌面浏览器、手机浏览器和本地手机应用。应用可能也须要公开部分API供第三方使用，还可能与其余应用经过web service或消息代理(message broker)相集成。应用执行业务逻辑来处理请求(HTTP请求或者消息)；访问数据库；与其余系统交换消息；并返回HTML/JSON/XML类型的响应。

应用或是多层架构或是六角架构，而且包含多种类型的组件：

• 表示组件(Presentation components) - 响应处理HTTP请求，并返回HTML或JSON/XML(对于web service API)

• 业务逻辑(Business logic) - 应用的业务逻辑

• 数据库访问逻辑(Database access logic) - 数据访问对象用于访问数据库

• 应用集成逻辑(Application integration logic) - 消息层，如基于Spring的集成

这些逻辑组件分别响应应用中不一样的功能模块。

问题

应用的部署架构是什么？

推进力

• 该应用由一个开发者团队在维护

• 团队新成员必须快速上手

• 应用应该易于理解和修改

• 你想对应用进行持续集成

• 你必须在多台机器上部署多份应用的拷贝，以知足可伸缩性和可用性的要求

• 你想使用新技术(框架、编程语言等)

解决方案

使用一体化架构构建应用。如：

• 单个Java WAR文件

• 单个Rails或NodeJS目录结构

举例

咱们假设你在构建一个电子商务应用，应用从客户接收订单，验证库存和可用额度，并派送订单。应用包含多个组件，包括StoreFrontUI，用来实现用户接口，以及一些后台服务，用于检测信用额度、维护库存和派送订单。

应用做为一体应用部署。例如，一个Java web应用运行在Tomcat之类web容器上，仅包含单个WAR文件；一个Rails应用使用Phusion Passenger部署在Apache/Nginx上，或者使用JRuby部署在Tomcat上，它们都仅包含单个目录结构。为了伸缩和提升可用性，你能够在一个负载均衡器下面运行该应用的多份实例。

结果

这个方案有一些好处：

• 易于开发 - 当前开发工具和IDE的目标就是支持这种一体应用的开发

• 易于部署 - 你只须要将WAR文件或目录结构放到合适的运行环境下

• 易于伸缩 - 你只须要在负载均衡器下面运行应用的多份拷贝就能够伸缩

可是，一旦应用变大、团队增加，这种方法的缺点就越发明显：

• 巨大的一体代码库可能会吓到开发者，尤为是团队的新人。应用难于理解和修改。所以，开发速度一般会减缓。另外，因为没有模块硬边界，模块化也随时间而破坏。还有，由于难于理解如何实现变动，代码质量也随时间降低。这是个恶性循环！

• 超载的IDE - 代码库越大，IDE越慢，开发者效率越低。

• 超载的web容器 - 应用越大，容器启动时间越长。所以开发者大量的时间被浪费在等待容器启动上。这也会影响到部署。

• 难于持续部署 - 对于频繁部署，巨大的一体应用也是个问题。为了更新一个组件，你必须从新部署整个应用。这还会中断后台任务(如Java应用的Quartz做业)，无论变动是否影响到这些任务，此外还可能引起问题。未被更新的组件也可能于是不能正常启动。所以，鉴于从新部署的相关风险会增长，不鼓励频繁更新。这尤为对用户界面的开发者来讲是个问题，由于他们一般须要快速迭代，频繁从新部署。

• 难于伸缩应用 - 一体架构只能在一个维度伸缩。一方面，它能够经过运行多个拷贝来伸缩知足业务量的增长。某些云服务甚至能够动态地根据负载调整应用实例的数量。可是另外一方面，该架构不能伸缩知足数据量的增长。每一个应用实例都要访问所有数据，这使缓存低效，而且提高了内存占用和I/O流量。并且，不一样的组件所需资源不一样 - 有些多是CPU密集型的，另外一些多是内存密集型的。一体架构下，咱们不能独立伸缩各个组件。

• 难于调整开发规模 - 一体应用对调整开发规模也是个障碍。一旦应用达到必定规模，将工程组织分红专一于特定功能模块的团队一般更有效。好比，咱们可能须要UI团队，会计团队，库存团队等。一体应用的问题是它阻碍组织团队相互独立地工做。团队之间必须在开发进度和从新部署上进行协调。对团队来讲也很难改变和更新产品。

• 须要对一个技术栈长期投入 - 一体架构迫使你娶下开发初选择的技术栈(某些状况下，是那项技术的某个版本)。一体架构下，很难递增式地采用更新的技术。好比，想象下你选了JVM。除了Java你还能够选择其余使用JVM的语言，它们好比Groovy和Scala也能够与Java很好地进行互操做。可是一体架构下，非JVM语言写的组件就不行。并且，若是应用使用了后期过期的平台框架，将应用迁移到更新更好的框架上就颇有挑战性。还有可能，为了采用新的平台框架，你要重写整个应用，这就太冒险了。

相关模式

微服务架构是解决一体化架构缺点的替代模式。

已知案例

著名的互联网服务，如Netflix, Amazon.com和eBay开始都使用一体架构。做者开发的大部分web应用也是一体架构的。

变动

第一篇：一体化架构(Monolithic Architecture)

第二篇：微服务架构(Microservices Architecure)

            伸缩立方(Scale Cube)

第三篇：API网关(API Gateway)