soa - ESB 対 EAI/ハブ スポーク

Question

ポイントツーポイントからハブスポーク、ESB への統合アーキテクチャの進化について説明している統合に関する文献をたくさん読みました。しかし、私の人生では、ハブスポークと ESB の違いを理解するのに苦労しています。ハブ アンド スポークは通常、次のように表されます。

スポークを介してハブに接続された複数の小さな円を持つ 1 つの大きな円 (ハブ) としてのハブ

しかし、ESB を描くのと同じように再描画できますよね?

そのため、ESB とハブスポーク アーキテクチャが、考え方は同じように見えても、なぜ図では異なって表現されているのかわかりません。

実際の例を見てみましょう -

Oracle Service Bus のプロキシ サービスは、ファイル サーバーから CSV ファイルを読み取り、ファイルを複数の行に分割し、各行を XML に変換し、最後にこの XML で ERP を更新します。これは、ハブ スポークでどのように処理されますか?

ハブ スポークは通常、単一障害点としてタグ付けされます。しかし、上記の例で ESB が失敗した場合、プロセス全体が崩壊するのではないでしょうか?

Hub-Spoke と ESB で特定の統合がどのように異なる方法で処理されるかを示す実用的な例を探していますが、私が読んだ本やドキュメントのどれも具体的な実用的な例を提供していません。

Answer 1

すべてのサービス バスの実装について説明することはできませんが、(.NET の世界で私が知っている) ほとんどが実際には分散型のサービス バスの実装であると想定しています。私のサービス バスは Shuttle ESB と呼ばれていますが、私の知る限り、NServiceBus、MassTransit、および Rebus はすべて配布されています。

一部の統合エンジンはサービス バスと自称しており、特定するのが難しい用語の 1 つになっています。

ハブ アンド スポーク アプローチの問題点は、通常、すべてのメッセージがルーティングされる中央サーバーが存在することです。その中央マシンに障害が発生すると、メカニズムが機能しなくなります。一部のエンジンでは、中央のマシンをフェデレートできますが、依然として非常に中央です。メッセージの送信者が発信メッセージを何らかの形でキューに入れていない場合、失敗はより明白になります。

Shuttle ESB などの分散サービス バスでは、各エンドポイントがサービス バスの一部を形成します。すべてのメッセージがルーティングされる中央サーバーはありません。各エンドポイントは、メッセージを関連するコンシューマーにルーティングします。メッセージは送信/発行時にキューに入れられる場合もあるため、受信側で障害が発生しても送信が停止することはありません。受信者が戻ってくると、処理はそのまま続行されます。

論理的には、画像に示されているように、2 つのアプローチは同じですが、実際の実装はまったく異なります。