ESB与EAI / Hub Spoke

Question

我阅读了很多集成文献，讨论了从点对点到Hub-Spoke到ESB的集成架构的演变。但对于我的生活，我很难理解Hub-Spoke和ESB之间的区别。 Hub和Spoke通常描述如下 -

Hub作为一个大圆圈（Hub），周围有多个较小的圆圈通过辐条连接到集线器

但是你可以重新描绘ESB的权利吗？

所以我不确定为什么ESB和Hub-Spoke架构在图片中的表现方式不同，即使这个想法看起来是一样的。

让我们看一个实际的例子 -

我的Oracle Service Bus中的代理服务从文件服务器读取CSV文件，将文件拆分成多行，将每行转换为XML，最后使用此XML更新ERP，如何在Hub中进行不同的处理辐条？

Hub-Spoke通常被标记为单点故障。但是在上面的例子中，如果我的ESB失败了，整个过程就会崩溃吗？

我正在寻找实际示例，说明如何在Hub-Spoke和ESB中以不同方式处理特定集成，但我阅读的书籍/文档都没有提供具体的实际示例。

Answer 1

我不能代表所有服务总线实现，但我将假设大多数（我在.NET世界中知道）实际上是分布式服务总线实现。我的服务总线叫做Shuttle ESB，但据我所知，NServiceBus，MassTransit和Rebus都是分布式的。

一些集成引擎称自己为服务总线，这使得它成为一个棘手的术语之一。

采用中心辐射的方法是通常有一个中央服务器，通过它可以路由所有消息。如果该中央机器出现故障，则该机制将失败。对于一些引擎，中央机器可以联合，但它仍然是非常重要的。如果消息的发送者不以某种方式对传出消息进行排队，则失败将更加明显。

使用Shuttle ESB等分布式服务总线，每个端点都构成了服务总线的一部分。没有中央服务器通过它来路由所有消息。每个端点将消息路由到相关的消费者。消息也可以在发送/发布时排队，以便即使接收方的失败也不会停止发送。一旦收件人回来，处理就会继续。

虽然从逻辑上讲，如图中所示，这两种方法完全相同，但实际实现却完全不同。

Answer 2

严格说明建筑模式 -

在 Hub And Spoke 中，HUB是一个智能实体，具有将特定消息路由到特定系统的所有逻辑。集线器将 推送 消息发送给目标收件人。

在 BUS 中，没有包含所有路由逻辑的中央实体。它只是一个发布消息的地方。接收方必须监控总线是否有任何消息的到达，并且每当发现这样的消息时，它必须 从 它离开总线。

虽然你提到的两个描述看起来都是一样的，但区别在于路由逻辑所处的位置。