マイクロサービス間の通信-データのリクエスト

Question

マイクロサービス間の通信を扱っています。

例（架空の例、説明のためだけに）：

マイクロサービスA-ストアユーザー（getUserなど）
マイクロサービスB-注文の保存（createOrderなど）

クライアントアプリから新しい注文を追加する場合は、ユーザーアドレスを知る必要があります。したがって、リクエストは次のようになります。

クライアント->マイクロサービスB（userId 5のcreateOrder）->マイクロサービスA（ID 5のgetUser）

マイクロサービスBは、ユーザーマイクロサービスからの詳細（住所）を使用して注文を作成します。

解決する問題：応答が返されるまで待たなければならないので、マイクロサービスAとマイクロサービスBの間の通信をどの程度効果的に処理しますか？

オプション：

RestAPIを使用し、
RabbitMQのようにAMQPを使用し、RPCを介してこの問題に対処します。（ https://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html ）

パフォーマンスに何が良くなるかわかりません。 RabbitMQまたはRestAPIを介した呼び出しは高速ですか？ マイクロサービスアーキテクチャに最適なソリューションは何ですか？

Foolish · Accepted Answer

あなたの場合、直接REST呼び出しを使用しても問題ありません。

オプション1 Rest APIを使用：

同期通信が必要な場合。たとえば、あなたの場合。このオプションが適しています。

オプション2 AMQPを使用：

非同期通信が必要な場合。たとえば、注文サービスが注文を作成するときに、製品の数量を減らすように製品サービスに通知することができます。または、ユーザーの注文が正常に行われたことをユーザーサービスに通知することもできます。

http://microservices.io/patterns/index.html をご覧になることを強くお勧めします。

Vanlightly · Answer

個人的には、RPCにメッセージブローカーを使用するのは好きではありません。不必要な複雑さとオーバーヘッドが追加されます。

ユーザーのWebサービスで長寿命のRabbitMQコンシューマーをどのようにホストしますか？静的なシングルトンにした場合、Webサービスでスケーリングと同時実行性をどのように処理しますか？それとも、スタンドアロンのデーモンプロセスにしますか？これで、1つではなく2つのユーザーアプリケーションができました。ユーザーコンシューマーの速度が低下した場合、リクエストメッセージを消費するまでに、Ordersサービスコンテキストがタイムアウトして別のメッセージを送信したか、あきらめた可能性があります。

RPCの場合、単純なHTTPをお勧めします。

同期ネットワーク呼び出しの必要性を回避できるメッセージブローカーを含むパターンがあります。このパターンは、サービスが他のサービスからのイベントを消費し、そのデータを独自のデータベースにローカルに保存するためのものです。次に、Ordersサービスがユーザーレコードを必要とするときが来ると、独自のデータベースからアクセスできます。

あなたの場合、ユーザーアプリは注文について何も知る必要はありませんが、注文アプリはユーザーについての詳細を知る必要があります。したがって、ユーザーが追加、変更、削除などされるたびに、Usersサービスはイベント（UserCreated、UserModified、UserRemoved）を発行します。 Ordersサービスはこれらのイベントをサブスクライブし、ユーザーアドレスなどの必要なデータのみを保存できます。

利点は、リクエスト時に、Ordersサービスの別のサービスへの同期依存関係が1つ少なくなることです。リクエスト時間の依存関係が少ないため、サービスのテストは簡単です。ただし、ユーザーレコードの変更が発生してからOrdersアプリで受信されるまでに遅延が発生するなどの欠点もあります。考慮すべきこと。

更新RabbitMQfor RPCを使用する場合は、メッセージTTL機能を使用することを忘れないでください。クライアントがタイムアウトする場合は、メッセージの有効期限をその期間に設定してください。これにより、無駄な作業を回避できます。コンシューマー側で、負荷がかかった状態でキューがバックアップされないようにします。メッセージブローカーを介したRPCの問題の1つは、キューがいっぱいになると、回復に時間がかかる長い待ち時間が追加される可能性があることです。メッセージの有効期限をクライアントタイムアウトはそれを回避するのに役立ちます。

RPC用のRabbitMQについて。通常、デカップリングと耐久性のためにメッセージブローカーを使用します。 RPCは同期通信であるため、つまり応答を待っているため、耐久性は考慮されません。それは私たちにデカップリングを残します。問題は、そのデカップリングは、ゲートウェイまたはDockerサービス名を介してHTTPで実行できるデカップリングよりも何かを購入するのでしょうか？

Yogendra Mishra · Answer

REST APIとイベントベースの設計またはその両方）のどちらかを選択するかどうかは、サービスの通信動作によって異なります。

あなたがすることはあなたが選ぶことができるあなたの要件に基づいていますREST APIあなたが見るところ同期の振る舞いサービス間で、イベントベースの設計を使用して、サービスのニーズ非同期動作、両方を組み合わせても害はありません。

プロセス間通信プロトコルには、メッセージングを使用することをお勧めします。クライアントサービスにはREST APIが最適です。 microservices.io の通信スタイルを確認してください。

RESTベースのアーキテクチャ

利点
1. 要求/応答は簡単で、同期環境が必要な場合に最適です。
2. 中間ブローカーがないため、よりシンプルなシステム
3. オーケストレーションを促進します。つまり、サービスは他のサービスの応答に基づいてアクションを実行できます。
欠点
1. サービスは、サービスインスタンスの場所を検出する必要があります。
2. サービス間の1対1のマッピング。
3. 残りは、TCP/IP上に構築された汎用プロトコルであるHTTPを使用しました。これは、メッセージを渡すために使用するときに膨大な量のオーバーヘッドを追加します。

イベント駆動型アーキテクチャ

利点
1. イベント駆動型アーキテクチャは、非同期環境で非常にうまく機能するため、API開発者にとって魅力的です。
2. 一度サービスを実行すると、複数のサービスがアプリケーションの要件に基づいてアクションを実行できるため、サービスが分離されるため、疎結合。新しい消費者をプロデューサーにプラグインするのは簡単です。
3. メッセージブローカーは、コンシューマーがメッセージを処理できるようになるまでメッセージをバッファリングするため、可用性が向上します。
欠点
1. 高可用性が必要なメッセージブローカーの追加の複雑さ
2. イベントリクエストのデバッグはそれほど簡単ではありません。