AMQPのようなメッセージ指向ミドルウェアはどのドメインで役立ちますか？
MOM（メッセージ指向ミドルウェア）はどのような問題を解決しますか？スケーラビリティ？統合？
それらは通常どのドメインで使用され、どのドメインで通常使用されますnot使用されますか？
たとえば、Googleはそのようなソリューションをメインの検索エンジンに使用しているのですか、それともGMailを強化していますか？
Walmart、eBay、FedEx（かなりのJavaショップ）、buy.com（かなりのMSショップ）など）のような大きなWebサイトはどうですか？MOMはそのニーズを解決しますか？
サーバー側を制御し、同種の環境（たとえば、すべてのLinux + Java JVM）を実行している数十のAmazon EC2インスタンス）があるWebアプリケーションを作成しているとき、それは意味がありますか？クライアントはまあ、Webブラウザーですか？
サーバーと通信する必要があるデスクトップアプリには意味がありますか？
それとも、通常、何らかの方法で通信する必要があるさまざまなシステムが無数に混在している大企業向けのものだけですか？
私はそれらが何のために有用であるかについて少し混乱しています。私は、それらが適切な場所と適切でない場所の例を使用して、それらの使用法をよりよく理解できると思います。
これは素晴らしい質問です。
メッセージングの主な用途は、スケーリング、オフロード作業、統合、モニタリング、イベント処理、ルーティング、ネットワーキング、プッシュ、モビリティ、バッファリング、キューイング、タスク共有、アラート、管理、ロギング、バッチ、データ配信、pubsub、マルチキャスト、監査です。 、スケジュール、...など。基本的には、データが必要だがデータベース要求を行いたくない場合。 （キャッシングは別の、より長い話です）。
これを見るもう1つの方法は、ユーザー（人）がデータベースでトランザクションを実行することによって実行されるアクション（読み取り、書き込みを含む）を実行することを前提として構築された多くのアプリケーションに気づくことです。しかし今日、多くのアクションはユーザーが開始するものではありません。代わりに、それらはアプリケーションによって開始されます。たとえば、「購入したい本が入荷したら教えてください」などです。このクラスの問題を解決する最良の方法は、何らかのメッセージングを使用することです。ミドルウェアと呼んでも、Web Pushと呼んでも、リアルタイムのサラダドレッシングを呼んでもかまいません。それはすべてメッセージングです。
アプリケーションがイベントを開始または反応できるようにすると、アーキテクチャは疎結合コンポーネントに基づくことができるため、スケーリングがはるかに容易になります。また、メッセージングが安定したスケーラブルなサービス可能なツールに基づいている場合は、これらのコンポーネントを統合する方がはるかに簡単です。
これがお役に立てば幸いです。メッセージングに関する便利なリンクのリストを維持するようにしています ここ
これについての質問やコメントをお寄せください。私たちは簡単に見つけることができます。
特定の質問に対処するには：
それらは通常どのドメインで使用され、どのドメインで通常使用されませんか？
データベースと同様に、メッセージングシステムはいたるところに出現します。
たとえば、Googleはそのようなソリューションをメインの検索エンジンに使用しているのですか、それともGMailを強化していますか？
Googleは多くの自社開発テクノロジーを使用していますが、オープンソースの貢献と既知の使用例の多くは、メッセージングがいくつかの主要サービスの中心である（またはそうでなければならない）ことを示唆しています。
Walmart、eBay、FedEx（かなりのJavaショップ）、buy.com（かなりのMSショップ）など）のような大きなWebサイトはどうですか？MOMはそのニーズを解決しますか？
まさにその通り。
使用例としては、Webページ要求のスケーリングがあります。ユーザーがWeb要求を行うと、Webサーバーはそれをバックグラウンド処理のキューに入れます。これは、リクエストが処理されている間、Webサーバーが機能し続けることを意味します。また、主要な部分が「分離」されているため、Webサーバーはリクエストの処理方法を知る必要がなく、システムのメンテナンス、アップグレード、ロールバックがはるかに簡単になります。
したがって、いずれにせよ、Webリクエストはバックエンドサービス、または「本のタイトルの検索」、「ショッピングカートの描画」、「広告の取得」、「ユーザーアカウントの確認」などの多くのサービスによって処理されます...最後にすべて結果は別のキューに入れられ、Webサーバーによる収集とユーザー応答の準備が整います。通常、システムには約100ミリ秒のタイムアウトが含まれるため、遅延した要求はすべて破棄されます。時間間隔で処理されたものはすべてユーザーに表示されます。これが、一部の大規模なeコマースサイトに段階的に読み込まれるように見えるページがある理由の1つです。
さらに多くのユースケースがあります...
サーバー側を制御し、同種の環境（たとえば、すべてのLinux + Java JVM）を実行している数十のAmazon EC2インスタンス）があるWebアプリケーションを作成する場合、それは意味がありますか？クライアントはまあ、Webブラウザーですか？
間違いなく。未知の、または無制限の数のユーザー、サーバー側インスタンス、およびアプリケーションのレイテンシがある場合、たとえ非ブロッキングRPCのスケーラブルな基盤としても、メッセージングを使用することは理にかなっています。
サーバーと通信する必要があるデスクトップアプリには意味がありますか？
多くの場合。非常に一般的なケースの1つは、サーバーがデスクトップアプリにイベントをプッシュする場合です。たとえば、ゲームイベント、ツイート、ファイナンスの価格フィード、システムアラートなどです。
それとも、通常、何らかの方法で通信する必要のある無数の異なるシステムがうまく混在している大企業向けのものだけですか？
確かに、これらの「レガシー統合」の場合だけでなく、それらも重要です。 RabbitMQで、純粋なスケールまたはメッセージボリュームに関して私たちが持っている最大の顧客は、クラウドプロバイダーと大規模なWebアプリケーションプロバイダーです。
以前の経験から1つだけ答えます-これを見てください ミドルウェア ここで大企業で採用されています-ミドルウェアには1つの目的があります-切断されたシステムを接着する（異種の言語）を一緒に使用して、相互にやり取りし、ビジネスプロセスを合理化できます-私が経験したことのあるEnteraは、Cで記述されたプロセスを使用するUNIXボックスがメインフレームシステム（DB2、COBOL ）PowerBuilderで記述されたフロントエンドを介して（私は会社に名前を付けていません！）.
私が与えた説明から、Enteraは多くのことをホストするミドルウェアです-エンディアン形式に関係なくデータの流れをスムーズに統合し、異なる言語がミドルウェアブローカーと通信する能力（ブローカーは [〜＃〜] corba [〜＃〜] または [〜＃〜] dce [〜＃〜] プロセスと同様、リッスンする「The Open Group」に準拠）特定のポートで） [〜＃〜] idl [〜＃〜] によって指定され、プロセスがローカルであるように見えます-Microsoftの.NET FrameworkでのRemotingで使用される用語を理解している場合、あなたはマークから遠くないです！ミドルウェアは、コンパイル時にリンクされるスタブを生成し、プロセスの作成、ポートからのホスト、実行時のマルチスレッド化、および最新のフロントエンド（.NET、Javaなど）を管理します、PowerBuilderでさえ、発言できないVB6 ... ok ... VB.NET（純粋主義者向け）でさえ、特定のIPアドレスで指定されたポートへの接続を開くことで対話でき、生成されたスタブを使用して直接対話できます。
明らかに、説明した内容から、レガシーシステムに新しい命が吹き込まれ、プロセスのスケーラビリティが向上することがわかります。これの主な欠点は、数千ドルに及ぶ可能性のあるコスト要因です。メインフレームを請求/請求のバックエンド処理システムとして使用し、莫大な収益を生み出す大企業は、明らかにそのような高価な製品を購入することができます-彼らにとって、それは水のプールに数ペニーを投げ込むように見えるでしょう...ビジネスプロセスを延長し、そこに新しい命を吹き込むミドルウェアは、「レガシー」タグが付けられていることを心配することなく、ビジネスをかなりの数年先まで拡張できます。
ちなみに、私はこれを私の理学士号の論文の一部として実施しました。この商用フロントエンドをカバーする情報システム。 sourceforgeで利用可能なミドルウェアのオープンソースバージョン FreeDCE がありましたが、開発の取り組みが拒否または中止されました。
編集：@cocotwo：配管ツールだと言ったミドルウェアはまさにそれを行っています...メッセージ指向のミドルウェアは実際にはそうではありません私が想像するので、AFAIKについて聞いたのですが、プロセス（関数）は、フロントエンドのアプリケーションドメイン内でローカルに表示されているかのように呼び出して、簡単に対話できるようにする必要があります。
メッセージの使用には、ネットワーク切断が発生した場合にメッセージが安全保持領域のキューに入れられるという点で、RPC呼び出しよりも優れている場合があります。そのアスペクト内でデータキャッシングが行われ、フロントエンドを続行できるようにする場合があります。 ...これは、「特定の請求/請求書番号のステータスを更新する」場合に役立ちます-ミドルウェアを介してバックエンドへの一方向の書き込みデータ。
大企業には、技術者が24時間体制でデータフローをスムーズに提供できるように高度なシステムインフラストラクチャがあり、それを考慮に入れる必要があります。私が協力した会社には、IBMグローバルサポート契約があり、小数点以下6桁で最大稼働率99％を保証する...ホットスワップ/バランスクラスター/ミラーリングシステムを配置した場合...
RPCでは、切断が発生した場合、フロントエンドを再起動するか、切断イベントを処理する必要があります。メッセージキューミドルウェアが各メッセージをリアルタイムで処理し、結果をフロントエンドにすぐに返すかどうかは、本当に重要です...
ここに、それぞれ（メッセージキューイングとRPC関連のミドルウェア）に長所と短所があります...また、サポート、最大稼働時間、開発作業、トレーニングなどのコストを軽減する要素-これはミドルとして重要ですウェアは本当に独占的であり（「オープングループ」のレイアウト/標準に従っているにもかかわらず）、設定が複雑で、スクリプトを介して全体を接着することは複雑です。
ここで良い答えと議論。当社のコンサルティングチームには、2つの推奨される「メッセージング」ソリューションがあります。RabittMQとNXTeraは、上記のEnteraの最新バージョンである高速RPCミドルウェアです。私のパートナーと私はRabittMQを使用していくつかのソリューションを開発しました。これは、その分野で現在利用できる最高のツールです。さらに、NXTera/Enteraを製造している会社で働いています。
経験から、これらの製品はどちらも、前述のように信頼性とメンテナンスの必要性を満たしているとはっきり言えます。 RabittMQのようなメッセージングサービスが適切な選択である状況があります-パブリッシュおよびサブスクライブ、認定配信、キューイング、またはストアアンドフォワードが必要な場合です。
他の場合では、RPC（リモートプロシージャコール）は、エンタープライズまたはクラウドベースのアプリケーションのトランザクションおよび分散処理に最適かつ最速のソリューションです。 RPCを使用するのは適切ですが、SOAP/.NET（これはRPC実装です）が遅すぎる、高価である、または複雑な場合、NXTera/Enteraのような軽量の高速RPCミドルウェアが私たちにとって正しい選択です。
RPCミドルウェアとメッセージ指向ミドルウェアの間にはいくつかのユースケースのオーバーラップがあり、そこではどちらでも問題なく使用できます。しかし、どちらも強力で信頼できる選択肢です。
私が協力している大企業では、RPCとMoMの両方を併用しています。インターネット企業に関する限り、Google（プロトコルバッファー）とFacebook（スリフト）は、RPCが最新のWebおよびクラウドベースの開発で果たす役割を持っていることを示しています。