AMQPは、マシン内およびマシン間のソフトウェアバスとして適していますか？

Question

AMQP を回避しようとしています。アプリケーション間のマシン間（クラスター、LAN、WAN）通信には最適ですが、1つのマシン内でソフトウェアバスとして使用するのに（アーキテクチャおよび現在の実装用語で）適切かどうかはわかりません。

AMQPに置き換えるために、現在の高性能メッセージパッシングフレームワークを引き出す価値があるか、またはこれは RPCと同じトラップは、ローカル通信と非ローカル通信の区別を曖昧にしますか？

また、マシン内通信にWANテクノロジを使用した場合のパフォーマンスへの影響についても警戒していますが、これはアーキテクチャよりも実装上の懸念事項の方が多いかもしれません。

戦争物語はありがたいです。

Answer 1

AMQPはRPCフレームワークではありません。共有キュー、RPC、pubsubなどのようなものをモデル化するためのビルディングブロックを提供しますが、それを使用する特定の方法を強制するものではありません。

アプリケーションをパーティション分割（途中で配布可能にする）し、AMQPと接続する場合は、適切なテクノロジーだと思います。ただし、より高速な代替手段があるかもしれませんが、AMQPほど一般的なものはおそらくないでしょう。

Answer 2

AMQPは仕様なので、実際にリンゴとオレンジを比較することになります。実稼働可能なAMQPプロバイダーはそれほど多くありません。執筆時点で主要なメッセージングプロバイダーまたはベンダーはどれもAMQPをサポートしていません（IBM、Tibco、Sonic、BEA、Oracle、SwiftMQ、MS、Apache ActiveMQ、Sunのopenmqなど）。利用可能なAMQPプロバイダーはすべてかなり新しいです。

したがって、興味のあるAMQPプロバイダーをメッセージパッシングフレームワークと比較することをお勧めします。 ＆amp;の読み方だけのために、うまく機能している何かを切り取る意味はありません。ソケットにバイトを書き込みます：）

Answer 3

AMQP標準は成熟しつつあり、JMSのような他のメッセージング標準を悩ませてきた毛深い問題のいくつかを解決しています。既存のソリューションを交換する価値があるかどうかという質問に、私はそれが依存すると言うでしょう。おそらくシステムは既に稼働しており、実稼働環境で非常にパフォーマンスが高いため、私は非常に懐疑的です。

次のような問題がある場合：

• 相互運用性が機能していません
• 簡単にスケールアウトできない
• パフォーマンスが十分ではありません
• 現在のメッセージングソリューションは（維持するために）高価です

必要な作業を調査し、利益をより正確に分析する必要があります。既に満足している場合、メッセージングフレームワークを交換しても投資は回収されません。

Answer 4

信頼性があり、非常に柔軟な（メッセージングパターンの観点から）の基盤として、マシン内（プロセス間）とネットワーク間の両方の多くのメッセージングシナリオに使用できます。ゼロから巨大な高帯域幅のマルチネットワークシステムまで、あらゆる規模で拡張できます。

現在、メッセージがどこまで移動するか、誰が何を（理由内で）消費しているかを気にしない、小規模ではあるが比較的複雑なリアルタイムシステムで評価しています。消費者が同じマシンに座っているなら、そうしてください。私はそれを試してみて、あなたがそれで何を作っているのか見てみましょう。プロトタイプシステムをノックする場合は、pythonと Pika ライブラリを使用します。

Answer 5

AMQPは、内部で使用されるものというよりも、SOA用の信頼性の高いトランスポートミドルウェア製品のように見えます。

Answer 6

マシン内シナリオでのパフォーマンスに主に興味がある場合、AMQP（ワイヤレベルプロトコルにすぎません）についての質問は、どの実装を試すべきかについてではありません。

ネットワークによって導入されたレイテンシを削除することにより、おそらく、さまざまな実装の生のパフォーマンスにより敏感になります。したがって、QpidやZeromqなど、C ++で実装された製品を検討します。

Qpidは、適切なハードウェア（クアッドコア）で簡単に400 000メッセージ/秒（1024バイトのメッセージ）に達することができます。 Qpidはブローカーアーキテクチャを使用していますが（ステップがありました）、Zeromqはおそらくピアツーピアチャネルを持つことができるため、はるかに優れたパフォーマンスを発揮します。