为你的集成需求选择合适的 ESB

公司内外的不同应用间需要进行相互通信。企业服务总线（Enterprise Service Bus，ESB）已经被视为支持应用集成的工具。但是 ESB 是什么呢？什么时候使用集成套件（integration suite）更为合适呢？下一个项目最合适的产品是什么？本文将会讲述为什么没有银弹（silver bullet）以及为何有时 ESB 可能也是错误的选择。对于项目的成功来讲，选择合适的产品是至关重要的。

术语“企业服务总线”的定义

众多来自不同供应商的产品都包含了“企业服务总线”的名字。令人遗憾的是，这个术语并没有标准的定义。因此，这些产品提供了很多不同的特性。在使用之前，ESB 这个术语应该进行清晰地定义。在后文中，ESB 可以定义为帮助开发人员进行应用集成的软件产品，因此它会提供必要的基础设施来实现路由、转换以及其他的集成设施。按照集成的复杂性路径，ESB 通常会位于框架和套件之间，会作为应用集成的可选方案，如下图所示：

图 1：应用集成的可选方案
在定义完 ESB 这个术语后，下一小节将会讨论什么时候要考虑 ESB，以及在何时集成框架或集成套件是更好的选择。

集成框架

框架会帮助实现企业集成模式（Enterprise Integration Patterns，EIP, http://www.eaipatterns.com ），如 Splitter 或基于内容的路由（Content Based Router）, 从而能够以标准的方式进行应用集成。使用标准的 API 来集成产品可以明显地减少实现所付出的努力并且源码能够更容易被其他开发人员理解。框架可以很好地基于不同的协议和技术来集成不同的应用，像端点（endpoint）、生产者（producer）、消费者（consumer）以及 EIP 这样的理念可以用来创建集成逻辑。即便背后的支持性测试也使用了相同的理念。
框架包含了一些通用的库因此可以与任何开发环境兼容，即便是传统的文本编辑器也是可以的。
在 Java 环境中知名的框架样例是 Apache Camel 以及 Spring Integration，在.NET 中则是 NServiceBus 。
使用框架的话，开发团队要或多或少全权负责项目的成功。通常不会有商业上的支持。工具一般也只会部分可用，并且不一定适合“关键任务”（mission-critical）的部署。因此本文剩余的内容将会关注 ESB 以及对应的套件，通常来说它们是比框架更好的选择。

企业服务总线

类似于框架，ESB 也用来集成应用。ESB 在幕后会基于框架。但是，它是更为强大的产品。相对于框架来讲，除了应用集成的基本功能以外，ESB 还提供了强大的工具来支持部署、管理以及运行时的监控。另外，图形化的编辑器可以用于实现各种集成场景。集成逻辑可以使用“拖拽操作”来建模，对应的代码将会自动生成。ESB 会包含商业化的支持。
相对于单纯地使用框架，ESB 的巨大优势在于更好的工具，它会明显地降低成本和复杂性。可以在更高的抽象等级解决集成的问题。

集成套件

套件提供了 ESB 的所有特性。另外，还会包含很多其他的功能，如业务流程管理（Business Process Management，BPM）、业务活动监控（Business Activity Monitoring）、主数据管理（Master Data Management）或仓库（Repository）。如果除了单纯的集成还需要某些附加的特性，那么建议使用套件。借助一个软件栈（software stack）就能实现全部的集成。
希望你现在已经明白了框架、ESB 以及套件的区别。接下来会介绍如何选择合适的 ESB 或套件。

对比指标

注意：我们不会提供按照各种标准比较所有产品的矩阵。以笔者看来，创建一个良好且有用的矩阵几乎是不可能的，因为这些产品提供了如此之多的（通常还是不同的）功能和理念。除此之外，在 IT 世界中，所列的特性实际上每天都在发生着变化。
因此，建议你预先定义自己的需求，然后评估哪一个产品是最合适的。专有的解决方案通常是类似的，而最经常使用的开源竞争对手也提供了类似的特征。因此，在开始的时候，要考虑专有的还是开源的解决方案中，哪一个是更好的选择。
为了做出决策，你应该使用以下的指标：

• 可用性：安装的复杂性如何？需要多少工具？开发环境是否直观？
• 可维护性：如何管理产品？是否有管理服务的 GUI？
• 社区：是否有活跃的公共论坛或邮件列表？是否可以获取众多的文章、教程以及视频？是否有众多的公司支持该产品？
• 企业级 **** 支持：提供了什么样的支持选项（“营业时间”、“24/7”热线、Email 以及在线支持等）？需要的服务级别协议是否有保证？是否提供了你所首选语言的支持？
• 功能性：你所需要的所有功能是否都提供了？
• 灵活性：为了满足我的需求，是否能够自定义功能？
• 可扩展性：是否可以对产品进行扩展？产品及其接口是否基于标准构建的？
• 连接器（Connector）：对所有需要的技术，是否有适配器？对 B2B 产品，如 SAP 或 Salesforce，是否有适配器？构建自定义适配器的便利性如何？
• 成本：产品的全部成本（拥有的总成本）是什么——包括维护、所有需要的辅助产品以及连接器等？
• 许可证：所使用的许可证或定制收费模式是什么？当需求发生变化（更多的电脑、更多的 CPU 以及转移到虚拟机等等）时会怎样？升级免费吗？或者可以降级吗？成本是“可预期的”吗，甚至价格清单易于理解吗？

表 1 比较了专有的和开源的 ESB 以及套件之间的优势和劣势（绿色 = 良好，红色 = 居中，红色 = 较差）。考虑到差异，所得到的结论如下：专有的解决方案通常提供了更多的特性以及“强大”的支持。但是，存在的问题在于，“它们是真的是需要的吗？”要记住的是，它们所要付出的努力、复杂性以及成本都会随之增高。开源产品会在使用便利性、更强的灵活性、易于扩展以及低成本方面得分。

指标

专有产品

开源产品

易用性

安装很复杂（需要咨询顾问！？），“工具地狱（tool hell）”

一键点击安装（很多场景下对 Mac 也是如此），几分钟后就可以开始使用，统一的平台

可维护性与监控

强大的工具（例如，用于管理和监控）、不必分析源码，通过 GUI 进行重构

工具的强大性稍差（例如，用于管理和监控，有时候需要进一步集成其他厂商的产品），不必分析源码，通过 GUI 进行重构

社区

购买支持、论坛（但是没有真正提供帮助的社区）

基于开源的项目，以及自己的社区

企业级支持

24/7 企业级支持、按需的服务等级协议（SLA）、上千台服务器的部署

24/7 企业级支持、比专有产品支持的保障性稍差、要确认本地的咨询和支持

功能性

集成特性 + 众多其他特性（业务活动监控 Business Activity Monitoring BAM、复杂事件处理 Complex Event Processing CEP、电子设计自动化 Electronic Design Automation EDA 等等）

集成特性 + 一些其他特性

灵活性

（发出变更请求 + 长时间等待 + 支付）或者（支付巨资 + 快速得到响应）

开源，按照需求进行变化

可扩展性

自己做（很难）或者付费

基于标准，事实标准

连接器

对技术和业务产品的适配器

对技术和业务产品的适配器

成本

高（甚至非常高）

较低

许可证

复杂的报价列表、要为一切付费（升级、迁移至虚拟机、“各种名义（you-name-it））”

定制收费、包括升级、可预测的成本、可能允许降级

表 1：专有和开源产品的优势与劣势

可选的产品

在描述完专有产品和开源产品的主要不同之后，下面介绍一些相关的产品。因此，我将会给出各种可行方案的概要介绍以及简短实用的分析。
几乎每家专有集成产品的厂商都提供了包含所有功能的解决方案，如 IBM 和 Oracle。至于开源的可选方案，尤其值得一提的是 Talend 的统一平台（Unified Platform）以及 WSO2 平台，它们也提供了完备的套件。除此之外，还有一些可选方案只专注于 ESB，这方面可能最重要的开源提供者是 Mule ESB 以及 Fuse ESB。

Oracle 服务总线 /Fusion 中间件

Oracle 服务总线是 Oracle 目前的 ESB。它是 Oracle Fusion 中间件（Oracle Fusion Middleware，OFM）软件栈的一个组件，它符合本文中对集成套件的定义。其中还包含了很多其他的产品，如 SOA 套件（SOA Suite）、Coherence、复杂事件处理（Complex Event Processing）、BPEL 处理管理器（BPEL Process Manager）、企业信息服务（Enterprise Messaging Service）、服务注册中心（Service Registry）等等。
很难找到 Oracle 套件所没有提供的功能。工具非常强大和稳定。对于大多数的产品都有图形化编辑器。对于能够想到的服务等级协议都能得到服务支持。如果这些强大的功能和 SLA 真的是你需要的，那么你可以选择 Oracle。这种强大当然也是要付出一定成本的。不应低估产品的高度复杂性。另外，你还要注意许可证和支持的高昂成本以及不透明的定价模式。
OFM 是基于标准的，如 Java EE、BPEL、SOAP 以及 SCA。产品是专有的，它们来源于 Oracle 在过去的多次收购。因此，使用了不同的代码基，不同的产品通常会使用不同的开发工具。下载的总量能够迅速到达 20Gb。安装是非常耗时的，偶尔会需要几天的时间——即便只是在笔记本上的简单安装也可能如此。产品是相当重量级的。运行时的资源要求也很高。
另外，你可以将“Oracle”替换为“IBM”并将“Fusion 中间件”替换为“WebSphere”，本节所讨论的内容依然成立——值得一提的是，IBM 在其产品组合中有三个不同的 ESB：Message Broker、ESB 以及 DataPower SOA Appliances。Tobco、Microsoft 以及 SAP 在专有 ESB 和集成套件市场上也扮演着重要的角色。
因此，这一部分的结论可以这样说，专有的集成套件几乎可以提供所有需要的功能并涵盖所有的 SLA。但是，在大多数的项目中，很多功能和 SLA 并不是必需的。在这种情况下，一定也要评估一下开源的替代方案。它们中最重要的产品在接下来的小节中进行了描述。

Mule ESB

Mule ESB 是最早成功的开源 ESB 之一。它具备前面所提到的开源 ESB 的很多通用特征。这包括非常简单（“一键点击”）的安装以及直观的、基于 Eclipse 的工具。通常，开源的 ESB 是非常轻量级和可扩展的解决方案。除了开源的免费版本，还有商用的企业级版本。这会为产品提供额外的功能和支持。
对于那些还没有了解的人来说，需要提及的一点是“开源”并不意味着“免费”。开源软件的厂商必须要挣钱，因此不能免费地开发软件和提供支持。但是，对顾客来说价格会友好得多，同时也不会像专有产品那样基于晦涩难懂的价格列表。不过，开源版本可以用在任何环境（甚至是生产环境）下，并没有许可证的成本。但通常，开源版本只是用来了解的，并为稍后升级到企业级版本提供可行的证明，企业级版本会有额外的特性和支持。
正如其名字所示，Mule ESB 是纯粹的 ESB。相对于 Apache Camel 和 Spring Integration 这样的框架，其重要的优势在于能够高效实现集成场景的图形化编辑器，以及为 SAP 或 Salesforce 这样的 B2B 产品所提供的连接器。但是，在 Mule ESB 中会缺少套件的功能。为了应对这样的使用场景，ESB 必须要与其他厂商的产品联合使用。Mule ESB 的不利因素在于较小的社区、限制性的许可证模型并且可获取的源码有限。它的竞争对手在这方面有明显的优势。

Fuse ESB

Fuse ESB 类似于 Mule ESB 也是一个纯粹的 ESB，而不是套件。它基于集成环境中的事实标准如 Apache CXF 以及 Apache Camel。这样它一开始就拥有了强大的社区。它的开发环境是基于 Eclipse 的，并且非常直观。

Fuse ESB 是 FuseSource 的一部分。但是，FuseSource 最近被 Red Hat 收购了，现在它属于 JBoss 部门。Fuse ESB 包含在当前的 Roadmap 之中并将会得到持续的支持。它将会集成到 JBoss 企业级 SOA 平台（JBoss Enterprise SOA Platform）之中——就像它收购的 BPM 解决方案 Polymita 一样。到形成统一的套件还有很长的路要走，因为集成 FuseSource 和 Polymita 依然需要几个月的时间，并且 JBoss ESB、Switchyard 和 Fuse ESB 这三个 ESB 产品要合并为一个。在这方面，其他的厂商已经获得了更好的效果。

Talend ESB/ 统一平台（Unified Platform）

Talend ESB 是 Talend 套件的一部分。Talend ESB 可以独立使用，也可以与 Talend 统一平台的其他组件联合使用。所有的组件都是开源的并且可以免费得到。企业级的版本提供了更多的功能和支持。与专有产品的不同之处在于，所有的组成组件都是基于相同的代码基而且同一个工具可以用在各个地方。在不同领域如 ESB、BPM、ETL、MDM，都可以很顺畅地完成——它本身不是单独的集成项目。
Talend 套件的所有工具都是基于 Eclipse 的。使用 Eclipse 的类似“外观和体验”以及直观性依然得到了保存。Talend 为所有的产品提供了一个可视化的设计器，并使用“零编码”（zero-coding）的方式。这样就能高效地实现集成的场景。当然，你依然可以编写和集成自定义的逻辑到项目之中，例如通过 Java 类（POJO）或不同的脚本语言。
类似于 Fuse ESB，Talend ESB 也基于多个集成环境中的事实标准，如 Apache Camel、Apache CXF、Apache Karaf 以及 Apache Zookeeper。除了能够使用 Apache Camel 为 JMS、HTTP 以及 FTP 这些技术所提供的连接器以外，还有很多的 B2B 适配器是可用的，如为 Alfresco、Jasper、SAP、Salesforce 以及主机系统所提供的适配器。默认会包含所有的 500 个以上的连接器。这样所造成的结果就是 Talend 的 IDE 比其竞争对手有更高的硬件需求。你不能在太差的笔记本上安装 Talend。另外一个不足是缺失 SOA 管理功能（SOA governance feature）。这计划在下一版中进行添加。

WSO2 ESB/Platform

相对来说， WSO2 是一个不太知名的厂商。但是 WSO2 提供了完整的套件组件，包括业务流程服务器（Business Process Server）、业务规则服务器（Business Rules Server）、业务活动监控（Business Activity Monitor）以及注册表管理（Governance Registry）。完整的 WSO2 平台可以很容易地进行安装，它并且提供了轻量级的、基于 Eclipse 的开发 studio。类似于 Talend 和 FuseSource，WSO2 也将主要的开源项目纳为其组件，如 Apache Synapse（轻量级 ESB）、Axis（Web Service 实现）以及 ODE（业务流程引擎）。
除了 Talend 以外，WSO2 是唯一一个所提供的套件基于单一代码基和单一开发环境的厂商。因此，没有什么会阻碍迭代式的开发过程，例如开始的时候只有几个小的特性，然后一步步添加更多的功能。弱点在于图形化的工具。它能够支持平台上的所有组件，但是不像其竞争对手的工具那样直观。

“自己动手做”（Do it yourself）集成套件？

警告性的结论：如果联合使用多个框架和产品来构建自己的自定义集成套件，通常会遇到不必要的高昂成本并会遇到很多额外的陷阱。鉴于已经有多种方案，所以强烈不建议通过各种拼凑来创建自己的方案。如果这样做的话，需要编写“粘合代码”（glue code）、进行测试和缺陷修正，同时一旦遇到问题时，没有明确的协议。供应商通常会归咎于另一方，例如，如果你想将 ESB 与其他厂商的 BPM 方案结合在一起，当遇到问题的时候，你该找谁呢？所以，你为什么要去关注那些别人已经关注过的问题呢，而且现在已经可以获取完整的产品栈（同时也有开源的）？

结论

解决集成的问题方面并没有银弹。首先，必须要做出决策框架的功能是否足够。要注意的是，使用框架大多数的源码要自己编写，同时工具和支持都很有限。否则的话，ESB 就是更好的选择。但是，如果稍后会用到套件中的额外功能，那么最好在开始的时候就使用集成套件中的 ESB。这可以保证持续性，不会遇到联合使用多个产品的问题和额外成本。

如果要使用 ESB 或集成套件，必要要决定专有产品还是开源产品更合适。专有的解决方案提供了所有可能的特性以及强大的支持。但是，这也会导致更高的成本和更高的复杂性。与此相对的是，开源解决方案会有更低的成本、便于使用且具备灵活性。一旦这个问题解决了，就可以创建一个候选列表来详细地评估备选方案。强烈建议在做出最终决策前做出证明。确保你的团队实现了原型（从第一次安装到最终部署和监控），而不是只听从于厂商的顾问所言。将来你的团队将会独自安装产品并解决集成的问题，此时可能并没有可咨询的顾问。

本文的英文原文有很多有价值的讨论，建议读者移步一观。——译者注

关于作者

Kai Wähner是 Talend 的首席顾问。他关注于 Java EE、SOA、云计算、BPM、大数据以及企业架构管理领域。您可以通过电子邮件（kontakt@kai-waehner.de）、 Twitter（@KaiWaehner）或社交网络（LinkedIn / Xing）给他提供反馈。