什么是ESB(企业服务总线)

Posted 2023-04-26

ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。 参考技术A 有了它，才能释放SOA的最大价值。因此，ESB成为厂商在SOA(面向服务的架构)竞争中的焦点。 作为近两年软件领域最热门的词汇之一，SOA(Service Oriented Architecture，面向服务的架构)的概念以及SOA带来的好处，正在被用户逐步接受。Gartner的数据表明，到2007年，全球将有70%以上的大企业会将他们的应用转到SOA。但是目前CIO们最关心的是，如何才能真正实现基于SOA的应用? 在近一段时期，多家软件厂商如IBM、Sun、BEA、Oracle等都加大了对ESB(Enterprise Service Bus，企业服务总线)产品的投入力度，并声称自己的SOA解决方案因此而更加完善，ESB成为厂商在SOA竞争中的焦点。 ESB成为一种新的诱惑 ESB是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。 业内对ESB的定义是：它是由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。 这样的定义稍显抽象，简单地说，ESB就是试图将应用服务器上的多种逻辑层面迁移到总线以及连接点上，从而降低企业内部信息共享的成本。IBM WebSphere软件全球副总裁Sandy Carter女士介绍说，“企业服务总线是SOA中的消息框架—即消息相互交换和通信的方式，是业界标准与客户消息框架的整合。” ESB产品的共有特性包括：连接异构的MOM(Microsoft Operations Manager)、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。 ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。 从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。 在电信领域：ESB能够在全方位支持电信行业OSS(运营支撑系统)的应用整合概念，是理想的电信级应用软件承载平台。 在电力领域：ESB能够全方位支持电力行业EMS的数据整合概念，是理想的系统数据交换平台。 在金融领域：ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。 为SOA挑起大旗 对于SOA的概念，不同的软件提供商有不同的定义方式。很多用户也都是从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service;从架构设计师的角度，SOA就是一种新的设计模式，方法学;从业务分析人员的角度，SOA就是基于标准的业务应用服务。 SOA不仅是Web服务，如何让业务服务最大限度地复用才是SOA的核心价值。ESB为分散服务提供了交互、组合和治理的基础架构。有了它，才能释放SOA的最大价值。 我们可以这样来理解，ESB就是在SOA架构中实现服务间智能化集成与管理的中介。而它与SOA的关系是：ESB是逻辑上与SOA所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB是特定环境下(SOA架构中)实施EAI(enterprise application integration，企业应用集成)的方式。 IONA公司大中国区总裁薛志勇表示，采用IONA公司的ESB产品Artix作为SOA的切入点，将可以使企业以最小的投入将已有系统纳入SOA架构。 薛志勇称，目前ESB是SOA集成中最普遍采用的方法，传统的EAI和平台厂商是以“服务器”为中心、以“Hub”为形式的解决方案，这种方法虽然解决了信息孤岛问题，但投资大，见效慢，而且也不灵活。 因为ESB是传统中间件技术与XML、Web服务等技术结合的产物，对企业而言，采用ESB中间件系统作为企业级信息系统整合方案中的中枢技术，可以无须添加任何软硬件设备，就可把过去、现有和未来的IT系统整合在企业级的信息应用框架下，并且能为企业提供实时、大容量的信息通信和实时控制、管理和分配消息传递的能力。 目前，除了IONA、Tibco等专业的ESB公司外，SOA的两大领导厂商IBM和BEA也加入了ESB的阵营。 Forrester公司分析师Mike Gilpin说：“尽管人们还不十分确定如何构建出一个完整的SOA，但他们已经知道要解决集成问题，而ESB正好能帮助他们解决该问题。” 国内CIO对SOA早已听了很多。SOA的理念和他们所面临诸多挑战，SOA 的开放性和灵活性，给了CIO一个选择它的理由。然而，不菲的平台迁移成本以及缺少成功案例的佐证,都让CIO难下决心。 CIO不但要考虑必须对现有产品进行集成以支持SOA的使用场景。还必须考虑如何构建面向未来的SOA应用。ESB的出现和应用恰好为这个难题提供了一个解决之道。 甲骨文公司在去年将ESB产品内嵌在其业务流程管理产品中，今年就推出了独立的ESB产品。BEA推出了 AquaLogic Service Bus等来加强ESB的产品线。IBM在原有WBI Message Broker、WAS 6 SIBus这些集成产品之外，又推出了独立的WebSphere ESB产品。而传统的EAI厂商Tibco和WebMethods也宣布了各自的ESB产品。 BEA公司中国区技术经理刘汩春认为：“SOA的‘服务’必须是可组装编排、可快速注册发布、质量可监控、生命周期可管理的。这样SOA才能在整个 IT范围内实现服务治理和优化，从而直接推动业务的优化。而从简单的服务重用框架到SOA演进的过程中，ESB就是其中最重要的催化剂之一。” ESB的兴起让SOA的渐进之路可以走得更开放和平稳，而ESB也代表了中间件产品本身的进化方向，从应用领域而言，由于ESB是基于开放的Web服务而来，在SOA的发展过程中，ESB已经当仁不让地挑起大旗。 ESB开源之路 开源软件市场这几年的发展也早就显示出极其旺盛的生命力。Linux服务器、开源数据库、开源应用软件等产品的市场份额都已有了很大提高。开源软件已成为政府机构和企业用户节约成本的一种有效手段。 随着Java应用服务器迅速成为一种大众化商品，企业中间件也朝着开源的方向跟进。近两年，已出现了许多极其成熟的企业服务总线实施项目。 Sun在JavaOne大会上发布了自己的免费ESB。这个名为Java开放式企业服务总线的项目将放在Java.net上进行，第一个版本有望在今年夏末交付。Sun还计划把来自这个社区项目的代码包装成商用产品。 Sun的应用程序以及开发者平台的市场副总经理Joe Keller说，Open ESB将会基于Java商业集成1.0规范。还提供了使用开源代码的Java系统应用程序服务器。“这将是一个推动整个世界商业的应用程序服务器，”Keller说。 而在Sun对ESB开源前，Iona科技公司就公开了Celtix的源代码，这是采用GNU LGPL许可证的Java ESB，从而启动了ObjectWeb社区在ESB方面的工作。Iona方面声称，Celtix将支持Java商业智能(JBI)规范，该规范为跨应用集成明确规定了标准化的对象容器。 目前市场上已经有大量BEA、IBM以及Sun Microsystems等大制造商生产的ESB产品。而ObjectWeb在上星期也接收到了法国IT服务公司BULL的源代码捐赠来加速它ESB产品发展。 随着开源项目的这股趋势，这个领域的所有供应商都在观望哪个ESB会获得成功。IDC的副总裁Dennis Byron说：“拿IBM举例，如果不管什么原因ObjectWeb占据了市场！本回答被提问者采纳 参考技术B

ESB是一种IT架构方法。ESB旨在通过“总线式”基础设施将各种应用集成在一起。ESB通常位于框架和套件之间，作为执行应用集成的另一种方式。ESB是一个中间件工具，它在构成应用程序的不同连接组件之间分配任务。 它为完成一些任务奠定了基本的基础架构，例如：

实现路由选择

翻译

提供一个移动任务的总体方法

提供应用程序连接到”总线”的能力。

订阅基于结构和业务政策规则发送的消息。

其他集成能力

ESB的建立是为了简化从服务和应用程序到大型机等不同格式想要相互集成时可能出现的混乱。然而，问题是ESB究竟是如何工作的？

1.企业服务总线是一组交换机，在应用程序和/或组件之间的特定路线上直接发送消息。

2.每个企业都有特定的业务策略，决定ESB将采取哪条路径来处理这些消息。

无论是客户端还是业务流程，任何连接到ESB的系统都不会直接相互通信，因为它们通过ESB本身进行通信。本质上，ESB向潜在的客户机暴露了相同的服务接口，而连接的服务则向ESB暴露。

ESB的一个主要好处是围绕着ESB是一个单一的访问点。通过ESB连接客户和服务，公司只需要在一个单一的位置，即ESB中寻找服务。即使一个业务流程更换了服务器，只需要重新配置ESB，公司仍然可以通过ESB访问服务。

ESB还可以作为事务管理器工作，这意味着它可以协调多个服务参与的分布式事务。当许多不同的业务流程和服务需要在一个事务中一起工作时，通常需要一个配置来协调事务。然而，通过ESB，这就不再需要了，公司可以访问ESB来顺利地处理交易。

ESB还可以作为一个安全管理器，集中处理认证和授权等流程。无论应用程序中的一个业务流程是否具有认证或授权，ESB都可以调整它的设置，在它暴露给使用它的客户端的服务界面中要求这样做。

ESB 的另一种工作方式是作为服务代理，为没有暴露在标准化服务接口上的应用程序充当网关。举个例子，如果一个应用程序暴露了一个Java RMI服务，但网络的其他部分运行在.NET上，因此它不能直接调用RMI服务。通过利用ESB，公司可以很容易地在Java中实现一个可以调用RMI服务的服务代理。然后，服务代理通过ESB向.NET应用暴露出Web服务接口，如SOAP和WSDL。

企业服务总线（ESB）

思考：

1.ESB的定义到底是什么？是一款产品还是一种架构模式？

2.ESB有何实际用处？

定义ESB

对于企业服务总线（Enterprise Service Bus），目前还没有公认的定义，根据供应商和来源的不同，有很多种不同的定义，其中包含如下定义：

一种集成架构样式，支持提供者和服务用户之间通过由各种点对点连接构成的公共通信总线进行通信”

“企业用来集成应用程序环境中服务的基础架构。”

“一种架构模式，使用面向服务支持异构环境之间的互操作性。”（图 1）

图 1：ESB 架构模式分成这几个主要系统架构

ESB 用于服务虚拟化，通常管理更大的服务集且位于内联网内部。

何时使用ESB？

有没有确定何时应使用ESB实现的最佳实践，需要集成三个或更多的应用程序或服务时，可以考虑使用ESB。连接两个应用程序时，点对点集成非常简单而且更经济划算。如果要从企业无法控制的外部服务提供者获取服务，也可以考虑使用ESB。然后，可以使用ESB监视外部提供者保证的服务级别协议。可进一步将服务合同调整的影响控制到最小，因为ESB对消息进行必要更改的同时将继续提供一个稳定的接口。

 

如果使用多种不同协议（如果：http、SQAP和FTP）并将它们标准化成一个协议（如SOAP），ESB可以执行必要的协议转换。如果始终需要将服务合并成一个架构才能接收、处理和生成消息，那么使用ESB也比较合适。如果需要访问一组预定义的组件和适配器，ESB也同样使用，这将支持以标准化方式集成各种协议和原有应用程序。如果需要安全、可靠地处理消息，ESB可以简化两个异构事务性数据源之间事务性消息流的实现。

如果需要通过总线将大量数据作为大量独立消息进行发送，那么使用 ESB 可能存在一些问题。ESB 绝不应取代传统数据集成，比如 ETC 工具。将数据从一个数据库复制到另一个数据时，使用数据集成可能更高效，因为该操作只会不必要地增加 ESB 的负担。

如果需要实现长期业务流程，ESB 应支持无状态的消息流。长期运行的业务流程是有状态的，最好使用 BPEL 和/或 BPMN 实现。这些流程通常无法通过 ESB 实现，但可以通过业务流程管理系统 (BPMS) 实现。

ESB 蓝图

由于缺乏标准化，ESB 市场相当混乱。很多产品自称是 ESB，但是提供的解决方案却大相径庭，而且基于不同的架构。为了更有效地评估 ESB 产品，我们将分配给 ESB 的各种功能组织成了一个蓝图（图 2）。

图 2：企业服务总线蓝图

ESB 蓝图不包括“编排”或“流程编排”组件，因为这被视作 BPMS 类别的一部分。它们为长期运行的、有状态的业务流程提供专用的运行时环境，这些流程为此进行了优化，支持 BPMN 或 BPEL 之类的语言。ESB 应该是无状态的，并且应配置为尽可能高效地处理消息。

操作和管理模块

该模块中的以下功能组件支持可靠的企业服务总线操作和管理。统计信息与状态 提供服务的 ESB 统计信息，如错误数量、最小和最大响应时间以及处理的消息数。警报 提供一个发送警报消息的机制，可通过各种通道发送，因此也可以集成到现有监视环境中。SLA 规则 是在统计信息与状态 功能组件的信息基础上定义的规则。支持度量和监视 SLA。可以使用警报 组件通知任何 SLA 侵权。

消息跟踪 可以在 ESB 中轻松跟踪消息，应在需要时激活，以便将相关开销降至最低。消息重新传递 确保在预定义时间后自动重新发送未及时处理的消息。可以配置尝试次数以及它们之间的时间间隔。该组件主要适用于仅持续一段时间的技术错误，如临时网络中断。端点故障切换 可以指定一个备用服务提供者，在主服务提供者不可用时自动调用。

负载平衡 可以列出一个逻辑服务提供者端点的几个服务端点。它使用冗余服务实现，根据定义的策略交替调用每个请求，可以循环调用，也可根据消息优先级和负载依赖关系进行调用。

消息限制 可以定义应被发送到服务提供者的服务端点的每单元时间内的最大消息数。它通过缓冲 ESB 队列中超过阈值范围的消息来防止服务提供者在高峰时段重载。消息限制 还支持消息优先级，这样可以确保始终先处理高优先级的消息。记录与报告 支持记录消息，方便以后显示。它还提供功能审计。

配置管理 支持在操作系统上安全地调整 ESB 配置，同时始终维护配置的完整性。可在操作过程中调整和替换构件和属性。还可以保存变更历史记录，这样 ESB 服务可以随时回滚到早期状态。服务注册表 可以在 ESB 上注册和管理服务。高可用性 确保 ESB 提供的服务是故障安全的，与运行这些服务的服务器的状态无关。

错误医院 是那些经过多次重新传递尝试仍无法处理的消息的目的地，可以在这里查看、更正（如果需要的话）以及重新处理这些消息。部署 可在 ESB 上自动安装服务。特定于环境的参数（如端点 URI）通常是由该组件重写的。服务使用情况 支持记录服务使用情况并向用户收取费用。

调节模块

调节模块包含用于实现 ESB 服务消息流的功能组件。消息路由 支持根据消息的内容将消息其转发至特定服务端点。如果使用的协议或消息格式支持与消息正文无关的消息头区域，转发标准可能源于消息正文或消息头。

根据消息头进行路由可能是一个极具吸引力的选择，可提高服务性能和可扩展性，因为直接访问消息头比解析来自消息正文的路由信息更高效。这对于大型消息来说尤其重要。

消息转换 支持从一种消息格式转换为另一种适用于文本和二进制消息的格式以及 XML 格式。此外，还可以从文本（如 CSV 格式）转换为 XML，或者从 XML 转换为文本（如 CSV 格式）。XML 转换使用著名的 XSLT 标准，XSLT 支持对转换进行声明性描述，并且拥有带拖放功能的图形资源以实现创建目的。

XSLT 转换的主要缺点是，如果处理大型文档，内存使用量过高，这可能会限制解决方案的可扩展性。如果 ESB 提供支持 XML 流转换的选项（比如，通过 XQuery），那就更好了。

服务调出 可以在 ESB 中访问消息流中的其他服务，比如增强一条消息。服务可能是一个 Web 服务，但 ESB 可以如您所愿地支持直接调用 ESB 中本地安装的程序代码（如 Java 类方法）。可靠的消息传递 支持使用队列或 WS* 标准（如 WS-ReliableMessaging）可靠地传递消息。

协议转换 意味着无需任何编程工作即可从某个通信协议切换到另一个协议，比如，从 TCP/IP 切换到 HTTP。消息验证 确保消息是有效的。在 XML 中，这意味着消息包含规范定义的 XML 并对应于特定的 XML 模式或 WSDL。不过，ESB 还提供了其他验证方法，如 Schematron 或规则引擎。

消息交换模式 (MEP) 支持消息交换模式，如同步和异步请求/应答、单向调用以及发布/订阅。结果缓存 可以在缓存中保存服务调用结果，这样返回同样结果的后续调用可从缓存获得应答，无需再次调用服务。如果数据是静态的或者需要零星或少许的改动，此功能尤为适合。可大大减少像访问原有系统这样的开销可能较大的操作。

事务 支持 ESB 通过消息处理提供事务完整性。ESB 用于支持可靠消息传递 的持久队列通常作为事务数据源，因此可参与异构事务。此外，ESB 还提供了一个分布式事务管理器，可使用两阶段提交协议通过异构数据源协调分布式事务。

消息重新排序 使属于一个整体但顺序不对的消息流可以重新排序。在并行处理消息的面向消息的解决方案中，消息进入 ESB 的顺序可能会丢失。如果顺序对于服务提供者很重要，消息重新排序 可以合并到消息流中。重新排序器包含一个内部缓冲区，缓冲区对消息进行处理，直至排序完成且可发送。

直通式消息传递 可以令 ESB 高效转发 ESB 消息。如果要将 ESB 用于服务虚拟化，并且将消息从服务使用者原样转发至服务提供者，这将非常有用。在这种情况下，如果 ESB 不接触消息，只是简单地按原样传递，该功能非常适用。

安全模块

该模块使用大量组件支持传输级和消息级安全性。当服务使用者访问 ESB 中的服务时，身份验证 验证其身份，并验证针对服务提供者的 ESB 身份验证。授权 为服务提供了一个授权系统，通常可通过 XACML 对这些服务进行配置，以便分配给用户或角色。

安全调节 支持交互，通过将一个域的凭证转换成另一个域的相应凭证在安全域之外进行通信。加密/解密 支持消息内容的加密和解密。

适配器/传输模块

该模块包括的适配器可通过服务托管模块连接 ESB 提供的服务。假设 ESB 从无到有提供一组适配器，客户或第三方开发人员还可以开发其他适配器以满足具体的用户需求。

服务托管模块

该模块支持在 ESB 上直接安装和操作服务，如果 ESB 基于应用服务器，该模块通常是必需的。服务容器 提供一个或多个容器，在其中安装服务和管理生命周期。它提供可访问技术横截面功能（如事务和安全性）的服务。

组件模型 提供了一个抽象的组件模型（如 Java EJB、Java Spring Framework 或 Microsoft COM+），在此基础上创建服务。

ESB 的实际应用场景

图 3 所示的符号用于以图形化方式描述各种场景，无需参考产品或工具。这些符号来自于 [1]，根据 ESB 功能不断添加。

图 3：ESB 符号

场景 1 — 服务虚拟化

服务使用者往往更喜欢硬连接实际服务端点，特别是在 BPEL 流程中，因为使用提供的工具可轻松执行。然而，在运行时对服务器地址的改动绝对不能产生需要在服务客户端进行重新部署的改动。这个问题的一个非常好的解决 方案是使用 ESB 虚拟化端点。图 4 展示了这个场景，服务提供者提供的 Web 服务接口不再由服使用者直接使用，而是通过 ESB 来使用。ESB 可以完全按照为潜在的服务使用者提供接口那样提供接口。

图 4：使用额外的监视拦截器虚拟化服务

在 ESB 配置过程中可以轻松实现需要对端点地址进行的任何改动，因此服务使用者可以像以前一样继续运行。然而，ESB 需要能够合并到现有消息流中。服务虚拟化还支持使用扩展到服务统计信息的 ESB 监视功能，以便检查 SLA 合规性，如果不合规的话，则配置适当的操作。如果服务提供者对服务合同进行了更改但不想影响服务使用者，可以执行服务虚拟化。在这种情况下，对交换的消息 进行简单的转换即可解决此问题。

场景 2 — 服务支持

当纳入具有功能接口的服务时，通常会出现的情况是，服务使用者和服务提供者在协议级别使用不同的语言。图 5 介绍了两个服务提供者，从技术上来说它们提供的是相同的服务，一个提供的是 SQL 接口，另一个提供的是 FTP 接口。可以将企业服务总线用作协议转换器以保持接口不变，因为它提供的方法可确保使用定义的接口。

图 5：服务支持

与场景 1 类似，如果通信协议将来发生变化，ESB 可确保服务使用者或服务提供者端无需后续更改。

场景 3 — 安全的消息处理

ESB 还能支持传统集成场景，主要目的是将消息从一个系统转发到另一个系统。在图 6 所示的场景中，ESB 使用来自外部队列的消息，使用对一个 Web 服务的服务调出来丰富这些消息，然后通过数据库适配器将消息发送到目标系统。

图 6：安全的消息处理

ESB 中的处理是事务性的，意味着将消息流配置为像其他参与者一样参与分布式 XA 事务。使用队列中的消息时将启动事务，事务还包含数据库适配器执行的数据库操作。如果消息流成功完成，紧接着会提交分布式事务。

场景 4 — 服务版本控制

服务往往随着时间而改变，通常需要引入一个新的不兼容版本。在这些情况下，可以使用 ESB 执行从“旧”接口到“新”接口的转换。在图 7 所示的场景中，服务提供者引入了服务的 2.0 版本，服务使用者 B 立即安装了该版本。服务使用者 A 一直使用接口 1.0，不想切换到 2.0 版本，因为不会给业务带来任何附加值。然而，服务提供者不想让这两个版本并行运行。同时运行两个接口可能比较困难，甚至在技术上不可行，而且会导致不必要 的资源消耗。

图 7：服务版本控制

如果 ESB 通过直通式传递（类似于场景 1）直接提供 2.0 版本，情况可能比较简单。同时，在适应现有消息流的同时必须提供接口 1.0 版本，这样将不再从服务提供者处调用 1.0 版本。相反，消息是从 1.0 版本转换到 2.0，然后发送给新服务。这种转换可能相对比较复杂，具体取决于两个版本之间的差异有多大。为了提供调用 2.0 版本所需的所有信息，可能需要额外丰富 1.0 版本消息。

需要维护 ESB 中的转换和接口 1.0，直至没有服务使用者使用旧接口。之所以在 ESB 中执行这种转换而不是在服务提供者中从版本 1.0 映射到 2.0，具体原因如下：

• 映射是技术问题，与业务相关问题无关
• 不会影响外部服务提供者。
• ESB 使旧接口的使用透明。
• 当所有服务使用者都改用接口 2.0 后，无需更改服务提供者。

总结

ESB 是一个中间件解决方案，使用面向服务的模型来促进和支持异构环境之间的互操作性。没有规范准确定义了什么是 ESB 或者它应该提供什么功能。虽然 ESB 主要与“调节”和“集成”这类概念相关，但它还适合作为一个平台以类似于应用服务器的方式提供服务。ESB 代表被称作“集成”和“应用服务器”的产品类别的整合。

ESB 的一个关键特性是服务虚拟化。本文提出的 ESB 蓝图提供了各种功能的有序排列，构成了评估 ESB 产品的基础。

要点

• 企业服务总线应被视为一个架构样式或模式，而不是一款产品。
• ESB 没有定义或规范，因此也没有标准。
• ESB 可帮助实现系统间的松散耦合。
• ESB 上的服务是无状态的。长期运行的流程不属于 ESB，但是在使用 BPEL 和 BPMN 之类语言的 BPM 系统中受支持。
• “误用”ESB 来执行批处理时应小心谨慎，因为可能会对性能产生负面影响。

参考资料

[REF-1] http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html