Message Broker和ESB之间的区别

我经历了关于Message Broker和ESB的不同问题/文章（即使在stackoverflow上也是如此）。仍然不是一个线索，因为Message Broker和ESB之间的CLEAR划界区别是什么？现在在这里，我正在尝试比较Websphere Broker和Mule ESB产品！

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

我的有限信息告诉我Message Broker在HUB-SPOKE模型上工作。但是，ESB在总线体系结构上工作。现在这到底意味着什么？我已经阅读过，如果HUB失败（我想不可用），则代理完全失败。ESB并非如此（这些家伙说）。我在这里不明白的是“如果总线失败”怎么办？

现在，关于ESB和Broker的通常的东西是，它们提供路由，转换，编排等。因此，如果两者都提供，那么为什么我要选择一个呢？

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

现在谈论水平缩放。谁胜过谁？或者，就复杂性（或任何其他因素）而言，它们是否具有同等的可伸缩性。当然，从成本上考虑，Webshpere Broker将为您收取每盒费用（更不用说每个CPU）了。我相信，即使是商业MULE ESB也不会这样做。除了其中的“成本”部分，ESB扩展和Message Broker扩展的含义是什么。我碰巧知道您可以扩展到ESB中的服务级别。在Message Broker中可能吗？

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

与ESB产品相比，经纪人可能具有更好的内置“乐高积木”来构建转换链。充当ESB的经纪人可能会承受重压，无法很好地扩展规模，或者可能缺少健壮的日志记录和处理日志的工具。

一旦发现并修复了严重的逻辑错误，某些ESB允许回滚数据库更新，并将队列重播到更正的应用程序中。我认为大多数经纪人都不会集成这种级别的交易支持。为了使它能够在所有“事务”中正常运行，几乎必须是业务事件（销售，续订，所有权变更等），而不是RPCish“数据库更新”之类的事情。

免责声明：我是IBM顾问，专门研究WebSphere ESB。此评论没有任何官方身份。

ESB与其说是产品，不如说是一种架构模式或概念-广义上讲，是一种基于服务的工程松散耦合方式。它的定义是争执不休的，并非一成不变。通常，ESB是一组不相关（从技术意义上来说）的服务-它们公开接口，并从其他服务中使用它们。尽管可以，但通常不涉及集线器和分支架构。

IBM当然将WebSphere Message Broker和WebSphere ESB都作为产品销售，这些产品使构建ESB（以及DataPower硬件设备）变得容易。它们具有不同的技术根源，但在目的上有一些重叠。另外，这并不是说您不能用许多其他未标记为“ ESB产品”的东西来构建ESB。

那不能回答您所有的问题，但是希望能解决IBM的问题。

Message Broker和ESB（企业服务总线）之间的区别主要是“总线”一词。

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

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

分离是渐进的，但是Message Broker体系结构和Bus之间的最大区别是粒度。如果您的任务是集成应用程序A，B，..，Z和几个数据库，则可以使用一个将每个人连接在一起的大型Message Broker来完成此任务。或者使用ESB，其中多个小型组件仅接管小任务。例如，一个适配器连接到A，另一个适配器连接到B（但他们不进行转换），然后每个适配器将其内容发送到一个（或多个）Message Broker，每个代理应该尽可能简单-例如，不要必须知道“ A”或“ B”的数据模型。一个好的ESB应该在总线上有一个通用的数据定义，从各个应用程序的“差异”中抽象出来。

转换：除非带有Message Broker，否则ESB不会帮助转换。但是无论如何，每个好的ESB都应该包括一个消息代理。Message Broker应该是您的公交专家进行转换的专家，但仅此而已。

水平缩放：如果您只有3件事要连接（现在和永远），那么获得成熟的ESB可能不值得。消息代理的优势在于只是一个大过程。您可以在那里配置所有内容，并为所有数据映射，过滤和路由提供一个中心位置。

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

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

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

报价：

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

...

不幸的是，在企业服务总线的旗帜下，有很多经纪人风格的技术正在销售。尽管某些产品具有以集中式和分布式方式（有时称为“联合”或“嵌入式”模式）进行部署的能力，但许多产品并未执行“每个事件类型的单个发布终结点”规则。

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

希望能帮助到你。

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

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

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

从那以后，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