AMQPについて頭を悩ませようとしています。アプリケーション間のマシン間 (クラスター、LAN、WAN) 通信には優れているように見えますが、1 台のマシン内でソフトウェア バスとして使用するのに (アーキテクチャ上および現在の実装面で) 適しているかどうかはわかりません。
現在の高性能メッセージ パッシング フレームワークを取り出して AMQP に置き換える価値はありますか? それとも、ローカル通信と非ローカル通信の区別が曖昧になり、RPC と同じ罠に陥るのでしょうか?
また、マシン内通信に WAN テクノロジを使用することによるパフォーマンスへの影響についても心配していますが、これはアーキテクチャよりも実装上の問題かもしれません。
戦争の話は大歓迎です。
AMQPはRPCフレームワークではありません。共有キュー、RPC、pubsubなどをモデル化するためのビルディングブロックを提供しますが、特定の使用方法を義務付けるものではありません。
アプリケーションをパーティション分割して（途中で配布可能にする）、AMQPと一緒に配線したい場合は、それが適切なテクノロジーだと思います。より高速な代替手段があるかもしれませんが、おそらくAMQPほど一般的なものはありません。
AMQP は仕様であるため、リンゴとオレンジを実際に比較することになります。実際には、本番環境に対応した AMQP プロバイダーはそれほど多くありません。執筆時点では、主要なメッセージング プロバイダーやベンダーはいずれも AMQP をサポートしていません (IBM、Tibco、Sonic、BEA、Oracle、SwiftMQ、MS、Apache ActiveMQ、Sun の openmq など)。そのため、利用可能な AMQP プロバイダーはすべてかなり新しいものです。
そのため、関心のある AMQP プロバイダーをメッセージ パッシング フレームワークと比較することをお勧めします。バイトをソケットに読み書きする方法のために、正常に機能しているものを切り取っても意味がありません:)
信頼性が高く、非常に柔軟な (メッセージング パターンに関して) 基盤として、マシン内 (プロセス間) とネットワーク間の両方の多くのメッセージング シナリオで使用できます。ゼロから大規模な高帯域幅のマルチネットワーク システムまで、あらゆる方法で拡張できます。
私は現在、メッセージがどこまで移動するか、または誰/何が (理由の範囲内で) メッセージを消費するかを気にしない、小規模ではあるが比較的複雑なほぼリアルタイムのシステムについて評価しています。消費者が同じマシンに座っている場合も同様です。私はそれを試してみて、あなたがそれをどうするか見てみたい. プロトタイプ システムを組み立てたい場合は、python とPikaライブラリを使用します。
AMQP 標準は成熟しつつあり、JMS などの他のメッセージング標準を悩ませてきた厄介な問題のいくつかを解決します。既存のソリューションを置き換える価値があるかどうかという質問に対しては、場合によると思います。おそらくシステムはすでに稼働しており、本番環境で非常に高性能であるため、私は非常に懐疑的です。
次のような問題がある場合:
必要な作業を調査し、利点をより正確に分析する必要があります。すでに満足している場合、メッセージング フレームワークを置き換えても投資に見合う効果はありません。
マシン内シナリオでのパフォーマンスに主に関心がある場合、問題はAMQP（ワイヤレベルのプロトコルのみ）についてではなく、どの実装を試す必要があるかについてです。
ネットワークによってもたらされる遅延を取り除くことにより、さまざまな実装の生のパフォーマンスに対しておそらくはるかに敏感になります。したがって、QpidやZeromqなどのC++で実装された製品を見ていきます。
Qpidは、適切なハードウェア（クアッドコア）で400 000メッセージ/秒（1024バイトのメッセージ）に簡単に到達できます。Qpidはブローカーアーキテクチャ（ステップがありました）を使用しているのに対し、Zeromqはピアツーピアチャネルを持つことができるため、おそらくはるかに優れたパフォーマンスを発揮します。
AMQP は、内部で使用されるものというよりも、SOA 向けの信頼性の高いトランスポート ミドルウェアのように見えます。