初めに、
- REST、RPC - アーキテクチャ パターン、AMQP - ワイヤ レベル、および HTTP - TCP/IP 上で実行されるアプリケーション プロトコル
- AMQP は HTTP の場合の特定のプロトコル - 汎用プロトコルであるため、HTTP は AMQP と比較してオーバーヘッドが非常に高くなります。
- AMQP の性質は非同期であり、HTTP の性質は同期です。
- REST と RPC の両方がデータのシリアライゼーションを使用します。フォーマットはユーザー次第であり、インフラストラクチャに依存します。どこでも python を使用している場合は、python ネイティブ シリアル化を使用できると思います
pickle。これは、JSON やその他の形式よりも高速です。
- HTTP+REST と AMQP+RPC の両方が異種環境および/または分散環境で実行可能
したがって、HTTP+REST または AMQP+RPC のどちらを使用するかを選択する場合、その答えは実際にはインフラストラクチャの複雑さとリソースの使用状況に左右されます。特定の要件がなくても、両方のソリューションは正常に機能しますが、それらを透過的に切り替えることができるように抽象化することをお勧めします。
あなたのチームは HTTP には精通しているが、AMQP には精通していないと言いました。開発時間が重要な時間である場合、答えが得られます。
最小限の複雑さで HA インフラストラクチャを構築したい場合は、AMQP プロトコルが必要だと思います。
私は両方の経験があり、RESTful サービスの利点は次のとおりです。
- 彼らはウェブインターフェースにうまくマッピングされています
- 人々は彼らに精通しています
- デバッグが容易 (HTTP の汎用目的のため)
- サードパーティのサービスに簡単に API を提供できます。
AMQP ベースのソリューションの利点:
- めちゃくちゃ速い
- フレキシブル
- 費用対効果が高い（リソース使用の意味で）
REST はプロトコルではなくパラダイムですが、AMQP ベースの API に加えてサードパーティ サービスに RESTful API を提供できることに注意してください。ただし、AQMP RPC API の構築について検討する必要があります。外部のサードパーティ サービスに API を提供し、古いコードベースで実行されるインフラストラクチャの一部または AMQP サポートを追加できない場所で API へのアクセスを提供するために、この方法を実行しました。
私が正しければ、あなたの質問は、エンドユーザーに API を提供する方法ではなく、ソフトウェアのさまざまな部分間の通信をより適切に整理する方法に関するものです。
高負荷のプロジェクトがある場合、RabbitMQ は非常に優れたソフトウェアであり、さまざまなマシンで実行されるワーカーをいくつでも簡単に追加できます。また、すぐに使えるミラーリングとクラスタリングも備えています。もう 1 つ、RabbitMQ は、信頼性が高く安定したプラットフォームである Erlang OTP の上に構築されています... (bla-bla-bla)、マーケティングだけでなくエンジニアにも適しています。nginx ログが、RabbitMQ が実行されている同じパーティションのすべてのディスク領域を使用したときに、RabbitMQ で一度だけ問題が発生しました。
UPD (2018 年 5 月):
Saurabh Bhoomkarは、2012 年 6 月 7 日に Arnold Shoon によって書かれたMQ vs. HTTPの記事へのリンクを投稿しました。
私は古いファイルを調べていて、MQ に関するメモに出くわし、MQ と HTTP を使用するいくつかの理由を共有したいと思いました。
- コンシューマーが固定レートで処理する (つまり、HTTP サーバーへのフラッド [バースト] を処理できない) 場合、MQ を使用すると、サービスが他の要求をバッファリングするのではなく、サービスが停止する柔軟性が得られます。
- 時間に依存しない処理およびメッセージング交換パターン — スレッドがファイア アンド フォーゲットを実行している場合、MQ は HTTP よりもそのパターンに適しています。
- リクエストを送信し、別のスレッドでレスポンスをリッスンできるため、存続期間の長いプロセスは MQ に適しています (WS-Addressing では HTTP がこの方法で処理できますが、両方のエンドポイントでその機能をサポートする必要があることに注意してください)。
- 他のプロセスが使用できない場合でも、1 つのプロセスが作業を続行できる疎結合と、HTTP の再試行が必要な場合。
- より重要なメッセージがキューの先頭にジャンプできる優先順位付けを要求します。
- XA トランザクション – MQ は完全に XA に準拠しています – HTTP は準拠していません。
- フォールト トレランス – MQ メッセージはサーバーまたはネットワークの障害に耐えますが、HTTP はそうではありません。
- MQ はメッセージの「確実な」配信を 1 回だけ提供しますが、http は提供しません。
- MQ は、大きなメッセージに対してメッセージのセグメント化とメッセージのグループ化を行う機能を提供します。HTTP には、各トランザクションを個別に処理するため、その機能がありません。
- MQ は pub/sub インターフェイスを提供しますが、HTTP はポイントツーポイントです。
UPD (2018 年 12 月) :以下のコメントで@Kevinが気づいたように、RabbitMQ が RESTful サービスよりも優れているかどうかは疑問です。私の最初の答えは、単にスケーリングの一部であり、単一の AMQP ブローカーの容量を超えない限り、単純にワーカーを追加することに基づいていました。 HTTP ベースのサービスと AMQP ベースのサービスの両方に、インフラストラクチャ レベルでのスケーリングが非常に複雑です。
慎重に検討した後、AMQP ブローカー (RabbitMQ) の維持はどの HTTP サーバーよりも簡単であることも削除しました。元の回答は 2013 年 6 月に書かれ、それ以来多くの変更が加えられましたが、主な変更点は、両方のアプローチでより多くの洞察を得たことです。 、だから「あなたのマイレージは変わるかもしれない」と今言えることは最高です。
また、HTTP と AMQP の両方を比較することは、ある程度はオレンジと同じであることに注意してください。したがって、この回答を決定の基礎となる究極のガイダンスとして解釈しないでください。むしろ、情報源の 1 つとして、またはさらなる調査の参考としてください。特定のケースに一致する正確なソリューションを見つけるために。