language-agnostic - なぜメッセージベースのシステムを使用するのですか？

Question

メッセージベースのシステムを使用する動機は何ですか？

NServiceBusやMassTransitなどのサービスバスについて多くのことを見ていて、基礎となる方法論の利点は何であるか疑問に思っています。

Answer 1

メッセージベースのシステムを使用することには複数の利点があります。

1. メッセージは、アプリケーション間の明確に定義されたテクノロジーニュートラルインターフェイスを形成します。
2. アプリケーションの緩い結合を可能にします。
3. パフォーマンス、チューニング、スケーリングのための多くのオプション：
   • リクエスターとサービスプロセスを異なるハードウェアにデプロイする
   • 単一のサーバーを共有する複数のリクエスター
   • 複数のサーバーを共有する複数のリクエスター
4. さまざまなメッセージングミドルウェアは、アプリケーションとは独立して一般的なメッセージングパターンを実装します。
   • リクエスト/リプライ
   • ファイアアンドフォーゲットオフラインアップデート
   • パブリッシュ/サブスクライブ
5. ミドルウェア製品の多くは、メッセージ変換（SWIFTからSWIFTXMLなど）を処理します。
6. ミドルウェア製品の多くは、単一の大きな要求をいくつかの小さな要求に分解できます。
7. それらはほぼすべて、複数のプラットフォームをサポートしています。

ちなみに、この分野の2つのマーケットリーダーは、Websphere MQと関連製品を提供するIBMと、EnterpriseServiceBusを提供するTIBCOです。

Answer 2

メッセージベースのアーキテクチャは、時間と空間の両方で、メッセージのプロデューサーとコンシューマーを切り離します。これには多くの利点があります。

• プロデューサーとコンシューマーは異なるマシンで実行できます
• プロデューサーとコンシューマーは異なる時間に実行できます。
• プロデューサーとコンシューマーは、異なるハードウェア/ソフトウェアプラットフォームで実行できます（同じメッセージプロトコルを理解するだけで済みます）
• 複数のプロデューサー/コンシューマーを調整するのは簡単です（たとえば、Dave Markleが説明したように、複数のマシンを必要とする計算集約型のジョブの場合）
• サービスが一時的に利用できない場合の安定性の向上（たとえば、注文処理を行う場合、メッセージングシステムを使用すると、注文の「ドロップ」を回避できます）

RPCスタイルの通信を行うと（つまり、サービスの応答を待っている間にブロックすると）、これらの利点のほとんどが失われます。

Answer 3

1つのユースケースは、特定のアイテムで作業できるリソースのプールと、スケーラブルな方法で分散する必要がある作業のリストがある場合です。

私はかつて、3270のスクリーンスクレイパー（すべて遅い）の数とメインフレームの統合を行わなければならないプロジェクトがありました。一度に1つのボックスでこれらのプロセスを最大10個開くことができます。スクリーンスクレイピングと更新を行うためのアカウントが何千もあったので、作業をキューに入れました。私のマシン（約3つありました）は、メッセージキュー（MSMQ）から作業項目を取得し、画面スクレイピングを行いました。それだけです。新しいマシンを簡単に起動したり、作業の流れを中断することなく古いマシンを非アクティブ化したりできるので、それは良かったです。

Answer 4

メリットは、アプリケーションの各部分を切り離すことにあります。バスをセットアップし、アプリケーションを追加したら、他の部分に影響を与えないことを保証できる新しい部分を追加することで、アプリを簡単に拡張できます。これは、時間の経過とともにシステムに継続的に追加するための非常に優れた方法です。

例えば。このようなシステムがあり、各コマンドはGUI全体の一部として実装されます。新しい機能を追加したり、既存の機能を変更したりする場合は、新しい部分を記述してシステムに追加するだけです。呼び出されても、残りの部分には依存しません。これは、アプリを非常に簡単に拡張できることを意味します。また、ネットワーク上のノード間を通過するメッセージがあります。1台のコンピューターで何かが変更されると、他のすべてのコンピューターにメッセージが送信され、他のすべてのコンピューターが更新できるようになります。イベントごとに100の異なるメッセージがあるため、適切なメッセージに反応する新しいサービスをドロップすることでシステムを拡張できます。

メッセージパッシングアーキテクチャは通常、Webサービスと同じ機能を備えており、呼び出すことができる個別のサービスがあり、新しいサービスを簡単に追加できます。

メッセージパッシングアーキテクチャが派手な（そして高価な！）ミドルウェア製品を必要とするとは思わないでください。ただし、Windowsはメッセージパッシングアーキテクチャで実行されます。ウィンドウに渡されるすべてのWM_ *メッセージは..まあ、メッセージであり、それが最も優れていると思います。アーキテクチャの例-システムのどの部分も他の部分について知る必要はありません。ダイアログなどで好きなだけコントロールを処理できるので、システムを無限に拡張できます。

メッセージパッシングはすばらしいアーキテクチャですが、アプリケーションを緊密に結合するよりも遅くなる可能性があります。特に、スクリプトや.netアプリをすでに使用している場合は、メッセージパッシングを使用しない理由はそれほど多くありません。

Answer 5

メッセージ指向システムは、一般的に特定のクラスの統合問題に適しています。他の選択肢は、アプリケーションが通信するための共有データストア（おそらくファイルまたはDBベース）またはRPCを介して統合するアプリケーションを持つことです。

これらの統合パターンに対するメッセージングの利点は、両方のアプリケーションを同じデータストアスキーマに結合せず、アプリケーションをポイントツーポイントRPC統合シナリオに結び付けないことです（より多くのアプリケーションが関与するほど複雑になります）。

非同期通信（電子メールとオンラインチャットなど）の利点と、メッセージのルーティングと変換の可能性もあります。

Answer 6

私はC＃とRemotingを使用するシステムの開発を手伝いました。クライアント（サービスまたはGUI）は、カスタムデータを含むメッセージを送信でき、受信者は次に接続したときまたは即座にそれを受信します。次に、メッセージを処理できます（負荷分散サービスの場合はメッセージの所有権を取得します）。また、長時間実行されているプロセスが終了したときにGUIを更新するためにも使用されました。

メッセージングシステム自体には、各メッセージを処理する構成可能なパイプラインがありました。ここでは、開発したパイプラインのいくつかの例を示します。

• ストレージ（メッセージを作成/データベースに保存）
• ルーティング（メッセージを送信する必要がある場所を特定）
• セキュリティ（クライアントがそれを受け取ることを許可された場合に解決されました）
• 削除（メッセージをシステムから削除する必要がある場合に機能します。つまり、クライアントに通知し、メッセージをキャッシュから削除してDBにフラグを立てる必要があります）。
• TakeOwnership（所有されているメッセージのみを変更できるため、一度に1つのクライアントのみがメッセージの状態を変更できるようにすることを扱います）

したがって、あなたの質問に答えるなら、メッセージングシステムは、クライアントが誰であるかを知らない、または気にしないときについての情報を送信する優れた手段です。