マイクロサービスアーキテクチャでは、サービスは互いに直接対話する必要がありますか？

Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST API呼び出しを通じてこれらのサービスにアクセスできます。

これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？

クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか？

または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか？

サービスをこの図のようにしたい場合は、はい： それを実行できないわけではありませんが、ほとんどの場合、悪い結果をもたらします。RESTを介した通信は、サービスを大幅に分離しません。一部のサービスインターフェースが変更されると、ほとんどの場合、依存するすべてのサービスを変更して再デプロイする必要があります。また、サービスを再展開する間、依存するすべてのサービスを停止する必要があります。これは、高可用性標準の優れた設計とは見なされていません。

最終的に、代替のモノリスアプリよりも遅いマイクロサービスアプリケーションが作成されますが、ほぼ同じ問題が発生します。

@Robert Harveyに同意しないと

ただし実際には、1つ以上のマイクロサービス（おそらくそれらすべて）は、SQLデータベースのようないくつかの中央データストアと通信します。

統合データベースはよく知られているアンチパターンです

より優れたソリューションは、サービス間の通信を非同期にするために、パブリッシュ/サブスクライブパターンを使用することです。

この通信方法を実装するCQRS / ESの方法をご覧ください。GregYoungや他の連中が、このトピックに関する素晴らしい動画をたくさん提供しています。"CQRS / ES"キーワードをググるだけ。このアプローチでは、各サービスが同時にパブリッシャーとサブスクライバーになり、サービスの結合を大幅に減らすことができます。

これは、トピックに関する論争に光を当てるマイクロサービスに関する優れた一連の記事です。素敵なイラストで非常に詳細な説明。

SOAについてUdi Dahanが何と言っているかを読むと、多くの非常に優れたアイデアが得られます。

サービスは、特定のビジネス機能に対する技術的な権限です。データまたはルールは、1つのサービスのみが所有する必要があります。

これが意味することは、サービスがお互いのイベントをパブリッシュおよびサブスクライブしているときでさえ、すべてのデータとルールに対する信頼できる真実の源が何であるかを常に知っているということです。

また、ビジネス機能のレンズからサービスを見ると、多くのユーザーインターフェイスがさまざまな機能に属する情報、つまり在庫があるかどうかに加えて製品の価格を提示していることがわかります。上記のサービスの定義に準拠するために、これにより、そのようなユーザーインターフェイスは実際にはマッシュアップであることがわかります。各サービスは、特定のデータを処理するUIのフラグメントを持っています。

具体的にはUI組成物に関して、オンマウロServientiの記事UI組成物は、良好な出発点です。こちらから入手できる Udiのビデオも参照してください。

これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？

2つのサービスが相互にメッセージを交換する場合、いくつかのカップリングが発生します。主な答えは、それらが他のサービスのAPIに結合するということです。サービスは、内部が変更されても安定した状態を保つことを約束します。

さらに、サービスディスカバリーのような手法は、特定のサービスプロバイダーへの依存を緩和し、メッセージブローカーはプロデューサーとコンシューマーを分離することができます（メッセージとブローカーのAPIと対話する方法を互いに理解する必要があります-魔法はありません） ）。

それはあなたが「直接」で何を意味するかによる。

マイクロサービスアーキテクチャによれば、RESTのようなインターフェースを介して、独自のサーバーまたは外部サーバーのいずれかで他のマイクロサービスを呼び出すマイクロサービスを持つことは完全に問題ありません。

うまくいかないのは、1つのマイクロサービスが直接メソッド呼び出しを使用して別のマイクロサービスを呼び出すことです。それは両方のマイクロサービスを同じモノリスの一部にするでしょう。

これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？

カップリングは悪い言葉ではありません。 すべてのアプリケーションには、すでにある程度の結合があります。マイクロサービスと通信するアプリケーションはすでにマイクロサービスに結合されています。そうでなければ、機能しません。

マイクロサービスで本当に求めているのは、疎結合です。パブリックAPIを介して、またはイベントバスを使用して、1つのマイクロサービスに他のマイクロサービスを問い合わせさせるだけで、これを実現できます。

ただし実際には、1つ以上のマイクロサービス（おそらくそれらすべて）は、SQLデータベースのようないくつかの中央データストアと通信します。目標をどのように達成したいかに応じて、1つのマイクロサービスに何らかの方法でデータベースデータを変更させるだけで、他のマイクロサービスが変更を取得するためにクエリを実行します。

SOAやアーキテクチャー全般について話すとき、人々は意味論や専門用語に夢中になっているようです。サービスを「マイクロ」にするものは何ですか？結局のところ、使用している「スコアリングシステム」において、サービスを「非マイクロ」にしないことは、明らかにいくつかの特性のセットです。最高裁判所の判事がわいせつについて何と言ったのですか？「見ればわかるよ」

これは答えではないと言う人もいると思いますが、彼らは要点を逃しています。マイクロサービスアーキテクチャは、「密結合」の問題など、いくつかの問題を回避することを目的としています。したがって、お互いの細かい詳細に依存しているマイクロサービスのもつれを作成することになった場合は、パブ/サブメッセージバスを使用しているか、直接呼び出しを使用しているかにかかわらず、それが破壊される密結合を作成しています。ピースから新しいソリューションを作成したり、システム全体を停止することなく個々のピースを再構成したりする能力など

クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか？

場合によります; ただし、クライアントに直接使用可能な機能を提供し、結果が（たとえば、複数のマイクロサービスを介して）組み立てられる方法の詳細を非表示（カプセル化）にすることをお勧めします。

クライアントによる個々のマイクロサービスの結果の結合に必要なロジックが多すぎると、一部のビジネスロジックが誤ってクライアントに侵入する可能性があります。また、必要以上に内部アーキテクチャをクライアントに公開し、後でマイクロサービスのリファクタリングを妨げることがあります。

つまり、マイクロサービスの場合、有用な抽象化を備えたエンドポイントをクライアントに提供し、他の（おそらくより多くの内部の）マイクロサービスのより高いレベルの調整を実行するラッパーマイクロサービスがあると便利な場合があります。

（さらに、クライアントへの往復は、マイクロサービスから相互への往復よりもおそらく高価です。）

たとえば、GraphQLが取っている方向を見ると、クライアントがエンドポイントに直接関連するクエリを発行していることがわかります。これは、micrservicesのコレクションとして実装されている場合と実装されていない場合があります。マイクロサービスのアーキテクチャはGraphQLの背後に隠されているため、アーキテクチャのリファクタリングが容易になり、クライアントにとっても使いやすくなります。たとえば、https://stackoverflow.com/a/38079681/471129を参照してください。

マイクロサービスの主な目的は、アプリケーションを疎結合にすることです。したがって、サービスは互いに呼び出すことができません。それ以外の場合は、密結合されます。しかし、データを共有する必要がある2つのサービスがある場合はどうしますか？答えはメッセージブローカーです。したがって、クライアントからデータを取得するサービスは、中央のメッセージブローカーとデータを共有できます。サービスは、そのデータを使用して、データを消費し、変換して、独自のデータストレージに配置する必要があります。さまざまなトピックのデータをオンザフライでカフカストリームに結合できるので、カフカをお勧めします。PS。マイクロサービスを機能ごとに分離する方が良いでしょう。