サービス指向アーキテクチャ-AMQPまたはHTTP
少しの背景。
非常に大きなモノリシックDjangoアプリケーション。すべてのコンポーネントは同じデータベースを使用します。残りの部分に影響を与えずにシステムの一部を個別にアップグレードできるように、サービスを分離する必要があります。
RabbitMQをCeleryのブローカーとして使用します。
現在、2つのオプションがあります。
- RESTインターフェイスを使用するHTTPサービス。
- AMQPからイベントループサービスへのJSONRPC
私のチームはHTTPに傾いていますが、それは彼らがよく知っていることですが、AMQPよりもRPCを使用する利点ははるかに大きいと思います。
AMQPは、メッセージ配信を保証し、負荷分散と高可用性を簡単に追加する機能を提供します。
HTTPでは、RESTインターフェイスで動作するクライアントHTTPラッパーを作成する必要がありますが、HAなどを使用するには、ロードバランサーを配置し、そのインフラストラクチャを設定する必要があります。
AMQPを使用すると、サービスの別のインスタンスを生成するだけで、他のインスタンスおよびbam、HA、負荷分散と同じキューに接続します。
AMQPについての考えで何かが足りませんか？
最初は、
- 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サービスの利点は次のとおりです。
- それらはWebインターフェースにうまくマッピングされています
- 人々はそれらに精通している
- デバッグが簡単（HTTPの一般的な目的のため）
- サードパーティのサービスに簡単にAPIを提供します。
AMQPベースのソリューションの利点：
- 速い
- フレキシブル
- 費用対効果の高い（リソース使用量の意味で）
RESTはプロトコルではなくパラダイムですが、AQMP RPCを構築することを検討する必要がありますが、AMQPベースのAPIの上でサードパーティサービスにRESTful APIを提供できます。 api。外部のサードパーティサービスにAPIを提供し、古いコードベースで実行されるインフラストラクチャの部分や、AMQPサポートを追加できない部分でAPIへのアクセスを提供するために、この方法で行いました。
あなたの質問は、エンドユーザーにAPIを提供する方法ではなく、ソフトウェアのさまざまな部分間の通信をより適切に整理する方法についてです。
高負荷のプロジェクトがある場合、RabbitMQは非常に優れたソフトウェアであり、異なるマシンで実行する任意の数のワーカーを簡単に追加できます。また、すぐに使用できるミラーリングとクラスタリングがあります。そしてもう1つ、RabbitMQは、信頼性が高く安定したプラットフォームであるErlang OTPの上に構築されています...（bla-bla-bla）、マーケティングだけでなくエンジニアにとっても優れています。 RabbitMQが実行されているのと同じパーティションでnginxログがすべてのディスク領域を使用したときに、RabbitMQで1回だけ問題が発生しました。
UPD（2018年5月）：Saurabh BhoomkarMQ vs. HTTP 記事へのリンクを投稿しました2012年6月7日にアーノルドショーンによって書かれた、それのコピーです：
私は古いファイルを調べていて、MQに関するメモに出会い、MQ対HTTPを使用するいくつかの理由を共有すると思いました。
- コンシューマーが固定レートで処理する（つまり、HTTPサーバーへのフラッドを処理できない[バースト]）場合、MQを使用すると、サービスが他の要求をバッファリングするか、それを停止する柔軟性が提供されます。
- 時間に依存しない処理およびメッセージング交換パターン—スレッドがファイアアンドフォーゲットを実行している場合、MQはHTTPよりもそのパターンにより適しています。
- リクエストを送信し、応答をリッスンする個別のスレッドを持つことができるため、MQに適した長時間のプロセス（WS-AddressingはHTTPをこの方法で処理できますが、両方のエンドポイントがその機能をサポートする必要があります）.
- HTTPが再試行を必要とするのに対して、他のプロセスが使用できない場合でも、1つのプロセスが動作を継続できる疎結合。
- より重要なメッセージがキューの先頭にジャンプできる優先順位付けを要求します。
- XAトランザクション– MQは完全にXAに準拠しています– HTTPはそうではありません。
- フォールトトレランス-MQメッセージはサーバーまたはネットワークの障害に耐えます-HTTPはそうではありません。
- MQは、メッセージの「確実な」配信を1回だけ提供しますが、httpは提供しません。
- MQには、大きなメッセージに対してメッセージのセグメント化とメッセージのグループ化を行う機能があります。HTTPには、各トランザクションを個別に処理するため、その機能はありません。
- MQは、HTTPがポイントツーポイントであるpub/subインターフェースを提供します。
UPD（2018年12月）：以下のコメントで @ Kevin に気づかれているように、RabbitMQがRESTfulサービスよりも優れていることは疑わしいです。私の元々の答えは、単に労働者を追加することに基づいていました。これはスケーリングのほんの一部であり、単一のAMQPブローカーの容量を超えない限り、それは事実ですが、それ以降は Highly Available（Mirrored ）Queues これにより、HTTPおよびAMQPベースのサービスの両方が、インフラストラクチャレベルで拡張するために、非常に複雑になります。
AMQPブローカー（RabbitMQ）の維持はどのHTTPサーバーよりも簡単であるということも慎重に考えて削除しました：元の回答は2013年6月に書かれ、それ以来多くの変更がありましたが、主な変更は両方のアプローチでより多くの洞察を得ることでした、だからこそ、「あなたの走行距離は異なる可能性がある」と言えるでしょう。
また、HTTPとAMQPの両方を比較すると、Appleはある程度オレンジになりますので、この答えをあなたの決定の基礎となる究極のガイダンスとして解釈するのではなく、特定のケースに一致する正確な解決策を見つけるためのさらなる調査の参考資料または参照として。
OPが受け入れなければならなかった皮肉な点は、AMQPまたは他のMQソリューションを使用して、呼び出し元をHTTPのみのサービスの固有の信頼性の低さから隔離するためによく使用されます。独自のHTTP絶縁コードを実装する必要があります。 JSONRPCなどのより信頼性の高いクライアントプロトコルを使用してAMQPに直接アクセスするオプションを備えた、信頼性の高いAMQPコア上の非常に薄いHTTPゲートウェイまたはアダプターレイヤーが、このシナリオに最適なソリューションであることがよくあります。