本系列文章是希望能给大家提供一个关于ESB的总的视角。在工作中，也经常与客户交流各种技术，也经常谈到ESB。 但我发现很多客户经常被一下一些问题所困扰，这些问题包括：ESB到底是什么？能帮企业实现什么？这个技术的优势在那里？适用于什么样的场合？所以我希望整理一些关于ESB的知识给大家作参考。当然，在网络上有不少文章提到了ESB，我也摘抄了部分，如果涉及到你认为摘抄的部分涉及到你的版权，请与我联系。
什么是ESB？
ESB – 全称Enterprise Service Bus, 中文也叫企业服务总线，是SOA架构中的基础构件，作为 SOA 架构的信息传输龙骨，为各业务应用系统提供了信息的高速通道。通过ESB可以把企业内各现有业务系统通过原子交易和组合交易的方式，将跨系统之间的数据高效地整合起来，消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现不同服务之间的通信与整合。各应用系统通过服务提供方适配器、服务请求方适配器接入ESB平台，满足各业务系统之间的服务生产和消费的衔接。
ESB的发展历程 – 从EAI到ESB
从历史上看，EAI 技术是软件行业首次尝试将市场上各种不同中间件解决方案整合为单一产品套件。当各公司开始寻求在不同的自动化系统间交换信息时，对 EAI 的需求也就应运而生了。在上世纪的九十年代，企业范围内诸如客户关系管理 (CRM) 和企业资源计划 (ERP) 等业务举措是促使 EAI 系统诞生的主要驱动因素。
在 EAI 面世之前，中间件的蓝图主要是由一系列协议栈（例如 CORBA、Tuxedo 和 MQ）以及数据格式（XML、XDR、固定格式、可变格式等）构成的。这些技术中的每一项都能够在很大程度上满足企业自身的集成需要，但是这需要选定的协议和数据格式在企业中完全通用才能够实现。但实际情况却是，大中型企业的IT系统都不可避免的具有异构特点。
如上图 所示，EAI 采用了一种简单有效的方式来解决不同应用程序间的集成问题。EAI 软件创建了一个交换中心，用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外发适配程序都可以理解的通用格式，并将其称为规范格式。每个适配程序都是一个有自主权的实体软件，存在多个分别负责管理各种应用程序特定交互操作的管理层，同时还另具有一些传输层，用于管理与应用程序和交换中心的连接。
为实现 EAI 各组件间的连接，EAI交换中心会在所有的内部集成过程中都采用一个消息代理程序（如MQ, JMS等）。除了重新更改消息负载格式外，所有应用程序间的交互都要经过中间件的多次转换。但是，在这样的架构下面，一些应用程序所需的，例如事务处理和验证/授权安全等服务质量功能通常都无法实现这些转换
作为第一代产品，EAI 是成功的，它提供了一个前所未有的解决方案。但是 EAI 体系结构有其固有的局限性，因此限制了它提供企业级可持续解决方案的能力。如上图所示，集中式交换中心使得企业（或者至少是企业中的几个特定的人）可以采用中央控制的方式。但是不断地将数据编组为规范格式或转变回原有格式的代价就是造成额外的处理负担，也就是需要购买高端服务器和管理程序实现对其的管理。虽然大多数 EAI 解决方案都允许您在集群中部署多个交换中心以便获取更大的可缩放性，但这只是在某个限度内是实用，而当您添加更多专用硬件时很快就会变得非常昂贵。
相对人工编码而言，每次改变企业应用程序组合的中间件和应用程序接口时 EAI 具有明显的优势。这是一项技术上的突破，当整个行业的想法都聚焦在为支持整个企业的举措而需要大型应用程序交换数据时它将发挥最大的作用。因为这是第一代的 EAI 工具，供应商尝试使用增量的方式来处理 EAI 的缺点。但是，因为不断地添加新功能，这使得 EAI 系统变得庞大、缺乏灵活性且难于管理。从长远来看，如果要实现真正的企业集成需要一种更好的技术。
企业的这种需求催生除了下一代的集成技术 – ESB。与 EAI 一样，ESB 也是一项允许开发人员集成使用不同中间件技术创建的异类系统的技术。ESB 一方面利用了它面向服务的优势，同时还通过使用更有效、更灵活的内部体系结构进一步改进了它的上一代 EAI 产品。
了解 SOA 和 ESB 之间的关系非常重要。SOA 代表策略、惯例以及框架，这些因素使得应用程序可以提供各种功能并且可以作为服务集合供其它应用程序使用。如下图所示，服务是一种业务完整的逻辑工作单元，可以通过直接开放的文档接口从独立设计环境以编程方式进行访问。可以调用、发布和发现服务，也可以使用单一的基于标准的接口方式抽象实现。应用程序软件由以松散 1 对 1 耦合关系存在的服务和服务消费者（即客户）构成。
SOA 是软件行业为应对单一大型应用程序的管理问题产生的解决方案。正如我们想象的那样，应用程序体系结构的这一变化对于怎样才能获得最佳的应用程序集成产生了极大的影响。如图 4 所示，ESB 为服务提供者和服务消费者之间的集成提供了一个平台。在现代平台上开发的新应用程序，其本质都是面向服务的应用。但是，有一些现有的企业应用程序并没有使用 SOA 的设计理念。在此情况下，ESB 应该能够提供将这些应用程序暴露为服务的能力。这些 EAI 产品中的许多产品都是当今计算构造层中的一部分，而且还将继续用于解决集成问题，但是对于大多数情况，因为以下一些原因，大家正在转而使用最新的 ESB：
1、更智能的端点 — ESB 启用的体系结构在应用程序与外界的接口点处配置了更多的智能功能。ESB 允许每个端点使用各种标准（如 WSDL 等）以服务的形式呈现自己，因此不需要为每个应用程序编写专用接口。可以在端点（客户机和服务器）创建时将集成智能性部署在这些端点上。可以绕过规范格式而将负载直接转换为目标格式。这一方法有效的去除了 EAI 产品所固有众多复杂特性。
2、集中式与分布式 — 当 EAI 完全采用中心辐射型通信方式时，ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时，集中式的交换中心才有意义。ESB（如 IONA Artix）可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样，仍然可以用于某些需要它的体系结构中，但它们只是开发人员的一项选择，而不是供应商指定的要求。
3、无集成堆叠 — 过去，当客户需要使用 EAI 产品来解决更多问题时，各供应商就会在 EAI 中附带添加多种堆叠的专用功能。随着时间的推移，这些堆叠的集成都成为专用的语言，需要具有更高的技术水平才能使用。与此不同的是，ESB 是一个具有相对少层级的软件，您可以使用开放式标准应用其它处理层。例如，如果某个 ESB 用户希望部署某个特定的业务流程管理工具，您只需使用行业标准接口（如用于协调这些业务流程的 BPEL）就可以很轻松地将该工具集成到 ESB 中。
ESB 方法的立即见效的短期优势在于它在获得与 EAI 方法相同总体效果的同时，花费的总拥有成本更低。这一节省不但可以通过减少硬件和软件的花费来实现，而且还可以通过因使用灵活的分布式框架而节省下来的人力来实现。除此之外，还可以逐步部署 ESB 以便减少因影响原系统和迁移造成的费用。
本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。