139

我已经阅读了有关消息代理和 ESB 的不同问题/文章（甚至在 stackoverflow 上）。仍然不知道消息代理和 ESB 之间的明确划分区别是什么？现在我在这里尝试比较产品，Websphere Broker 和 Mule ESB！

首先，（任何版本）Webshere Broker 是 ESB 吗？我们的 IBM 产品人员声称它是 ESB！（我对此并不感到惊讶）。

我有限的信息告诉我，Message Broker 在 HUB-SPOKE 模型上工作。然而，ESB 在总线架构上工作。这到底是什么意思？我已经读过，如果 HUB 失败（我猜不可用）那么经纪人就完全失败了。这不是 ESB 的情况（所以那些人说）。我在这里不明白的是“如果 BUS”发生故障怎么办？

现在关于 ESB 和 Brokers 的常见内容是，它们提供路由、转换、编排等。因此，如果它们都提供这些，那么我为什么要选择一个而不是另一个。

另一个冲突领域是关于转型。与 Message Brokers 相比，ESB 是否以不同的方式促进它？我真的很想对此有所了解。

现在谈论水平缩放。谁胜过谁？或者它们在复杂性（或任何其他因素）方面都具有同等的可扩展性。当然，在成本方面，Webshpere Broker 会为每个盒子（更不用说每个 cpu）向您收费。我相信，即使是商业 MULE ESB 也不会这样做。撇开其中的成本部分不谈，ESB 扩展和 Message Broker 扩展的含义是什么。我碰巧知道您可以在 ESB 中扩展到服务级别。这在消息代理中可能吗？

4

7 回答 7

30

您可以使用没有服务总线的转换代理，反之亦然。就具体产品而言，我不认为任何一种产品都是纯粹的一种或另一种，因为它们相互补充的方式。有些产品在一个领域更强大，而另一些则在另一个领域更强大。也许需要根据哪个功能最能解决单个问题来做出选择。

与 ESB 产品相比，代理可能拥有更好的内置“乐高积木”来构建转换链。作为 ESB 投入使用的代理可能会在负载下被压垮并且不能很好地扩展，或者可能缺乏强大的日志和处理日志的工具。

一旦发现并修复了严重的逻辑错误，一些 ESB 允许回滚数据库更新并将队列重播到更正的应用程序中。我认为大多数经纪人都没有整合这种级别的交易支持。要在所有“交易”中发挥作用，几乎必须是业务事件（销售、续订、所有权变更等），而不是像 RPCish“数据库更新”之类的东西。

于 2009-06-25T02:53:01.337 回答
24

免责声明：我是一名 IBM 顾问，专门研究 WebSphere ESB。此评论不以任何官方身份留下。

ESB 与其说是一种产品，不如说是一种架构模式或概念——从广义上讲，一种基于服务的松散耦合工程方式。它的定义是争论不休的，并不是一成不变的。一般来说，ESB 是一组不相关的（在技术意义上）服务——它们公开接口，并从其他服务中使用它们。通常不涉及中心辐射型架构，尽管可以。

IBM 无疑将 WebSphere Message Broker 和 WebSphere ESB 都作为可以轻松构建 ESB（以及 DataPower 硬件设备）的产品进行营销。它们有不同的技术根源，但在目的上有一些重叠。此外，这并不是说您不能使用许多其他未标记为“ESB 产品”的东西来构建 ESB。

这并不能回答您的所有问题，但希望能解决 IBM 部分。

于 2009-04-22T19:16:20.060 回答
22

Message Broker 和 ESB（企业服务总线）之间的区别主要在于“总线”这个词。

对我来说，Message Broker 是一个（通常很大的）进程，它将数据从一种结构转换为另一种结构或修改内容。

ESB 是一种面向消息的中间件 (MOM) 以及其他服务，其中之一可能是Message Broker。因此，ESB 可以包含消息代理作为其组件之一。总线由多个进程组成，否则我不会称它为“总线”。总线的本质是有多个组件服务于不同的任务，每个组件都通过 MOM 进行通信并遵循某种形式的“通用数据格式”。总线将包括：向 MOM 发送数据的应用程序、数据库适配器、消息代理、MOM 桥等。

分离有点渐进，但 Message Broker 架构和 Bus 之间的最大区别在于粒度。如果您的任务是集成应用程序 A、B、..、Z 和几个数据库，您可以使用一个连接每个人的大型 Message Broker 来做到这一点。或者在 ESB 中，多个小组件只接管少量任务。例如，一个适配器连接到 A，另一个连接到 B（但他们不进行转换），然后每个适配器将他们的东西发送到一个（或多个）消息代理，每个都应该尽可能简单 - 例如不必须了解“A”或“B”的数据模型。一个好的 ESB 应该在总线上有一个通用的数据定义，从各个应用程序的“差异”中抽象出来。

转换：ESB 对转换没有帮助，除非它带有消息代理。但无论如何，每个好的 ESB 都应该包含一个 Message Broker。Message Broker 应该是您的总线转换专家，但仅此而已。

水平扩展：如果您只有 3 个要连接的东西（现在和永远），那么获得完整的 ESB 可能不值得。Message Broker 的优势在于它只是一个大进程。您可以在那里配置所有内容，并为您的所有数据映射、过滤和路由提供一个中心位置。

但是，如果您要连接 30 个应用程序，那么一个 Message Broker 可能会停止运行。当然你可以购买更多的实例，运行冗余的东西，等等，但是你应该改变你的策略来“本地化”工作。每个应用程序的适配器（每个可能是一个小的 Message Broker 实例）应该能够生成和/或接收抽象的公共数据模型（例如，具有共享 XSD 的 XML）。也可以有一个用于转换任务的中央消息代理，但该实例应该不知道数据模型 A 或 B。因此 ESB 应该将处理转移到专家组件，而不是将所有内容都放在一个中央位置。

于 2015-01-16T10:28:22.980 回答
15

几天前我刚刚读了 Udi Dahan 的这篇文章，这可能会让您更清楚地了解我认为的一个根本区别。

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

报价：

给定事件类型只能有一个发布者的规则是总线与代理的区别之一，尽管两者显然都允许您拥有多个订阅者

...

不幸的是，有许多代理式技术正在企业服务总线的旗帜下销售。虽然有些产品能够以集中式和分布式方式部署（有时称为“联合”或“嵌入式”模式），但许多产品并不强制执行“每个事件类型的单一发布端点”规则。

没有这个约束，就太容易出错了。

希望能帮助到你。

于 2011-04-04T14:34:18.313 回答
6

企业服务总线为业务提供了三个关键价值：

  1. 基于上下文或内容的交易路由；
  2. 从一个消息域或传输转换到另一个消息域或传输；
  3. 多对多服务连接。

ESB 提供服务的松散耦合，允许将服务重构为与最初设想或开发服务时完全不同的应用程序上下文，并促进应用程序的重用，而无需重新编码应用程序。WebSphere Message Broker（或现在称为 IBM Integration Bus）是企业服务总线的主要示例。有关在几行代码中带来强大功能的简单代码示例，您可以在此处查看我的帖子： http ://soabus.org/viewtopic.php?f=3&t=13 。IIB 运行时内部的基本结构称为逻辑消息树（LMT）。开发人员想要做的一切都是在 LMT 上进行某种类型的操作。ESQL 是开发人员可以用来在 LMT 上执行这些操作的最有效的语言，尽管支持许多其他语言（例如，Java、PHP、Python 等）。没有其他产品能与开发 ESB 的效率和易用性相提并论应用程序比 IBM Integration Bus 更重要，因为这些应用程序 90% 的编码是通过将节点拖放到托盘上来完成的。这样就只剩下 10% 的编码工作需要由消息流开发人员完成。顺便说一句，IBM 已经停止使用 WebSphere ESB，而且许多与 IBM Integration Bus 竞争的产品几年来都没有看到任何新的开发。可以在 soabus.org 上查看各种 ESB 产品列表。

于 2014-01-22T12:36:20.697 回答
4

我从另一个主题 ( https://stackoverflow.com/a/3346417/5816637 )中找到的 Shimon Amit 复制了这个解释，这对我来说非常有意义。

  • ESB在消息代理之上提供附加层，例如路由、转换和业务流程管理。它是应用程序之间的中介，集成了 Web 服务、REST 端点、数据库连接、电子邮件和 ftp 服务器——你可以说它。它是一个高级集成主干，可在使用不同协议的应用程序网络中协调互操作性。

  • 消息代理是一个较低级别的组件，它使您作为开发人员能够在发布者和订阅者之间中继原始消息，通常在同一系统的组件之间但并非总是如此。它用于启用异步处理以保持较低的响应时间。有些任务需要更长的时间来处理，如果它们对时间不敏感，你不希望它们拖延。相反，将消息发布到队列（作为发布者）并让订阅者选择它并“稍后”处理它。

于 2021-01-07T13:34:46.997 回答
2

IBM 从那以后更改了他们的 ESB 产品的名称，所以我不会提及名称或供应商。

ESB 允许业务信息在跨多个硬件和软件平台的不同应用程序之间流动。ESB 更像是一个中间件层，它包含应用程序连接逻辑和最小到没有业务逻辑。这允许应用程序做它最擅长的事情，而不必担心嵌入任何连接逻辑来与需要来自它的数据的其他 N 个应用程序交互。ESB 架构试图解决企业中的点对点意大利面混乱。

ESB 和 Message Broker 是彼此的同义词，但是正如上面的回复之一所强调的那样，Messages Broker 模式是更大的 ESB 域的一部分。ESB 中的字母“B”类似于计算机体系结构中的总线（硬件）。主板或计算机中的总线连接各种组件以实现计算机的功能。ESB 是一种基于软件的总线，用于连接企业中的各种服务。中心辐射型是 ESB 架构支持的模式之一。在单体世界中，每个供应商都有自己的高可用性部署架构，以确保 ESB 可用。任何 ESB 供应商的最新产品都是基于微服务的部署模型或托管在他们自己的称为 iPAAS 的云中。因此，这可确保 Bus 永远不会失败或暂时失败，并根据您选择的部署模型进行自我修复。借助基于微服务的部署或 iPAAS，ESB 现在具有自动扩展功能（水平或垂直），其功能会因所选供应商而异。

对于 ESB 提供的非常高级的功能，您可以通过以下链接 => https://en.wikipedia.org/wiki/Enterprise_service_bus

于 2019-09-20T19:23:46.977 回答