TwitterのFinagleのようなRPCシステムとMuleのようなエンタープライズサービスバスの違いは何ですか？それぞれがどのような問題を解決するのが得意ですか？
2964 次
3 に答える
5
機能の技術的な内訳ではなく、簡単な説明としてこれに答えようとします。
Finagleは、複数のプロトコルをサポートしながら、サービスが互いに自由に接続できるようにする（アーキテクチャシステム統合標準に緊密に結び付けられていない）非同期メッセージングライブラリであると言えます。
FinagleのWebサイトから：
Finagleは、Java、Scala、または任意のJVMホスト言語で非同期リモートプロシージャコール（RPC）クライアントおよびサーバーを構築するために使用できるJVMのネットワークスタックです。Finagleは、プロトコルに依存しない豊富なツールセットを提供します。
一方、エンタープライズサービスバス（ESB）は、通常、業界標準とプロトコルに準拠する非同期メッセージングアーキテクチャです。ESBは、メッセージフローが制御され、システム間でルーティングされ、サーバーがサービスを登録し、クライアントが関心のあるメッセージを登録できるシステムを促進します。サーバーが提供するサービスは、登録およびバージョン管理できます。
通常、FinagleはWebサイトとバックエンドサービスの間のどこかで使用されています。ただし、ESBは通常、大企業内にあり、財務、サポート、販売などのシステムを統合する責任があります。
どちらのソリューションも、さまざまな拡張機能に対して非同期メッセージングとバッファリングを提供しますが、同じ問題を解決するようには設計されていません。ESBの場合、おそらく「厳密なエンタープライズ」と考えるでしょうが、Finagleの場合、おそらく「柔軟なWeb」と考えるでしょう。
お役に立てれば
アップデート：
あまり関係はありませんが、この空間を探索しているのなら、最近はカフカを見てみます。
于 2012-01-13T10:04:07.877 に答える
3
RPC と ESB は 2 つのアーキテクチャ パターンです。RPC は通常、要求と応答の同期であり、本質的に同期ですが、ESB はメッセージング (簡略化された説明) と本質的に非同期の概念に基づいて機能します。ESB は、あらゆる SOA 実装の基盤です。ESB は疎結合を可能にし、真の俊敏性を促進します。実装の観点からの単純化された例は次のとおりです。
Web サービスは典型的な RPC です。消費者は生産者と密接に結びついており、生産者側でコントラクトを変更すると、消費者側での変更が必要になります。
ESB では、サービス コンシューマーはサービス プロデューサーを直接呼び出しません。メッセージをバスに入れるだけで、ルール (メディエーター) に基づいて、適切なサービス プロデューサーがそれを処理します。サービス コンシューマとサービス プロデューサーが異なる形式で会話する場合、ESB は変換を行う機能を提供します (郵便番号を xxxxx-xxxx としてフォーマットする、名前を名と姓に分割するなど)。
これは単純化した説明です。詳細については、次のリンクを確認してください。
于 2011-09-09T06:30:24.993 に答える
2
どちらもまったく異なる問題を解決します。
- ESB は、メッセージの変換とルーティング、プロトコルの適応、およびその他の付加価値操作 (オーケストレーション、保証付き配信、べき等フィルタリングなど) を提供する仲介ミドルウェアです。サービスのコンシューマーとプロバイダーの間に位置し、透過的に (つまり、コンシューマーまたはプロバイダーを変更せずに) さまざまな機能を提供します。
- RPC システムは、RPC 操作を実行するためのクライアントおよびサーバー テクノロジを提供します。
于 2011-08-24T17:41:33.377 に答える