主页

索引

模块索引

搜索页面

传统可扩展架构-SOA

• 1996 年 Gartner 的两位分析师 Roy W. Schulte 和 Yefim V. Natis 发表了第一个 SOA 的报告

• 2005 年，Gartner 预言： 到了 2008 年，SOA 将成为 80% 的开发项目的基础

SOA 出现 的背景是企业内部的 IT 系统重复建设且效率低下，主要体现在:

1. 企业各部门有独立的 IT 系统
    比如人力资源系统、财务系统、销售系统，这些系统可能都涉及人员管理，
    各 IT 系统都需要重复开发人员管理的功能。
    例如，某个员工离职后，需要分别到上述三个系统中删除员工的权限。

2. 各个独立的 IT 系统可能采购于不同的供应商
    实现技术不同，企业自己也不太可能基于这些系统进行重构。

3. 随着业务的发展，复杂度越来越高，更多的流程和业务需要多个 IT 系统合作完成。
    由于各个独立的 IT 系统没有标准的实现方式
      例如，人力资源系统用 Java 开发，对外提供 RPC；
          而财务系统用 C# 开发，对外提供 SOAP 协议
    每次开发新的流程和业务，都需要协调大量的 IT 系统，同时定制开发，效率很低。

为了应对传统 IT 系统存在的问题，SOA 提出了 3 个关键概念:

1. 服务
  所有业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发。
  服务可大可小，可简单也可复杂。
  例如，人力资源管理可以是一项服务，包括人员基本信息管理、请假管理、组织结构管理等功能；
  而人员基本信息管理也可以作为一项独立的服务，组织结构管理也可以作为一项独立的服务。
  到底是划分为粗粒度的服务，还是划分为细粒度的服务，需要根据企业的实际情况进行判断。

2. ESB
  ESB 的全称是 Enterprise Service Bus，中文翻译为 “企业服务总线”。
  从名字就可以看出，ESB 参考了计算机总线的概念。
  计算机中的总线将各个不同的设备连接在一起，ESB 将企业中各个不同的服务连接在一起。
  因为各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。
  SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。

3. 松耦合
  松耦合的目的是减少各个服务间的依赖和互相影响。
  因为采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。
  如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

典型的 SOA 架构

备注

SOA 架构是比较高层级的架构设计理念，一般情况下我们可以说某个企业采用了 SOA 的架构来构建 IT 系统，但不会说某个独立的系统采用了 SOA 架构。例如，某企业采用 SOA 架构，将系统分为 “人力资源管理服务”“考勤服务”“财务服务”，但人力资源管理服务本身通常不会再按照 SOA 的架构拆分更多服务，也不会再使用独立的一套 ESB

ESB 虽然功能强大，但现实中的协议有很多种，如 JMS、WS、HTTP、RPC 等，数据格式也有很多种，如 XML、JSON、二进制、HTML 等。ESB 要完成这么多协议和数据格式的互相转换，工作量和复杂度都很大，而且这种转换是需要耗费大量计算性能的，当 ESB 承载的消息太多时，ESB 本身会成为整个系统的性能瓶颈。

备注

当然，SOA 的 ESB 设计也是无奈之举。回想一下 SOA 的提出背景就可以发现，企业在应用 SOA 时，各种异构的 IT 系统都已经存在很多年了，完全重写或者按照统一标准进行改造的成本是非常大的，只能通过 ESB 方式去适配已经存在的各种异构系统。

重要

SOA 是整合已有系统服务，微服务是拆分或重构复杂系统服务。soa 主要不是为了拆分，而是将已经存在的异构系统整合起来

微服务与 SOA 的关系

1. 服务粒度:

   整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。
   例如，对一个大型企业来说:
     “员工管理系统” 就是一个 SOA 架构中的服务；
     而如果采用微服务架构，则 “员工管理系统” 会被拆分为更多的服务，
       比如 “员工信息管理”“员工考勤管理”“员工假期管理” 和 “员工福利管理” 等更多服务。
   

2. 服务通信:

   SOA 采用了 ESB 作为服务间通信的关键组件:
       负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。
   微服务推荐使用统一的协议和格式:
       例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。
   Martin Fowler 将微服务架构的服务通讯理念称为 “Smart endpoints and dumb pipes”
   
   ESB 太强大了:
     既知道每个服务的协议类型（例如，是 RMI 还是 HTTP）
     又知道每个服务的数据类型（例如，是 XML 还是 JSON）
     还知道每个数据的格式（例如，是 2017-01-01 还是 01/01/2017）
   微服务的 “dumb pipes” 仅仅做消息传递，对消息格式和内容一无所知
   

3. 服务交付:

   SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；
   微服务的架构理念要求 “快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
   
   如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过 20 个微服务），
   整体就难以达到快速交付的要求，
   
   很多企业在实行微服务时踩过的一个明显的坑: 就是系统拆分为微服务后，部署的成本呈指数上升。
   

4. 应用场景:

   SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景。
       这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，
       有的是内部开发的，有的是外部购买的，
       无法完全推倒重来或者进行大规模的优化和重构。
       因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。
   
   微服务更加适合于快速、轻量级、基于 Web 的互联网系统
       这类系统业务变化快，需要快速尝试、快速交付；
       同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），
       但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行 SOA 的 ESB 那样的处理
   

备注

结论：SOA 和微服务本质上是两种不同的架构设计理念，只是在 “服务” 这个点上有交集而已

备注

Martin Fowler 在他的微服务文章中，做 提炼 : In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. 三个关键词分别是：small、lightweight、automated，基本上浓缩了微服务的精华，也是微服务与 SOA 的本质区别所在。

主页

索引

模块索引

搜索页面