私の仕事の分野では、誰かが MQ シリーズや MSMQ などの長所を称賛せずに 5 分間過ごすことは困難であり、バズワードのきらめきが過ぎ去った後、これらの素晴らしいデバイスのいくつかの実際の例は、現実の世界。
私が探しているのは、これらのいずれかの用途を見つけるきっかけになるもの、またはメッセージ バス/メッセージ ブローカー/メッセージ キューを評価するために使用できる何らかのメトリックを提供してくれるものです。前述のメッセージ*の違いは何ですか。
私の仕事の分野では、誰かが MQ シリーズや MSMQ などの長所を称賛せずに 5 分間過ごすことは困難であり、バズワードのきらめきが過ぎ去った後、これらの素晴らしいデバイスのいくつかの実際の例は、現実の世界。
私が探しているのは、これらのいずれかの用途を見つけるきっかけになるもの、またはメッセージ バス/メッセージ ブローカー/メッセージ キューを評価するために使用できる何らかのメトリックを提供してくれるものです。前述のメッセージ*の違いは何ですか。
特定の製品の詳細には触れませんが、一般的なメッセージ キューイング システムを使用する利点をいくつか紹介できます。
これらは通常、パブリッシャー/サブスクライバーのパターンをシミュレートするための優れたインフラストラクチャです。1 つの実行可能ファイルや 1 台のマシンにさえ制限されない大規模なイベント システムを考えてみてください。これらのキューに情報を入れて、リッスンしているアプリケーションがデータを取得できるようにします。
ほとんどのメッセージ キューイング システムでは、永続的なキューを使用できます。典型的なイベント システムを考えてみましょう。イベントの発生時にリスナーが切断されているか、または応答していない場合、イベントは見逃されます。永続メッセージ キューを使用すると、メッセージはリスナーが再接続されるまでキューに残ります。この方法でデータやイベントが失われることはありません。
あなたがリストした製品については知りませんが、JMS を使用すると、メッセージがキューから取り出されるときにスレッド化をきめ細かく制御できることはわかっています。理論的には、キューごとに 1 つのスレッドを作成し、そのスレッドでアクションを実行し、メッセージが取り出されたときにそれを処理することができます。または、共有スレッド内で、複数のキューからメッセージをプルしてそれらに対してアクションを実行することもできます。
MQ Series については、パートナー企業から (Microsoft ショップに) 押し付けられたこともあり、非常に苦い経験がありましたが、MQ Series (または任意のメッセージング システム) の使用は、アプリケーションにとって不可欠な部分でした。 .
基本的に、私たちはバックオーダーアイテムのサプライチェーンフルフィルメントを処理するプロセスを構築していました. 私たちのパートナーであるディストリビューターは、顧客が望むアイテムを持っていない場合、B2B サイトにメッセージを送信し、注文を処理できる潜在的な企業をターゲットにします。
私たちは 2 つの異なるフレーバーの統合を構築しました。1 つ目は、一定の間隔で固定幅のファイルを送受信する ftp アプローチで、データを見逃さないようにするためのあらゆる種類のルールを追加しました。
2 つ目は MQ Series を使用しており、メッセージは保証付き配信を使用してキューに入れられました。次に、キューをポップしてメッセージを処理します。キューイング システムは、重要なメッセージを送信するための信頼できる方法を可能にし、実際のお金が移動する結果となったので、ここでは大きな利点でした。
逆に、同じ MQ シリーズでは、情報を取得するために同期クエリを実装する必要がありました。Web 経由でこれにアクセスするユーザーは情報を取得するのを待つため、同期させたいと考えました。MQ シリーズでこれを行うことは、非常に興味深く、苦痛を伴う挑戦でした。ここで MQ が使用された唯一の理由は、それが既存の通信回線であり、クエリ機能が既に存在していたからです。
今回は MSMQ を使用した 2 番目の例は、クライアント アプリケーションに挿入されたダイヤルホーム コードから情報を収集するサイトでした。dialhome コードは、Microsoft の SQM プログラムのような機能の使用統計を収集します。メッセージが Web サービスに到着すると、メッセージをキューにドロップします。その後、任意の数のアプリケーション サーバーでメッセージをポップし、データベースにプッシュして、ウェアハウスにロールインすることができます。
ここで MSMQ を使用すると、メッセージをキューにすばやく配置することで、メッセージのバーストを確実に処理できます。これにより、システムのスケーラビリティと信頼性が向上します。
優れたキューイング システムは、複数のスレッド、プロセッサ、マシン (さらには組織) にわたる分散コンピューティングをより簡単に実行できるようにします。
少し前 (10 年前)、私はメッセージ送信メタファーを使用して、インターディーラー ブローカーのフロント オフィス オプション価格設定システムを実装しました。C++、VB6、Excel/VBA でサービスを実装し (Excel ソルバーを使用することさえあります!!)、フラット ファイルと SQL としてのデータ ストレージ、Excel と VB6 で記述されたエンド ユーザー アプリケーション、複雑なデータ モデル (市場データ、利回りカーブとボリューム サーフェス)。非同期メッセージング (永続的/信頼できるメッセージと pub/sub を使用) により、すべてが非常に効果的かつスケーラブルに機能しました。リモート サイトにアクセスすることなく、東京とニューヨークのオフィスをロンドンのインフラストラクチャに追加することができました。
私は大ファンですが、ここ 10 年ほど彼らがここまで来ていないことに驚いています。
実際のプロジェクトからの1つの非常に「要件に近い」例。数年から走っている人。ActiveMQの場合
1)海運市場の貿易センター。
運送会社には、リアルタイムで発送できるパケット数を把握しているシステムがあります。
すべてのシステムは異なります(例:言語、デザインなど)
各社用のアダプター「ActiveMQへの非常に特別なITシステム」を作成しました
各アダプタには簡単な作業があります。会社に空き容量があるときに、どのような価格で投稿するかです。(「輸送提案」)
私たちは、すべての「輸送提案」を集めて、それらをうまく表示するクライアントを作成しました。
=>タダ。お互いに話をしたくない会社のために、クロスプラットフォーム/言語/プロセスシステムがあります
=> Ta-da 2:新しい会社があなたの貿易システムに参入したい場合、彼らはアダプターを書くだけで済みます。