マイクロサービスは相互に通信する必要がありますか？

Micro-Servicesを使用してアプリケーションを設計していますが、複数のサービスからデータを収集するために使用する最適なメカニズムがわかりません。

私は2つのオプションがあると信じています：

• サービスが直接対話できるようにする「サービス間」通信メカニズムを統合します。API Gatewayは、統合された応答をAPI Gatewayに返す前に、個々のサービスを呼び出してから、他のサービスを呼び出してデータを収集します。その後、APIは呼び出し元に応答を返します。（これは、serviceBへの呼び出しがserviceAからの応答を必要とする場合、同期呼び出しである必要があります。IEは、個人とアドレスサービスを分離します。）
• API Gatewayで各サービスを直接呼び出し、応答を返す前にAPI内のデータを統合します。

サービスが相互に通信するとカップリングが導入されるため、2番目のオプションに傾いています。この場合、モノリシックアプリケーションを設計することもできます。ただし、このオプションを使用すると頭から離れて考えることができる重大な欠点がいくつかあります。

• APIに複数のサービスへの複数の呼び出しを実行させると、特にそれらの呼び出しの一部がブロックしている場合に、APIサーバーの負荷が増加します。

• このメソッドは、APIがアプリケーションが実行しようとしていることを「認識」する必要があることを意味します（IEロジックをAPIにプログラミングして、サービスの呼び出しを処理し、データを統合する必要があります）。マイクロサービスの愚かな「エンドポイント」として機能します。

この問題に対する標準的なアプローチが何であるか、そして私が見逃している別の3番目のオプションがあるかどうかを知りたいですか？

私は一般に、マイクロサービスが互いに同期通信を行うのを防ぐことをお勧めします。大きな問題は結合です。つまり、サービスの1つが失敗した場合、2番目のサービスが完全にまたは部分的に機能しなくなります。

状態変更操作と読み取り操作を明確に区別します（CQS コマンドクエリの分離）。状態を変更する操作の場合、何らかのメッセージングインフラストラクチャを使用します。クエリには、同期要求応答通信を使用し、http APIを使用するか、データストアに直接移動します。

メッセージングを使用している場合は、サービス間でイベントを発生させるためのパブリッシュサブスクライブも確認できます。

考慮すべきもう1つのポイントは、（トランザクションのみ）データ共有（読み取り専用ビューとは対照的）です。内部状態を公開すると、リーダーはデータの間違った状態または間違ったバージョンを取得し、データを潜在的にロックしますか？

最後になりましたが、サービスを自律的に保つためにできる限りのことを（少なくとも論理レベルで）行うようにしてください。

これが理にかなっていることを願っています。

そのデータが必要な理由によって異なります。UIの場合は、まったく問題ありません。さらに、そうあるべきです。クリス・リチャードソンはその概念について素晴らしい説明をしており、サム・ニューマンはフロントエンドのためのバックエンドと呼ばれる非常に類似した概念に関する素晴らしい記事を持っています。

しかし、何らかのロジックに必要な場合は、サービス境界が間違っている可能性があります。

私たちのサービスが持つべきであると常識が示すいくつかの特徴があります。彼らです：

1. 低カップリング。サービスAに何らかの変更を加えた場合、それらがサービスBに影響することは望ましくありません。
2. 高い凝集力。何らかの機能を実装する必要がある場合は、できるだけ少ない数のサービスに影響を与える必要があります。
3. 高い自律性。一部のサービスに障害が発生した場合、システム全体がダウンすることは望ましくありません。
4. 粒度を修正します。ネットワークは想像以上に複雑なものなので、サービスがおしゃべりにならないようにしてください。
5. サービスはイベントを介して通信する必要があります。保守性が低下するため、サービスがお互いを認識しないようにする必要があります。新しいサービスを追加する必要がある場合はどうなるかを考えてください。
6. 分散データ。サービスは、情報の保存方法を共有すべきではありません。良いオブジェクトのように、データではなく動作を公開します。
7. オーケストレーションに対するサービスの振り付け。

これを実現するには、サービスの境界をビジネス機能として扱います。サービス境界を識別する正式なプロセスは次のようになります。

1. より高いレベルの境界を特定します。私はそれらをビジネス目標を達成し、ビジネス価値を獲得するためにあなたの組織が歩むべきステップと考えたいです。ポーターのバリューチェーンを確認することで、基本的な手順を理解できます。
2. 各サービス内で、さらに深く掘り下げます。独自の責任を持つ子の自己完結型ユニットを特定します。
3. 彼らのコミュニケーション方法に注意してください。正しいサービスは、主にイベントを介して通信します。組織構造について考えてください。通常、いくつかの外部イベントが公開されますが、内部の通信はかなり集中的です。

このアプローチを適用する例は、興味深いかもしれません。

私はあなたの「APIゲートウェイ」にかかわらず、そうでないかもしれない、デフォルトでだけでなく第二のアプローチに傾くだろうが、私は、それは完全に合理的な作成するために検討する新しい唯一の目的、他のマイクロサービスに編成する要求にしたマイクロサービスをして表します高レベルの形式のデータ。マイクロサービスアーキテクチャでは、「ベース」マイクロサービスが相互に直接通信することに抵抗します。

これをもう少し主観的にするために、最初のサービスが直接または間接的に 2番目のサービスから2番目のデータまたはサービスを必要とする場合、1 つのサービスが別のサービスに依存するとします。数学用語では、この関係はpreorderではなく半順序にしたいです。ダイアグラム形式で、依存関係ダイアグラムをプロットした場合、ハッセダイアグラムを取得する必要がありますまた、（指示された）サイクルはありません。（ハッセ図では、エッジは暗黙的に下から上に向けられています。）さらにガイドラインとして、上から下へのパスを一般的に短くする必要があります。これは、デフォルトでより直接的に物事に依存したいということです。理由は、これにより、特定のリクエストで問題が発生する可能性のあるものの数が最小限に抑えられ、オーバーヘッドが最小限に抑えられ、複雑さが軽減されるためです。したがって、このメトリックによる「理想的な」場合、ハッセ図には2つのレベルしかありません。もちろん、キャッシング、統合、負荷分散、障害管理などの中間サービスを導入する理由はたくさんあります。

API Gatewayを「スマート」にするという2番目の懸念について詳しく説明するために、FalcorやRelay / GraphQLなどのフレームワークで注目を集めているパターンは、「API Gateway」が何GetTimelineが必要かを知ることなく、これらの仕様を実行します。代わりに、「このユーザー情報をユーザーサービスに要求し、これらの投稿をポストサービスから取得する」などのリクエストを取得します。

サービスを相互に「呼び出す」必要があるのは、適切にアーキテクチャ化されていないシステムを使用していることを示しているためです。マイクロサービスは適切に設計されています。

解決しようとしている問題について詳しく説明できますか？簡単な英語で？