传统可扩展架构-SOA
##################

* 1996 年 Gartner 的两位分析师 Roy W. Schulte 和 Yefim V. Natis 发表了第一个 SOA 的报告
* 2005 年，Gartner 预言： `到了 2008 年，SOA 将成为 80% 的开发项目的基础 <https://www.safaribooksonline.com/library/view/soa-in-practice/9780596529550/ch01s04.html>`_


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 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。
      如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。


.. figure:: https://img.zhaoweiguo.com/knowledge/images/architectures/expandabilitys/soa1.png

   典型的 SOA 架构

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


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


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




.. important:: 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 那样的处理

.. image:: https://img.zhaoweiguo.com/knowledge/images/architectures/expandabilitys/soa2-microservice.png

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

.. note:: Martin Fowler 在他的微服务文章中，做 `提炼 <https://martinfowler.com/articles/microservices.html>`_ : 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 的本质区别所在。