微服务—企业级应用的拆分及整合之路

1.2.2 企业 SOA-EAl/ESB 治理

随着企业 IT 建设的不断深入， IT 系统越来越多 ，由于建设人员、建设时期不同， 差异很大，技术不断发展，每个时期采用的技术也不一样， 这些系统往往 形成独立的竖井。随着务的不断发展变化，系统之间交互的需求越来越多，把这些“竖井式”的系统进行一体化整合也随之被提上日程

1.2.2.1 点对点式（ P2P ）的直连模式

这是最原始的整合模式，直连手段也五花八门：文件交换、 RMI 技术、基于 HTTP 的远程调用 ……不一而足，如图 1.7 所示。这种 EAI 方案虽然取得了一定的成功，但存在种种致命缺点。一方面，这种模式最终会导致内部应用系统之间形成一张网，造成系统之间的强祸合，随着集成的应用越来越多，程序员需要编 和维护的远程直连相关代码的工作量也迅速增长，不易于系统及整个 IT 环境的升级维护及管控：另一方面，这种解决方案的出发点还是基于各个业务系统的需求，而不是从企业 IT 发展的整体需求出发，使用的技术和协议都很随意，格局所限，导致只能各自为政，没有在整体的基础之上适应未来的变化和发展。因此， P2P 的集成方式很快就被摒弃了，尤其是在系统数量很多的大型企业或网站之中。

1.2.2.2 星型连接模型

为了克服点对点集成的缺点，逐渐出现了基于中间件的企业应用集成方案 如图 1.8 所示，通过建立 个由中间件组成的企业应用底层架构，来联系整个企业的异构应用。这些作为集成引擎的底 中间件主要包括 RMI CORB DCOM J2EE/JCA EJB 等。

使用这些分布式处理中间件技术解决 P2P 的问题时，也存在一定的局限性。这些技术虽然都基于某种标准，但其传输、数据定义、访问模型等机制均不一样。同时，由于厂商利益导致的技术对抗，这些中间件之间很难互联互通，比如基于 Java 阳协议和基于微软的 DCOM之间就无法直连。如果企业内部采用多种这样的模式，容易形成几个大的竖井，这也在客观上阻碍了这种模式的进一步推广。

1.2.2.3 SOA/ESB 接模型

基于中间件的星型集成方式走不通，通用性更广的面向服务的架构 SOA ）随之被提了出来。 SOA 是一种组件概念模型，它建议将应用程序的不同功能单元（称为服务〉进行拆分，并通过定义良好的接口和契约将这些服务联系起来，接口是采用 中立的方式进行定义的，它独于实现服务的硬件平台、操作系统和编程语言，井有效兼容各种协议。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA 概念的具体落 形式（也是核心）就是服务总线 CES ，那么什么是服务总线呢？简而言之，我们可以把 ES 想象成一个连接所有企业级服务的脚手架，是一种松柏合的服务和应用之间标准的集成方式。

服务总线本质上就是传统中间件技术与 XML We 服务等技术结合的产物，这些中间件包MQ 各种网络或数据的协议转换及适配器、流程引擎等。服务总线为应用系统之间的互联互通提供了一个基于网络的、中心化的连接中枢，它可以通过一整套标准化的协议适配器（比如几仅协议、 SOAP 协议等）来支持应用之间在消息、事件、服务级别上动态地互联互通，被接入的应用还可以通过流程化的编排，把这些接入的基础服务聚合成更大粒度的复杂服务（服务编排〉，并通过诸如 UDDI 协议暴露 出去，供第三方系统查阅和调用。

如图 1. 9所示， ESB 中的核心部件是 Web 服务，它由如下几大组件构成

• WSDL (We 服务描述语言〉 种规范，定义如何用 XML 语法描述 eb 服务 WSDL定义了一套基于 XML 的语法，将 Web 服务描述为能够进行消息交换的服务访问点的集合，实现了以结构化的方式对 Web 服务的调用或通信交易进行描述。
• SOAP （简单对象访问协议〉：是一种基于 HTTP 协议和 X1也规范的、轻量的、简单的Web 服务的标准通信协议
• UDDI （通用描述、发现与集成服务〉：是 种目录服务，企业可以使用它对 Web Service进行注册和搜索。
• BPEL4WS （基于 Web 服务的业务过程执行语言） 实现对 Web 服务的流程化编排。

除了 Web 服务，各大软件厂商还共同制定了中立的 SOA 标准来保证其落地。这一努力最重要的成果体现在 个重量级规范上： SCA SDO WS-Policy SCA SDO 构成了 SOA程模型的基础，分别定义了服务组件的开发规范和数据的封装规范，而 WS-Polic 建立了 SOA组件之间安全交互的规范。

此外，服务适配器也是重要组件，它比较彻底地解决了不 同协议互相转换的问题，可以把不同数据格式或模型转成标准格式，比如把 XML 的输入转成 csv 传给只能处理 csv 数据的遗留服务，把 SOAP 1.1 务转成 SOAP 1.2 等。它还有一个重要功能是消息队列和事件驱动的消息传递，比如把 JMS 服务转化成 SOAP 协议。由于既支持 RB 这类强同步的调用，也支持基于诸如 JMS 这类 MQ 协议的异步调用机制，所以在 ESB 上可以实现如下的应用架构：

• 服务驱动的架构 CSOA ）一一分布式应用由可重用的服务组成；
• 消息驱动的架构（ Message Driven Architecture, MDA ）一一应用之间通过 ESB 发送和接收消息：
• 事件驱动的架构（ Event Driven Architecture, EDA ）一一应用之间异步地产生和接收消息。

图1.10是一个 ESB 的典型案例的架构图

1.2.2.4 SOA 治理

我们首先引用一个流传甚广的真实故事来看看为什么 SOA 需要治理。

20 世纪 90 年代后期， Sun 推出了一系列产品，包括 Java So ris 等，他们鼓励用户使用这些产品，但当时网速太慢了，在线下载几百兆的软件几乎无法实现。因此， Sun 在网站上推出了一个电子商务服务 ，通过信用卡支付 10 20 美元快递费用，就可以免费获赠 un 的产品光盘。负责这个电子商务服务 的程序员，另外写了一个在线服务 ，用来完成信用卡付账交易，它运行在内网中，采用 HTTP 传输加密的 XML 消息。服务 上线之后，一直工作得很好。不久之后，这个程序员被调到 Java 开发组，但是 Sun Java 网站提供一个类似 MSDN的Java 产品光盘订阅服务，称为服务B，这个程序员每季度向订阅者寄送最新的 Java 产品光盘订阅者也要通过信用卡支付订阅费。碰巧这项工作又交给了这位程序员来完成。他不愿意重写信用卡结账服务 ，既然原来的那个服务通过 HTTP 暴露在内网里，何不直接用？他简单地复用了这个信用卡结账服务 ，完成了任务。这样，在 20 世纪 90 年代后半期，这位程序员率先实现了企业服务的复用。

这样就形成了 个有趣的局面，即服务A中包含一个子服务Z ，而服务B又依赖于服务 z,服务 Z实际上成为了一个公共服务。但这个秘密只有那个程序员和少数几个人知道，sun理们对此懵然不知 几年之后，这位程序员 离开了 sun ，随着他的离去，这个秘密变得更加不为人知了。

随着互联网的发展，人们已经习惯从网上直接下载软件，服务A变得越来越过时。终于有一天，Sun的一个经理决定关闭服务A。结果意想不到的事情发生了，随着服务A的关闭，服务Z也被关闭了，这就导致了服务B全面崩溃，所有的订阅者都无法付款了。

这就是一个在缺乏治理和监管的情况下发生的典型事故。在SOA这个大背景下，涉及的应用及其他软硬件资源越来越多，这时候，我们迫切需要知道:IT整合的整体规划是否合理;线上目前共注册了哪些服务;哪些服务是可用的;哪些服务是核心服务;某些敏感服务是不是做了权限控制;服务的依赖关系是什么;一个服务发生变更，是否通知了依赖它的相关周边服务;等等。这些都是对服务的治理需求。实际上，“服务治理”这个概念就是伴随着SOA的发展被同步提出的。

毋庸置疑，SOA整个体系架构涉及的规范多、技术栈长、流程复杂，从战略规划到架构落地的过程中，如果缺少一定的治理保障，导致过程中出现缺失，就算我们最初有个100分的战略规划，最终也有可能收获一个不合格的实现结果，图1.11形象地描述了这个过程。

所以，实施服务治理的目标就是防止SOA实施的失控。一般来说，企业都会成立专门的团队或委员会来负责SOA治理，负责创建策略来执行治理和角色标识、授权并保证获得了决策与策略执行能力的人员的可靠性。这里的治理与管理是有区别的，二者之间通常存在以下差异:治理决定谁具有决策的权力和责任，为决策提供框架，保证做“对”的事情，走“正确”的路;管理是进行决策和实施决策的过程。

因此，治理讨论应该如何进行决策，而管理是进行决策和执行决策的过程。简单来说，治理委员会需要处理三个主要问题:

• 为了确保有效的盯资产管理，需要进行哪些决策？
• 谁应该负责进行这些决策？
• 这类决策如何执行和监视？

作为治理实现的核心部分，需要建立服务水平协议（Service Level Agreement，SLA，又称服务可用性协议）的衡量指标体系及监控评估体系，以持续地对其进行改进。同时，也会收集相关服务的性能度量来表征治理的有效性。

大多数企业都会采用某种业界通用的方法论来逐步实施SOA，该方法首先通过收集业务需求并对其进行抽象和优化来进行基础服务的建模;有了基础服务之后，就可以组装新的及现有的服务来实现业务流程;创建的这些服务及流程资产将被部署到安全的环境中被使用;在使用的过程中，还要持续地对这些资产进行优化管理。“建模一组装―部署—管理”这个过程周而复始，这就是著名的4阶段的SOA生命周期方法论。

与此对应,SOA治理同样遵循生命周期原则, IBM推出的“SOA治理及管理方法”(SGMM就把服务治理的生命周期定义为如下4个阶段:

• 计划 确定 SOA 治理的重点：
• 定义 定义 SOA 治理模型：
• 启用 实现 SOA 治理模型：
• 度量：改进 SOA 治理模型

SOA治理生命周期产生一个治理模型来管理SOA生命周期。这两个生命周期相互配合、同时运行，一起被使用，产生SOA组合应用程序及其服务。图1.12描述了它们之间的关系。

具体来说，通过对UDDI服务注册中心的梳理，可以获取服务提供者、服务使用者的相关信息，继而推导出服务或系统之间的依赖关系;通过ESB内置的日志监控，可以获取服务调用过程中的性能指标等信息;通过ITIL等运营系统,可以获取服务的相关维护信息，再结合UDDI服务注册中心不同时期的服务注册信息和依赖关系，可以获取服务变动情况跟踪报告和依赖变动跟踪报告，如图1.13所示。这些指标信息，构成了SOA服务治理的相关指标报告，并提交给治理委员会成员进行相关的分析，据此提出优化建议，从而驱动SOA架构的持续调整和深度优化。

1.2.2.5 SOA 的问题

主导这一时期SOA标准及治理标准的都是一帮老牌大厂，像IBM、Oracle等。正因如此,企业级SOA最大的问题就是它所涉及的技术栈太重，相关规范太复杂，导致落地很困难。毕竟，对于软件厂商而言，技术太简单、落地太容易的话，就很难在咨询及服务上卖出大价钱。

同样，这个时期的服务治理还是一种比较粗粒度的行为，更多的是通过诸如ITIL这类企业内部的IT流程管理来实现服务的注册和梳理。在治理过程中，人工行为占了很大的比重，自动化及智能化水平不足。比如，这个时期的WebService UDDI服务注册采用人工方式将服务的接口信息（服务名、服务URI等)配置到服务注册中心。它的问题是需要人工收集服务接口信息，这个过程可能产生滞后或者错误的信息，运维代价大、“人肉”方式无法对服务进行细粒度的管控。另外，缺少服务运行时动态治理能力，面对突发的流量高峰和业务冲击，传统的服务治理在响应速度、故障快速恢复等方面存在不足，无法敏捷地应对业务需求。在大的软件厂商的有意推动下，治理流程及架构和平台复杂、治理组织机构臃肿、对人员要求高等因素也增加了服务治理的实施难度，SOA生命周期及治理周期的复杂度双重叠加，导致落地难度直线上升。

另外，像ESB这类组件，本身就成了一个最大的“单点”，虽然可以采用“主备”模式提高可用性，但在容量扩展上依然存在瓶颈，当服务数量及调用量不断增长时，ESB往往成为最先倒下的那张多米诺骨牌。