问题
I read a lot of integration literature that talk about the evolution of integration architecture from Point-to-Point to Hub-Spoke to ESB. But for the life of me I am struggling to understand the difference between Hub-Spoke and ESB. Hub and Spoke is usually depicted as the following -
Hub as one big circle (Hub) with multiple smaller circles around connected to the hub via spokes
But the same can redrawn as you would depict an ESB right?
So I am not sure why ESB and Hub-Spoke architectures are represented differently in pictures even though the idea seems to be the same.
Let's look at a practical example -
A proxy service in my Oracle Service Bus reads a CSV file from a file server, Splits the file into multiple rows, converts each row to XML and finally updates an ERP with this XML, how is this any differently handled in Hub-Spoke?
A Hub-Spoke is typically tagged as a Single Point of Failure. But in my above example if my ESB fails wouldn't the entire process fall apart?
I am looking for practical examples that show how a specific integration is handled differently in Hub-Spoke and ESB but none of the books/documents I read provide specific practical examples.
回答1:
I cannot speak for all service bus implementations but I am going to assume most (that I know of in the .NET world) are actually distributed service bus implementations. My service bus is called Shuttle ESB but NServiceBus, MassTransit, and Rebus are all distributed as far as I am aware.
Some integration engines call themselves a service bus making it one of those tricky terms to nail down.
The thing with a hub-and-spoke approach is that there is usually a central server through which all messages are routed. If that central machine fails then the mechanism fails. With some engines the central machine can be federated but it is still very much central. If the sender of a message does not queue the outgoing message somehow then the failure is going to be more apparent.
With a distributed service bus such as Shuttle ESB each endpoint forms part of the service bus. There is no central server through which all messages are routed. Each endpoint routes messages to the relevant consumer. Messages may also be queued on send/publish so that even a failure at the recipient will not stop that sending. once the recipient comes back up the processing simply continues.
Although logically, as depicted in your images, the two approaches are identical, the actual implementation is quite different.
回答2:
Speaking strictly of the architectural patterns-
In Hub And Spoke the HUB is an intelligent entity with all the logic to route a particular message to a particular system. The Hub will Push the message to the intended recipient.
In a BUS there is no central entity with all the routing logic. It is just a place where one would publish a message. The recipient will have to monitor the BUS for the arrival of any message intended for itself and whenever it finds such a message it will have to Pull it off the BUS.
Although both depictions as you mentioned look the same, the difference is in where the routing logic lies.
来源：https://stackoverflow.com/questions/35670583/esb-vs-eai-hub-spoke