普元云计算-微服务模式系列之一：总体式架构

本文为普元普元云计算架构师宋潇男原创翻译微服务模式文章系列，独家受权EAII企业架构创新研究院（微信号：eaworld）发布，转载请注明出处，违者必究。

 

熟悉个人朋友都知道，我很不喜欢翻译东西，由于在两种语言的思惟方式之间作频繁切换对我来讲是件很痛苦的事情。可是此次不同，公司和同事的大力支持下降了个人痛苦指数，让我可以坚持把Chris Richardson的微服务模式系列文章翻译完，今天发布第一篇，《总体式架构》。

 

背景

  

在开发服务端企业应用时，应用须要支持各类不一样类型的客户端，好比桌面浏览器、移动浏览器以及原生移动应用。应用还须要向第三方提供可访问的API，并经过Web Service或者消息代理与其它应用实现集成。应用经过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。

 

应用采用多层架构或者六角架构，主要由如下几类不一样组件构成：

 

• 展示组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）

• 业务逻辑——应用的业务逻辑

• 数据库访问逻辑——用于访问数据库的数据访问对象

• 应用集成逻辑——消息层，例如基于Spring Integration

 

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

 

 

 

问题

 

 

应用的部署架构是什么？

 

 

需求

 

 

• 应用须要由一个开发者团队专门负责

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

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

• 对应用可以进行持续部署

• 须要在多台设备上运行应用副本，从而知足可扩展性与可用性的要求

• 使用各类新技术（框架、编程语言等）

 

 

 

方案

 

 

使用单体架构构建应用。例如：

单个Java WAR文件。

单个Rails或者NodeJS代码目录层级。

 

 

 

举例

 

 

假设须要构建一款电子商务应用程序，使其可以接收来自客户的订单、验证库存信息与可用信用额度，然后进行发货。该应用程序会包含多个组件，其中StoreFrontUI负责实现用户界面，而其它后端服务则分别负责检查信用额度、维护库存信息以及发送订单。

 

应用被看成一个单体进行部署。例如：一个Java Web应用仅包含一个运行在Tomcat之类的Web容器上WAR文件。一个Rails应用由单一目录层级构成，该目录层级的部署经过在Apache/Nginx上使用Phusion Passenger，或者在Tomcat上使用JRuby得以实现。为了提升扩展性和可用性，你能够在负载均衡器以后运行此应用的多个实例。

 

 

 

结果

 

 

这类解决方案拥有如下优点：

 

• 易于开发——当前开发工具与IDE的设计目标即在于支持单体应用的开发。

• 易于部署——你只须要将该WAR（或者目录层级）部署在合适的运行环境中便可。

• 易于扩展——你能够在负载均衡器后面运行多个应用副本实现扩展。

 

然而，一旦应用变大、团队扩大，这种方案的弊端将会变得愈发明显：

 

• 单体应用巨大的代码库可能会让人望而生畏，特别是对那些团队新成员来讲。应用难以被理解和进行修改，进而致使开发速度减慢。因为没有清晰的模块边界，模块化会逐渐消失。另外，因为难以正确把握代码变化，致使代码质量逐步下滑，陷入恶性循环。

   

• 过载的IDE——代码库越大，IDE速度越慢，开发者的生产效率越低。

   

• 过载的Web容器——应用越大，Web容器启动时间越长。容器启动耗费时间，极大影响到开发者的生产效率。对部署工做也有负面影响。

   

• 持续部署困难——巨大的单体应用自己就是频繁部署的一大障碍。为了更新一个组件，你必须从新部署整个应用。这会中断那些可能与更改无关的后台任务（例如Java应用中的Quartz任务），同时可能引起问题。另外，未被更新的组件有可能没法正常启动。从新部署会增长风险，进而阻碍频繁更新。由于用户界面开发者常常须要进行快速迭代与频繁从新部署，因此这对用户界面开发者而言更加是个难题。

 

• 应用扩展困难——单体架构只能进行一维伸缩。一方面，它能够经过运行多个应用副原本增长业务容量，实现扩展。一些云服务甚至能够根据负载量动态调整实例数量。但在另外一方面，数据量增大会使得该架构没法伸缩。每一个应用实例须要访问全部数据，致使缓存低效，加大内存占用和I/O流量。另外，不一样的应用组件有不一样的资源需求——有的是CPU密集型的，另一些是内存密集型的。单体架构没法单独伸缩每一个组件。

   

• 难于进行规模化开发——单体应用是规模化开发的障碍。应用一旦达到特定规模，须要将现有组织拆分红多个团队，每一个团队负责不一样的功能模块。举例来讲，咱们可能须要设立UI团队、会计团队、库存团队等等。单体应用的问题在于它使团队没法独立展开工做。团队须要在工做进度和从新部署上进行协调。对于各团队而言，这使得变动和更新产品变得异常困难。

   

• 须要长期关注同一套技术栈——单体架构迫使咱们长期使用在开发初期选定的技术堆栈（在某些状况下，多是某些技术的特定版本）。单体应用是渐进采用新技术的障碍。举例来讲，若是咱们选择了JVM，那么咱们能够选择Java之外的一些语言，由于Groovy和Scala等基于JVM的语言也能够和Java进行良好的互操做。但此时以非JVM语言编写的组件就没法在该单体架构中使用。另外，若是你们所使用的应用平台框架已通过时，那么咱们将很难将应用迁移到其它更新而且更完善的框架当中。有时候为了采用一套新型平台框架，咱们甚至须要重写整个应用，这是风险很大的工做。

 

 

 

相关模式

 

 

微服务架构是一种可以解决单体架构各类局限的备选模式。

 

 

 

已知案例

 

 

知名的互联网服务商最初皆采用单体架构，包括Netflix、Amazon.com以及eBay等等。做者开发的大多数Web应用也是用单体架构。

原文连接：http://microservices.io/patterns/monolithic.html

 

若想与做者有更多交流，请添加微信：cloud_primeton

 

 

关于做者：

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师，曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工做。

 

原著做者

Chris Richardson

世界十大软件架构师之一，《POJOS IN ACTION》一书的做者。他的研究领域包括Spring、Scala、微服务架构设计、NoSQL数据库、分布式数据库、分布式数据管理、事件驱动的应用编程等。

 

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

 

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信帐号。