架构设计：系统间通信（35）——被神化的ESB（下）

（接上文：《架构设计：系统间通信（34）——被神化的ESB（上）》）

2-4、ESB与版本控制

企业中的系统集成过程，存在很多非技术因素引起的变化。可能出现的情况是，某个一直能够正常使用的调用功能A，在某一天突然就不能使用了。技术团队和业务团队排查了许久才发现功能A中对某个业务系统的调用接口已经被私自更改（可能只是多传递了一个参数、或者减少了一个参数的传递）。这种情况在现实中经常出现，可能是业务部门出于私利对外屏蔽了这个接口，也可能是技术人员在改动接口时，忘记了这个接口还有外部系统进行使用。

ESB中间件提供的版本管理功能可以帮助我们解决这个问题。这里说的版本管理功能，并不是像Git那样面向整个工程的版本管理，而是细化到服务接口层面的版本管理。以下示意图向读者展示了ESB中的版本控制功能是如何工作的：

上图中，进行版本控制的关键功能就是ESB中的注册中心模块。在其中管理了各个业务系统已经向ESB总线注册的能够提供业务服务的接口定义和接口版本信息。ESB总线在进行服务编排时，只能使用已经向注册中心注册的业务接口和相应版本。

这样的机制保证了业务系统可以在新版本准备好以后，再向注册中心注册一个新的接口版本。在此之前无论业务系统的模块怎样变更，只要在注册中心注册的原有接口定义没有变化，就可以保证各个业务系统集成后的功能能够正常工作。注册中心在下线某个版本的服务时，会检测是否还有业务功能对这个服务和版本存在调用关系，如果检查发现服务依赖关系任然存在，则不允许进行下线操作。注册中心还可以在服务的新版本注册后，对现有编排逻辑中的老版本进行批量升级。

需要注意：ESB中的注册中心模块并不像协议转换功能那样，是ESB技术的必备功能。但是有注册管理中心和版本管理机制的ESB实现更能保证总线上业务功能的稳定运行。

2-5、ESB与监控

虽然在ESB定义的特性中，并没有规定监控是它的必要部分，但是由于现在的ESB中间件软件都比较庞大，且往往在企业系统集成中扮演非常重要的角色。所以大多数ESB软件都带有监控模块。这里说的监控并不是业务层面的监控，而是指非业务性指标的监控：

• 对原子服务单元的健康性进行监控：

  为了保证ESB提供的服务路由能够被正确调用，ESB中间件需要对各个业务系统提供的原子服务的可用性进行健康监控。这是为了保证在集成服务后，如果其中某一个原子服务出现问题技术团队/业务团队能够第一时间知晓这个情况，并且能立即进行解决。如果原子服务出现问题，那么很有可能代表着由这个原子服务参与各个服务编排也有可能出现问题（当然，这还要看设置的消息路由条件）。

• 对原子服务的调用情况进行监控：

  各业务系统提供的原子服务在ESB总线上被调用的次数、频度、单次执行时间、峰值访问时段等数据都可以反映这个原子服务的重要性和原子服务本身的性能指标。所以ESB的监控子系统需要对这些指标进行采集，间接帮助技术团队/业务团队对原子服务的非业务性指标进行优化。例如：增加业务系统的计算节点、扩大单个节点的硬件性能，甚至重构原子服务。

• 对集成后的新业务调用情况进行监控：

  在ESB中间件中，基于多个原子服务所构建的集成服务上，包括这个集成服务被调用的次数、这个集成服务总的单次执行时间、集成服务中哪一个原子服务是最消耗执行时间的、哪一个原子服务的执行次数是最多的，调用原子服务所采用的协议标准和消息格式，等等一系列数据指标都是监控子系统需要采集的重点数据。

• 对ESB中间件自身健康性进行监控：

  ESB中间件自身的健康指标至少需要包括：ESB每个子系统的CPU使用情况、内存使用情况、网络使用情况、线程工作情况、磁盘I/O使用情况、集群中当前活动节点（和发生故障的节点）等等。需要注意的是：对各个业务系统自身的健康状态和性能状态进行监控，并不是ESB中间件的监控子系统份内的工作，如果后者有和前者有关的功能，也只是对各个业务系统所提供的原子服务健康状态进行监控。

3、常用ESB产品

3-1、商（付）用（费）ESB产品

• IBM ESB系列产品。

IBM提供了两款纯软件的ESB产品：IBM WebSphere ESB和IBM WebSphere Message Broker（WMB）。后者是前者的升级版本（或者说是高级版本），支持更广泛的传输协议和消息格式。

（此图来源于网络）

WebSphere Message Broker产品是一个全分布式的ESB产品，它使用多个Message Broker实例分别处理不同的业务编排、消息转换工作。并且使用Message Broker Explorer和Message Broker Toolkit（基于eclipse-plugin的开发者工具）对这些Broker进行统一管理。

• Oracle ESB产品
  Oracle Service Bus (OSB)是Oracle的付费产品：

上图来源于OSB官网文档（https://docs.oracle.com/cd/E29542_01/doc.1111/e15020/introduction.htm#OSBCA117），显示了OSB的基本功能全貌。和WMB类似，OSB也是全分布式的ESB产品，并且为开发人员提供的工具也是基于eclipse-Plugin。指的注意的是OSB和WMB实现业务编排的思路是一致的：ESB基础层只提供消息转换和协议转换动作，而服务编排和路由规则则由特定的上层组件（Message Broker/Service Virtualization）进行处理，并且这些组件可以灵活部署。

不过笔者从两者的官方文档中并没有看到这两款付费的ESB产品对一些目前流行的传输协议和消息格式的支持，例如是否支持Protobuf、是否支持Netty4、是否支持Avro等等。

• 普元ESB产品

普元ESB产品是国内比较有代表性的有用自主产权的ESB产品（本人并没有打压国产其他ESB产品意思）：

上图来源于普元官方白皮书截图。普元的ESB中间件系统经过多年建设和升级，在国内商用ESB中间件中已经算是比较完整了。除了包括ESB技术必要的消息转换、消息路由、协议转换、服务编排功能外，还有众多辅助功能，如ESB Studio中提供给开发人员使用的编辑管理工具，以及独立的服务注册管理单元，还包括监控ESB中间件监控平台等子系统功能。

貌似普元ESB中间件是有社区版本的，可以供开发人员下载使用。不过功能方面肯定不如付费版本那样全面。

3-2、共（免）享（费）ESB产品

• Mule ESB

Mule ESB是集成服务提供商MuleSoft（官方网站：https://www.mulesoft.com/）的产品之一。这家公司还有很多有趣的产品，例如：Anypoint MQ。

Mule ESB主要基于JAVA语言进行构建，支持多种传输协议（File,FTP,UDP,TCP,Email,HTTP,SOAP,JMS等），并且有独立的提供给开发人员使用的工具：Mule Studio。消息格式转换方面，Mule ESB提供了很多现成的组件，使开发人员能在编排的服务内部轻松实现消息转换，当然开发人员也可以按照Mule ESB的规范自行定义消息格式转换。

（上图来源于网络）

企业集成模式（Enterprise Integration Patterns，实际上是一本书名），其中专门讨论的就是企业内部的各个业务系统如何进行集成。Mule ESB中的业务服务集成就基于EIP思想。

Mule ESB有两个版本，社区版和企业版。前者是大多数开发者使用的版本；后者是需要付费的，但是功能更强大。

• ServiceMix

  想说说Apache ServiceMix，最后想想还是算了。说到这个开源ESB中间件，说起来都是痛。如果各位读者要使用Apache ServiceMix，建议使用最新的5.6+版本。提醒一点：各位最好搞清楚OSGI的一些基本知识再使用它，免得走弯路。

• Apache Camel

Apache基金会下的一个顶级开源项目，它提供了一套消息路由规则和消息转换引擎。不过他并没有现成的消息转换组件，技术人员需要遵循Camel的定义规则自行实现消息转换（您可以实现一次消息转换然后在各个路由定义中重复使用）。Apache Camel支持领域特定语言（DSL），这里我们不需要把这个知识点铺开来讲，举一个例子就行：

// 编排的业务过程
process {
    // 入库
    procurement {
        Item_code = "12345678"
        name = "物品名称"
        numner = 12
        time = "2016-09-08 18:30:01"
    }
    // 发车
    sendCar {
        car_code = "098765"
        plate = "京AXXXXX"
        time = "2016-09-09 19:37:00"
        driver = "王老五"
    }
}

以上DSL例子使用Groovy语言进行实现，虽然物流行业的业务人员不懂编程，但是他们也可以看懂以上例子所描述的业务过程，甚至还可以进行改编。这就是领域特定语言——专门用在特定行业或领域用来进行业务规则描述的语言。Apache Camel支持业务人员使用JAVA语言在业务集成领域进行规则描述。还是不能理解吗？没关系我们下一篇文章开始会比较详细的介绍Apache Camel的使用，到时还会提到这个问题。

严格来说Apache Camel并不能算作ESB中间件服务，不过开发人员可以使用它获得完整的协议转换、消息路由和服务编排能力。然后再自行为它集成注入版本控制、服务注册、运行监控等其他能力并使用某种方式让这些服务运行起来。也就是说，我们可以使用Apache Camel自行开发一个符合我们业务要求的ESB中间件服务。

4、后文预告

通过这两篇文章，笔者并没有采用企业/产品宣讲的形式，用许多高大上的词汇向各位读者描述ESB技术。这样依赖，各位读者是否感觉到ESB技术并没有那么生涩难懂？实际上，如果用最简单的词语对ESB技术进行概括的话，那么最形象的概括就是：转换和集成。转换是指转换协议和消息格式，集成是指将原子服务按照要求有规律的进行串接。

从下篇文章开始，我们将向读者介绍Apache Camel组件。这个组件服务开发人员进行转换和集成的基本能力，但是要将它单独作为一款可用的ESB中间件进行发布使用，那还有大量的设计和开发工作需要完成。最后，我们介绍如何基于Apache Camel设计一款满足自身业务需求的ESB中间件产品。