消息代理和 ESB 之间的区别

我已经阅读了关于 Message Brokers 和 ESB (甚至关于 stackoverflow)的不同问题/文章。还是不知道 MessageBroker 和 ESB 之间的明显区别是什么？现在在这里，我试图比较产品，WebSphere 经纪人和 Mule ESB! ！

首先，(任何版本) WebshereBroker 是 ESB 吗？我们的 IBM 产品人员声称它是一个 ESB！(对此我并不感到惊讶)。

我有限的信息告诉我，MessageBroker 在 HUB-SPOKE 模型上工作。但是 ESB 在总线体系结构上工作。这到底是什么意思？我曾经读过，如果 HUB 失败(我猜测是不可用的) ，那么代理将完全失败。这不是 ESB 的情况(那些家伙是这么说的)。我不明白的是“如果巴士失败了怎么办?”？

关于 ESB 和 Broker，通常的情况是，它们提供路由、转换、编配等功能。如果他们两个都提供这个，那我为什么要选择其中一个。

另一个冲突领域是关于转换的。与消息代理相比，ESB 是否以不同的方式促进了它？我真的很想知道这件事。

现在谈谈水平伸缩。谁胜过谁？或者就复杂性(或其他因素)而言，它们都是同等可扩展的。当然在成本方面，WebshpereBroker 会对每个盒子(更不用说每个 CPU)收费。我相信，即使是商业 MULESB 也不会这样做。撇开成本部分不谈，ESB 伸缩和 MessageBroker 伸缩的含义是什么。我碰巧知道您可以扩展到 ESB 中的服务级别。在消息代理中可以这样做吗？

103989 次浏览
小开

免责声明: 我是一名 IBM 顾问，专攻 WebSphereESB。本评论不以任何官方身份发表。

ESB 更多的是一种体系结构模式或概念，而不是一种产品——广义而言，它是一种基于服务的松散耦合工程方法。它的定义是争论不休，并不是一成不变的。一般来说，ESB 是一组不相关的(从技术意义上来说)服务——它们公开接口，并从其他服务中使用这些接口。通常没有一个中心和辐射架构涉及，虽然可以有。

IBM 当然将 WebSphere Message Broker 和 WebSphere ESB 作为产品进行营销，使其易于构建 ESB (以及 DataPower 硬件设备)。它们有不同的技术根源，但在目的上有一些重叠。另外，这并不是说您不能构建一个包含许多其他非“ ESB 产品”的东西的 ESB。

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

小开
最佳答案

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

与 ESB 产品相比，代理可能具有更好的用于构造转换链的内置“乐高块”。被迫作为 ESB 提供服务的代理可能会在负载下崩溃，无法很好地伸缩，或者可能缺乏处理日志的健壮日志和工具。

一些 ESB 允许回滚数据库更新，并在发现和修复逻辑中的严重错误后，将队列重播到已更正的应用程序中。我不认为大多数代理会整合那种级别的事务支持。为了在所有的“事务”中运行，这几乎必须是业务事件(销售、更新、所有权变更等) ，而不是 RPCish“数据库更新”之类的事件

小开

几天前，我刚刚读了 Udi Dahan 的这篇文章，这篇文章可能会让你更清楚地了解我所感受到的一个根本区别。

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

引用:

规则是只能有一个 给定事件的单个发布者 类型是 区分公交车和经纪人, 但显然两者都允许你这么做 有多个订阅者

...

不幸的是，有很多 经纪人风格的技术 这些产品是根据 企业服务总线的旗帜。 而有些产品具有 部署在集中的 和分布式时尚(有时 称为“联邦”或“嵌入式” 模式) ，许多都没有强制执行「单一 发布每个事件类型的端点” 规则。

如果没有这个约束，它就是公正的 太容易犯错了。

希望能有帮助。

小开

企业服务总线为业务提供三个关键值:

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

ESB 提供服务的松散耦合，允许将服务重构为与最初设想或开发服务时完全不同的应用程序上下文，并促进应用程序的重用，而不需要重新编码应用程序。WebSphereMessageBroker (或者现在称为 IBMIntegrationBus)是企业服务总线的主要示例。作为代码简单性的一个例子，你可以在这里查看我的文章: http://soabus.org/viewtopic.php?f=3&t=13。IIB 运行时内部的基本构造称为 逻辑消息树(LMT)。开发人员想要做的所有事情都是在 LMT 上进行某种类型的操作。ESQL 是开发人员在 LMT 上执行这些操作所能使用的最高效的语言，尽管还支持许多其他语言(例如，Java、 PHP、 Python 等)。没有其他产品比 IBM Integration Bus 更接近于开发 ESB 应用程序的效率和易用性，因为这些应用程序的90% 的编码是通过将节点拖放到托盘上完成的。剩下的代码只有10% 由消息流开发人员完成。顺便说一下，IBM 已经停止了 WebSphere ESB 的生产，IBM 集成总线的许多竞争产品已经有好几年没有看到任何新的开发了。可以在 soabus.org 上看到各种 ESB 产品的列表。

小开

MessageBroker 和 ESB (企业服务总线)之间的区别主要在于“总线”这个词。

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

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

这种分离是逐步进行的，但 MessageBroker 体系结构和总线之间的最大区别是 粒度。如果您的任务是集成应用程序 A，B，。.Z 和几个数据库，你可以用一个大的消息代理连接每个人。或者使用 ESB，其中多个小组件接管仅仅是小任务。例如，一个适配器连接到 A，另一个适配器连接到 B (但它们不进行转换) ，然后每个适配器将它们的内容发送到一个(或多个) Message Broker，每个都应该尽可能保持简单——例如，不必知道“ A”或“ B”的数据模型。一个好的 ESB 应该在总线上有一个公共的数据定义，从各个应用程序的“差异”中抽象出来。

转换: ESB 对转换没有帮助，除非它附带了消息代理。但无论如何，每个好的 ESB 都应该包含一个 MessageBroker。 MessageBroker 应该是您的总线的转换专家，但除此之外没有别的了。

水平扩展: 如果您只有3个要连接的东西(现在和永远) ，那么可能不值得为获得一个成熟的 ESB 而付出努力。MessageBroker 的优点是只是一个大进程。您可以在其中配置所有内容，并为所有数据映射、筛选和路由设置一个中心位置。

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

小开

从那以后，IBM 一直在更改其 ESB 产品的名称，所以我不会深入研究这些名称或供应商。

ESB 允许业务信息跨多个硬件和软件平台在不同的应用程序之间流动。ESB 更像是一个中间件层，它包含应用程序连接逻辑和最小到 NO 业务逻辑。这使得应用程序可以做它最擅长的事情，而不必担心如何与其他 N 个需要从中获取数据的应用程序交互时嵌入任何连通性逻辑。ESB 体系结构试图解决企业中的点对点混乱问题。

ESB 和 Message Broker 类似于彼此的同义词，但是上面的一个响应强调了 Messages Broker 模式是更大的 ESB 域的一部分。ESB 中的字母“ B”类似于计算机体系结构中的总线(硬件)。主板或计算机中的总线连接计算机运行所需的各种组件。ESB 是基于软件的总线，连接企业中的各种服务。中心和辐射是 ESB 体系结构支持的模式之一。在单一世界中，每个供应商都有自己的高可用性部署架构，以确保 ESB 可用。 任何 ESB 供应商最近提供的服务都是基于微服务的部署模型，或者托管在它们自己的名为 iPAAS 的云中。因此，这可以确保总线永远不会失败或暂时失败，并根据您选择的部署模型进行自愈。通过基于微服务的部署或 iPAAS，ESB 现在具有自动伸缩功能(水平或垂直) ，其特性随所选供应商的不同而变化。

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

小开

我从另一个主题(https://stackoverflow.com/a/3346417/5816637)中找到了西蒙 · 阿米特(ShimonAmit)的解释，这对我来说非常有意义。

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

  • 消息代理是一个较低级别的组件，它使您能够作为 开发人员在发布者和订阅者之间传递原始信息, 通常是在同一系统的组件之间，但并非总是如此 用于启用异步处理以保持较低的响应时间。 有些任务需要更长的时间来处理，你不想让它们持续下去 如果他们不是时间敏感的事情。相反，发布消息到一个 排队(作为发布者) ，并让订阅者拾取和处理它 “稍后”。


提交答案