マイクロサービスRESTまたはAMQP、どちらの場合

Question

マイクロサービスアーキテクチャに関する記事をたくさん読んだので、AMQPとRESTのどちらを使用すべきか迷っていました。

サービス間の疎結合は良いことであり、その場合はAMQPが良い選択のようです。しかし、AMQPを使用する場合、これはRESTエンドポイントが不要になることを意味します（ただし、HATEOASの概念が失われることを意味します）。

しかし、RESTは本当に私のサービスを構築する良い方法ですか？原因エンドポイントを使用しないのです...その場合、一方が他方よりも優れていますか？

どちらを使用すればよいですか？

Arseni Mourzenko · Answer

RESTを破棄することで、HATEOASだけではなく、はるかに多くを失うことになります。マイクロサービスが公開されている場合（そして、公開するか、少なくとも1日公開する傾向があることをお勧めします¹）、RESTおよびSOAP以外のものを使用すると問題が発生します。

AMQPを使用したことがない開発者もいます。
AMQPを使用している人もいますが、多くの場合RESTとSOAPに精通しています。
一部の言語のAMQPライブラリは特に簡単ではありません。
サービスを使用した手動の実験は非常に限られています。CURLを使用してAmazon S3へのリクエストを実行できます。 S3のAMQPバリアントでプレイしたい場合、自分のマシンに何をinstallすべきですか？
RESTおよびSOAPのデバッグは簡単です。 HTTP交換を追跡して分析するだけです。 AMQP交換をデバッグするためにどのツールを使用すればよいかわからない。

AMQPはすばらしいですが、イベントに基づく交換という非常に特定の目的のために行われます。 AMQPでRPCを行うことは技術的には可能ですが、それが主な目的ではありません。

非同期の側面も重要です。場合によってはメリットがあります。サーバーへのリクエストを実行している間、アプリのユーザーインターフェースをブロックしたくありません。場合によっては、必要以上に困難になることがあります。ローカルバックアップが破損しているためにAmazon S3からファイルバックアップを復元し、バックアップを復元する必要がある場合、バッチファイルは続行する前にジョブを完了するためにCURLを必要とします。同期操作（特定のタイムアウトを伴う）は完全に理にかなっています。

Keep REST for primary operations：

製品の入手
請求書の保管、

メッセージングが実際に意味をなすタスクにはAMQPを使用します：

9月からのすべての請求書を処理し、レポートを表示する準備ができたらアプリに通知します（操作に通常2〜10分かかります）。

^{ここでのAMQPの利点は、非同期の側面です。 10分間保留中のHTTPリクエストは、タイムアウトやその他の問題を引き起こす可能性が高くなります。}
バックアップが破損したという情報を、サポート担当者、データベース管理者、監視チーム、このデータベースを使用するアプリケーションの開発者など、関心のあるすべての人に送信する。

^{ここでのAMQPの利点は、特に、バックアップを追跡し、破損したアプリケーションを検出したときにアラートをトリガーするアプリケーションを変更せずにサブスクライバーを追加できることです。}

^{publicパブリックWebサービスは、必ずしも社外のユーザーが使用する必要はありません。大規模または中規模の企業では、サービスは多くの場合、同じ企業の他の部門によって使用され、サードパーティによって使用されるものと同じ要件を持っています。あなたのサービスがあなたと同じ会社で働いていると聞いても、彼がそのセキュリティ問題を悪用しないわけではありません）、適切に文書化する必要があります（同じインド人が必ずしもあなたの電話番号を知っているわけではなく、必ずしもそうではないためです）英語を知っているなど）.}

Ewan · Answer

両方を使う。

RESTスタイルのJSON Webサービスは、javascript、iosなどとの相互運用に最適です

AMQPは、長時間実行されるプロセス、イベント、マイクロサービスのオーケストレーションに最適です。

ただし、どちらも実際のサービスの単なる通信ラッパーであり、同じサービスを複数の方法で公開できます。

AMPQは、RESTエンドポイントに目を細めればエンドポイントのように見える可能性があります。

gbjbaanb · Answer

RESTは、コンポーネント間の相互運用性に特に適した標準テクノロジーです。これは重要な部分であり、他のユーザーが使用できるWebサービスを作成するのに最適です。ただし、カスタムプロトコルよりも効率が悪いという点で、このような相互運用性の通常の問題があります。

サービスが自分で消費されるだけのバックエンドアーキテクチャを作成している場合は、好きなプロトコルを使用できます。相互運用性の高いプロトコルを使用することによる制約を受けなくなります。 MQまたはより密接に結合されたパフォーマンスの高いものを使用できます。どちらを使用するかはユースケースによって異なります。メッセージバスは、クライアントが送信するメッセージをだれが受け取るかを気にしないデータを処理する分散サービスセットに非常に適しています。

Cochise Ruhulessin · Answer

AMQPは、ポイントツーポイント通信もサポートしています（たとえば、python-qpid-protonチュートリアルを参照）。 REST != HTTPなので、それを使用してRESTfulインターフェースを実装できます。

AMQPは、HTTPよりもパフォーマンスが大幅に向上します。