2つのマイクロサービス間の通信
私はマイクロサービスアーキテクチャでプロジェクトを作成しています。そして、2つのマイクロサービスを作成しました。
1つは製品エンティティ用で、もう1つは請求エンティティ用です。それらには独自のエンドポイントがあり、ゲートウェイと一緒に接続されています（jhipsterマイクロサービスアーキテクチャを使用しています）。
Bill-msは製品のリストにアクセスする必要があります。これら2つのms間でどのように通信できるのか疑問に思っています。私の頭の中には3つのアプローチがあります：
Bill-msからキューにリクエストを送信します-rabbitMQのように、これらのIDを持つこれらの製品をproduct-msから取得します（これのボトルネックはわかりません）
製品サービスのゲートウェイにリクエストを送信し、そこから製品を取得します（それらの間のデータサイズのために遅延が心配で、この方法ではデータベースに直接触れないため、常にゲートウェイに依存しています）
リポジトリ、サービス、およびエンティティをbill-msで複製できます（これはい方法であり、ms-architectureのルールを破り、メンテナンスは非常に困難です）
他のアプローチをお持ちの場合は、私と共有していただきありがとうございます。
編集
- これでボトルネックが何であるかがわかりました。bill-msには3つのインスタンスがあり、rabbitMQはどのインスタンスを応答するかをどのように決定するのでしょうか。または、ロードバランシングのために、「rabbitMQからのリクエストをサブスクライブするbill-msの無料インスタンスを提供してください」とリボンに言う必要があります。
私が答えようとしていることが正しい方法であるかどうかはわかりません。私はまだ自分自身を学んでいます。しかし、マイクロサービスの試みをどのように実装したかをお伝えできます。
まず、HTTP通信ベースのマイクロサービスで始めました このブログを使用 。これは正常に機能しますが、問題は、サービス間にdependendiesを作成することです。 サービスAはサービスBを認識し、呼び出す必要があるitdirectly（もちろんサービス発見などを介して）。これは、マイクロサービスを開発するときに一般的に避けようとしていることです。
最近始めたもう1つのアプローチは、message bus。実際には、質問で触れた3番目のオプションです。
私はサービスAを持っています。これは人を保存します（ほんの一例）。新しい人を作成するときにサービスが行うことは、eventバスでRabbitMQを送信します：personCreatedEvent。このようなイベントに関心のある他のサービスがある場合、それらは購読できます。これらの関心のあるサービスは、関心のある関連情報を独自のデータストアに保持します。
この最後のアプローチでは、サービス同士が直接通信しないため、サービス間に実際には依存関係はありません。 サービスAはサービスBを認識しません。Bはイベントを送信するだけですRabbitMQからこれらのイベントに関心のあるサービスへ、またはその逆。
もちろん、サービス上のデータストア間で重複があります。しかし、これも同様に有益です。サービスBは、サービスAと同じスキーマまたはデータストアメカニズムを使用する必要はありません。このサービスに最適な方法で関連情報のみを保存します。
http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ パート2：サービス間通信セクションを見ましたか。それがどのように達成されるかについての特定の例を説明します
このシナリオにさらに詳細を追加して、製品と入札のコンテキストでイベントと見なされるかどうかを強調してみましょう。 Billing-MSは、注文が行われた場合にのみProduct-Mと通信する必要があります。オーダーの配置は、主に、別のMSのオーダーMSの場合です。注文が作成または配置されると、商品の情報が品目として含まれます。
注文の作成は、イベントと見なすことができます。注文作成イベントが発生すると、請求サービスのキューにプッシュできます。キューは、RabbitMQのワークキューとして実装する必要があります。この方法では、Billing-MSの複数のインスタンスが同じキューにサブスクライブできますが、1つのワーカーだけで処理されます。 RabbitMQのワーカーとしてサービスを登録する際のRIBBONの役割はありません。各インスタンスはキューに登録され、RabbitMQはこのイベントを処理するBilling Serviceのインスタンスを取得するRoundRobinを決定します。
Billing-Mの注文で製品の詳細を取得することは、リボンを介して負荷分散されたサービス間コールである必要があります（使用している場合）。製品の詳細を取得することは実際にはイベントではなく、注文することは違いです。
また、エッジサービスを公開するためにゲートウェイを使用する必要があります。 Service-to-Serviceコールの場合、ゲートウェイサービス経由でホップすることは理想的ではありません。
1つのオプションは、eurekaレジストリの登録名を使用してマイクロサービスに請求するリクエストを送信することです。