我在Message Brokers和ESB上经历了不同的问题/文章（甚至在stackoverflow上）。仍然不是一个线索，因为消息代理和ESB之间的CLEAR划分区别是什么？现在我在这里尝试比较产品，Websphere Broker和Mule ESB !!
首先，（任何版本）Webshere Broker是ESB吗？我们的IBM产品人员声称它是ESB！（我并不感到惊讶）。
我的有限信息告诉我，Message Broker适用于HUB-SPOKE模型。然而，ESB适用于总线架构。那究竟是什么意思呢？我读过如果HUB失败（我猜不到）那么经纪人就完全失败了。这不是ESB的情况（所以那些人说）。我在这里不明白的是“如果BUS失败了怎么办？”
现在关于ESB和Brokers的常见问题是，它们提供路由，转换，编排等。所以如果它们都提供了这个，那么为什么我会选择一个而不是另一个。
另一个冲突领域是转型。与Message Brokers相比，ESB是否以不同的方式为其提供便利？我真的很喜欢这方面的一些见解。
现在谈论HORIZONTAL缩放。谁比谁更优秀？或者它们在复杂性（或任何其他因素）方面都具有相同的可扩展性。当然，Webshpere Broker会为每个盒子收取费用（更不用说每个cpu）了。我相信，即使是商业上的MULE ESB也不会这样做。暂且不说它的Cost部分，ESB扩展和Message Broker扩展的含义是什么。我碰巧知道您可以扩展到ESB中的服务级别。这是否可以在Message Broker中使用？
答案 0 :(得分：24)
您可以使用不带服务总线的转换代理，反之亦然。就具体产品而言，我认为任何一个都不是纯粹的一个或另一个，因为每个产品都是对另一个产品的补充方式。有些产品在一个区域更强，另一个在另一个区域更强。也许需要根据哪个函数最好地涵盖个别问题来做出选择。
经纪人可能有更好的内置“乐高积木”来构建转型链而不是ESB产品。作为ESB服务的经纪人可能会在负载下被压垮而且规模不大，或者可能缺乏强大的日记和处理期刊的工具。
一旦发现并修复了逻辑中的一个严重错误，某些ESB允许回滚数据库更新并将队列重播到已更正的应用程序中。我不认为大多数经纪人整合了这种级别的交易支持。为了在所有“交易”中工作，几乎必须是商业活动（销售，续订，所有权变更等），而不是像RPCish“数据库更新”。
答案 1 :(得分：21)
免责声明：我是IBM顾问，专门研究WebSphere ESB。此评论不以任何官方身份保留。
ESB更像是一种架构模式或概念而非产品 - 广泛地说，是一种基于服务的松散耦合工程方式。它的定义是争吵而不是完全一成不变的。通常，ESB是一组不相关的（在技术意义上）服务 - 它们公开接口，并且它们从其他服务中消费它们。通常没有涉及中心和辐射架构，尽管可以。
IBM确实将WebSphere Message Broker和WebSphere ESB作为产品推向市场，以便轻松构建ESB（以及DataPower硬件设备）。它们有不同的技术根源，但在目的上有一些重叠。此外，这并不是说你不能用很多其他没有被称为'ESB产品'的东西建立一个ESB。
这并不能解答您的所有问题，但希望能够解决IBM的问题。
答案 2 :(得分：17)
Message Broker和ESB之间的区别主要是“bus＆＃39;”这个词。
对我来说，Message Broker是一个（通常很大的）进程，它将数据从一个结构转换为另一个结构或修改内容。
ESB是面向消息的中间件（MOM）以及其他服务，其中一个可能是一个Message Broker。因此，ESB可以包含Message Broker作为其组件之一。总线由多个进程组成，否则我不会将其称为总线＆＃39;。总线的本质是有多个组件服务于不同的任务，每个组件通过MOM进行通信并遵守某种形式的“通用数据格式”。总线包括：将数据发送到MOM的应用程序，数据库适配器，消息代理，MOM桥等。
分离有点渐进，但Message Broker体系结构和总线之间的最大区别在于粒度。如果您的任务是集成应用程序A，B，..，Z和几个数据库，您可以使用一个连接每个人的大型Message Broker来完成此任务。或者使用ESB，其中多个小组件只接管很少的任务。例如，一个适配器连接到A，另一个适配器连接到B（但它们不进行转换），然后每个适配器将它们的内容发送给一个（或多个）Message Broker，每个Message Broker都应尽可能简单 - 例如不必了解＆＃39; A＆＃39;的数据模型。或者＆＃39; B＆＃39;。一个好的ESB应该在总线上有一个共同的数据定义，从“不同性”中抽象出来。个人申请。
转换：ESB对转换没有帮助，除非它带有Message Broker。但无论如何，每个好的ESB都应该包含一个Message Broker。 消息代理应该是您的公交车转换专家，但没有别的。
HORIZONTAL缩放：如果你只有三件事要连接（现在和永远），它可能不值得努力获得一个成熟的ESB。 Message Broker的优势在于它只是一个大流程。您可以在其中配置所有内容，并为所有数据映射，过滤和路由提供中心位置。
但如果您有30个连接应用程序，一个Message Broker可能会停止运行。当然，您可以购买更多实例，运行冗余等等，但您应该将策略更改为“本地化”。工作。每个应用程序的适配器（可以是一个小的Message Broker实例）应该能够生成和/或接收抽象的公共数据模型（例如，具有共享XSD的XML）。可能还有一个用于转换任务的中央Message Broker，但该实例应该不知道数据模型A或B.因此，ESB应该将处理移动到专家组件，而不是将所有内容保存在中心位置。
答案 3 :(得分：14)
我几天前刚读过Udi Dahan的这篇文章，这可能会让你更清楚地看到我认为的一个根本区别。
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
引用：
只能有一个规则 特定事件的单一发布者 类型是其中之一 将公交车与经纪人区分开来， 虽然两者显然都允许你这样做 有多个订阅者
...
不幸的是，有很多 经纪人式的技术 正在销售的 企业服务总线的旗帜。 虽然有些产品有能力 要集中部署 和分布式的时尚（有时候 称为“联合”或“嵌入式” 模式），许多不强制执行“单一 每个事件类型发布端点“ 规则。
没有这个约束，它就是 太容易犯错误。
希望它有所帮助。
答案 4 :(得分：5)
企业服务总线为业务提供三个关键值：
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％的编码由Message Flow开发人员完成。顺便说一句，IBM已经停止使用WebSphere ESB，并且许多与IBM Integration Bus竞争的产品已经好几年没有看到它们的任何新开发。可以在soabus.org上看到各种ESB产品列表。
答案 5 :(得分：3)
我从 Shimon Amit 那里复制了在另一个主题 (https://stackoverflow.com/a/3346417/5816637) 中找到的解释，这对我来说很有意义。
ESB 在消息代理之上提供附加层，例如 路由、转换和业务流程管理。它是一个 应用程序之间的中介，集成 Web 服务，REST 端点、数据库连接、电子邮件和 ftp 服务器 - 随便你说。 它是一个高级集成主干，用于编排 应用程序网络内的互操作性 不同的协议。
消息代理是一个较低级别的组件，它使您能够 开发人员在发布者和订阅者之间中继原始消息， 通常在同一系统的组件之间，但并非总是如此。这是 用于启用异步处理以保持较低的响应时间。 有些任务需要更长的时间来处理，你不希望它们被搁置 如果它们对时间不敏感，则可以解决问题。相反，将消息发布到 排队（作为发布者）并让订阅者拿起并处理 它“稍后”。
答案 6 :(得分：1)
此后，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