我阅读了很多关于集成架构从点对点到 Hub-Spoke 到 ESB 的演变的集成文献。但是对于我的一生，我一直在努力理解 Hub-Spoke 和 ESB 之间的区别。Hub and Spoke 通常被描述为如下 -
集线器作为一个大圆圈（集线器），周围有多个较小的圆圈，通过辐条连接到集线器
但同样可以重绘，就像您描述 ESB 一样，对吧？
所以我不确定为什么 ESB 和 Hub-Spoke 架构在图片中的表示方式不同，即使想法似乎相同。
让我们看一个实际的例子——
我的 Oracle Service Bus 中的代理服务从文件服务器读取 CSV 文件，将文件拆分为多行，将每一行转换为 XML，最后使用此 XML 更新 ERP，这在 Hub-Spoke 中有何不同处理？
Hub-Spoke 通常被标记为单点故障。但是在我上面的例子中，如果我的 ESB 失败了，整个过程不会崩溃吗？
我正在寻找实际示例，以展示在 Hub-Spoke 和 ESB 中如何以不同方式处理特定集成，但我阅读的书籍/文档都没有提供具体的实际示例。
严格来说架构模式——
在Hub And Spoke中，HUB 是一个智能实体，具有将特定消息路由到特定系统的所有逻辑。集线器会将消息推送给预期的收件人。
在BUS中，没有具有所有路由逻辑的中央实体。它只是一个发布消息的地方。接收者必须监视 BUS 是否有任何打算发送给自己的消息的到达，并且每当它发现这样的消息时，它必须将其从 BUS中拉出。
尽管您提到的两种描述看起来相同，但不同之处在于路由逻辑所在的位置。
我不能代表所有服务总线实现，但我会假设大多数（我在 .NET 世界中所知道的）实际上是分布式服务总线实现。我的服务总线称为 Shuttle ESB，但据我所知，NServiceBus、MassTransit 和 Rebus 都是分布式的。
一些集成引擎称自己为服务总线，使其成为难以确定的术语之一。
中心辐射式方法的问题是，通常有一个中央服务器，所有消息都通过该服务器进行路由。如果该中央机器发生故障，则该机制将发生故障。对于某些引擎，可以联合中央机器，但它仍然非常集中。如果消息的发送者没有以某种方式将传出消息排队，那么失败将更加明显。
对于分布式服务总线（例如 Shuttle ESB），每个端点构成服务总线的一部分。没有中央服务器可用于路由所有消息。每个端点将消息路由到相关的消费者。消息也可以在发送/发布时排队，这样即使接收方出现故障也不会停止发送。一旦接收者回来，处理就会继续。
尽管从逻辑上讲，如您的图像所示，这两种方法是相同的，但实际实现却大不相同。