专栏首页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

关于作者:

宋潇男

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

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

原著作者

Chris Richardson

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

本文分享自微信公众号 - EAWorld(eaworld),作者:宋潇男

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-09-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 全网首发:逐一解读云原生应用开发“12-Factors”

    作者自序: 12原则的提出已有五年之久,可惜业界一直缺乏一篇对其进行简明解读的指导性文章,所以我决定写这样一篇文章。在微服务模式的大背景下,力求对12原则的来龙...

    yuanyi928
  • 让前端走进微时代, 微微一弄很哇塞!

    微前端这个词这两年很频繁的出现在大家的视野中,主要是把微服务的概念引入到了前端,让前端的多个模块或者应用解耦,做到让前端的子模块独立仓储,独立运行,独立部署。

    yuanyi928
  • 普元微服务平台EOS Platform 8全新发布

    普元新一代应用平台EOS Platform 8已经全面拥抱微服务架构,支持分布式架构,为企业业务上云提供云原生应用的支撑。同时该版本完全支持Spring Boo...

    yuanyi928
  • 如何打造一个以应用为核心的运维体系

    在前面《有了CMDB,为什么还要应用配置管理》一文中,描述了CMDB和应用配置管理的关系,这里面提到了非常核心的一个概念:应用,。但是,上篇中更多的是从运维的角...

    赵成
  • 运营app,第一步要做什么?【从0开始运营APP之①】

    无论是大公司还是小企业,从0开始推广一个APP,都要经历一个创业过程——时刻面临人少、缺资源,“无推广预算”的窘境。腾讯云分析从这个月开始,将推出【从0开始运...

    腾讯大数据
  • 可能是你见过的最完善的微前端解决方案

    技术栈无关:主框架不限制接入应用的技术栈,子应用具备完全自主权 独立开发、独立部署:子应用仓库独立,前后端可独立开发,部署完成后主框架自动完成同步更新 独立运行...

    用户4962466
  • 全网首发:逐一解读云原生应用开发“12-Factors”

    作者自序: 12原则的提出已有五年之久,可惜业界一直缺乏一篇对其进行简明解读的指导性文章,所以我决定写这样一篇文章。在微服务模式的大背景下,力求对12原则的来龙...

    yuanyi928
  • AWCMP实现云应用全生命周期管理

    云应用生命周期管理是整个云平台的核心业务,以“应用商店”为核心,实现快速的应用开发和应用分发,实现整个云应用生命周期的管理和运营。通过对虚拟机、容器和物理机以预...

    海云捷迅
  • 2017年度盘点丨基础架构演化:从“以资源为中心”到“以应用为中心”的迁移

    作者:刘建,搜狗架构师,商业平台基础平台负责人,十多年Java相关研发经验,在互联网软件体系结构、分布式计算、面向服务体系结构、用户身份安全等方面有浓厚的兴趣及...

    CSDN技术头条
  • 快应用之开发体验纪要

    何谓「快应用」呢?它是基于手机硬件平台的新型应用形态,标准是由主流手机厂商组成的快应用联盟联合制定。其标准的诞生将在研发接口、能力接入、开发者服务等层面建设标准...

    晚晴幽草轩轩主

扫码关注云+社区

领取腾讯云代金券