マイクロサービスアーキテクチャでは、サービスは互いに直接対話する必要がありますか？
Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST APIs呼び出しを介してこれらのサービスにアクセスできます。
これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？
クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々と直接呼び出す必要がありますか？
または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか？
サービスをこの図のようにしたい場合は、はい： 
それはあなたがそれを行うことができないようなものではありませんが、ほとんどの場合それは悪い結果をもたらします。 RESTを介した通信は、サービスを大幅に分離しません。一部のサービスインターフェイスが変更された場合、ほとんどの場合、すべての依存サービスを変更して再デプロイする必要があります。また、サービスを再デプロイするときに、すべての依存サービスを配置する必要がありますこれは、高可用性標準に適した設計とは見なされていません。
最後に、代替のモノリスアプリよりも遅いマイクロサービスアプリケーションが作成されますが、ほぼ同じ問題が発生します
@Robert Harveyに同意しないと
ただし、実際には、1つ以上のマイクロサービス（おそらくそれらすべて）は、SQLデータベースのようないくつかの中央データストアと通信します。
統合データベースは 既知のアンチパターン です
より良い解決策は、サービス間の通信を非同期にするために、パブリッシュ/サブスクライブパターンを使用することです。
この通信方法を実装するCQRS/ESの方法、グレッグヤングと他の人たちを見てください トピックのニースのビデオの提供 「CQRS/ES」キーワードをググるだけ。このアプローチでは、各サービスが同時にパブリッシャーとサブスクライバーになり、サービスの結合を大幅に減らすことができます。
これが マイクロサービスに関する優れた一連の記事 であり、このトピックに関する論争に光を当てています。ニースのイラストで非常に詳細な説明。
Udi Dahanのコメント [〜＃〜] soa [〜＃〜] を読むと、非常に良いアイデアがたくさん得られます。
サービスは、特定のビジネス機能に対する技術的な権限です。データまたはルールは、1つのサービスのみが所有する必要があります。
つまり、サービスがお互いのイベントをパブリッシュおよびサブスクライブしている場合でも、データとルールのすべてについて、信頼できる真実の源が何であるかを常に把握しています。
また、ビジネス機能のレンズからサービスを見ると、多くのユーザーインターフェイスがさまざまな機能に属する情報、つまり在庫があるかどうかに加えて製品の価格を提示していることがわかります。上記のサービスの定義に準拠するために、これにより、このようなユーザーインターフェイスは実際にはマッシュアップであることがわかります。各サービスは、特定のデータを処理するUIのフラグメントを持っています。
特にUI構成に関しては、Mauro Servientiの I構成 に関する記事が出発点として適しています。 Udiのビデオ こちらから入手可能 も参照してください。
これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスのコンセプトに反するカップルになるでしょうか？
2つのサービスが相互にメッセージを交換する場合、いくつかのカップリングが発生します。主な答えは、それらが他のサービスのAPIに結合するということです。サービスは、内部が変更されている場合でも安定した状態を保つことを約束します。
それ以上に、 service discovery のような手法は特定のサービスプロバイダーへの依存を緩和し、メッセージブローカーはプロデューサーとコンシューマーを分離することができます（それらはまだお互いのメッセージとメッセージと対話する方法を理解する必要があります）ブローカーのAPI-魔法はありません）。
それはあなたが「直接」で何を意味するかに依存します。
マイクロサービスアーキテクチャによれば、RESTのようなインターフェースを介して、独自のサーバーまたは外部サーバー上で他のマイクロサービスを呼び出すマイクロサービスを持つことは完全に問題ありません。
うまくいかないのは、1つのマイクロサービスが直接メソッド呼び出しを使用して別のマイクロサービスを呼び出すことです。それは両方のマイクロサービスを同じモノリスの一部にするでしょう。
これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？
カップリングは悪い言葉ではありません。すべてのアプリケーションにはすでにある程度のカップリングがあります。マイクロサービスと通信するアプリケーションは、マイクロサービスにすでに結合されています。そうでない場合、それらは機能しません。
マイクロサービスで本当に必要としているのは loose cupling ;です。これは、パブリックAPIを介して、またはイベントバスを使用して、1つのマイクロサービスに他のマイクロサービスを問い合わせさせるだけで実現できます。
ただし実際には、1つ以上のマイクロサービス（おそらくそれらすべて）は、SQLデータベースなどの中央データストアと通信します。目標をどのように達成したいかに応じて、1つのマイクロサービスに何らかの方法でデータベースデータを変更させるだけで、他のマイクロサービスが変更を取得するためにクエリを実行します。
SOAやアーキテクチャー全般について話すとき、人々は意味論や専門用語にとらわれているようです。サービスを「マイクロ」にするものは何ですか？結局のところ、使用している「スコアリングシステム」の中で、サービスを「非マイクロ」にしないことは、明らかに一連の特性です。最高裁判所の判事がわいせつについて何と言ったのですか？ 「見ればわかるよ」
これは答えではないと言う人もいると思いますが、彼らは要点を逃しています。マイクロサービスアーキテクチャは、「密結合」の問題など、いくつかの問題を回避することを目的としています。したがって、相互の細かすぎる詳細に依存するマイクロサービスのもつれを作成することになった場合、パブ/サブメッセージバスを使用しているか、直接呼び出しを使用しているかにかかわらず、それが破壊される密結合が作成されています。ピースから新しいソリューションを作成したり、システム全体を停止させることなく個々のピースを再構成したりする能力など
マイクロサービスの主な目的は、アプリケーションを疎結合にすることです。したがって、サービスは互いに呼び出すことができません。それ以外の場合は、密結合されます。しかし、データを共有する必要のある2つのサービスがある場合はどうしますか？答えはメッセージブローカーです。したがって、クライアントからデータを取得するサービスは、中央のメッセージブローカーとデータを共有できます。その後、サービスはそのデータを使用して、データを消費し、変換して、独自のデータストレージに配置する必要があります。 Kafkaを使用すると、さまざまなトピックのデータをオンザフライでKafka Stream。PS。で結合できるため、機能ごとにマイクロサービスを分離する方がよいためです。
クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか？
場合によります;ただし、直接使用可能な機能をクライアントに提供し、結果が（たとえば、複数のマイクロサービスを介して）組み立てられる方法の詳細を隠す（カプセル化する）ことをお勧めします。
クライアントによる個々のマイクロサービスの結果の結合に必要なロジックが多すぎると、一部のビジネスロジックがクライアントに侵入する可能性があります。また、必要以上に内部アーキテクチャをクライアントに公開し、後でマイクロサービスのリファクタリングを妨げることもあります。
つまり、マイクロサービスでは、有用な抽象化を備えたエンドポイントをクライアントに提供し、他の（おそらくより多くの内部の）マイクロサービスのより高いレベルの調整を実行するラッパーマイクロサービスがあると便利な場合があります。
（さらに、クライアントへの往復は、マイクロサービスから相互への往復よりもおそらく高価です。）
たとえば、GraphQLが取っている方向を見ると、クライアントがエンドポイントに直接関連するクエリを発行していることがわかります。これは、micrservicesのコレクションとして実装されている場合と実装されていない場合があります。マイクロサービスのアーキテクチャはGraphQLの背後に隠されているため、アーキテクチャのリファクタリングが容易になり、クライアントにとっても使いやすくなります。たとえば、 https://stackoverflow.com/a/38079681/471129 を参照してください。