マイクロサービス通信のための直接サービス呼び出しとAPIゲートウェイ
以下のようなマイクロサービスアーキテクチャがあります。実行サービスでストレージおよび割り当てサービスから情報を取得したい。 MVCアプリをAPIゲートウェイのように使用し、すべてのマイクロサービス通信を処理したいと考えています。ただし、最初にネットワーク経由でAPIゲートウェイ、次に実行サービスにアクセスする必要があるため、特に大きなファイルの場合はオーバーヘッドが発生します。
私の質問は、REST呼び出しを介してマイクロサービス間で直接通信しても問題ないか、それを行うと最終的にスパゲッティアーキテクチャに変わるかどうかです。
どうやって矢をつなげていきましょうか…？
前もって感謝します。
基本的な質問から始めましょう：
REST呼び出しを介してマイクロサービス間で直接通信しても問題ありませんか？
短い答え：yes、しかし...
いくつかの概念を明確にしたいだけです。 APIゲートウェイは、実行中のマイクロサービスの潜在的に複数のインスタンスの1つにリクエストをリダイレクトするためのものです。ゲートウェイは負荷分散などを処理します。
マイクロサービス間の直接接続が必要な場合でも、負荷分散が必要です。それはすべて、インフラストラクチャにどのように対処するかによって異なります。たとえば、Kubernetes、Spring Cloudインフラストラクチャ、またはConsulでそれを達成する方法は少し異なります。
実際には、マイクロサービスのいずれかが部分的な障害に陥り、新しいリクエストへの応答を停止し、本質的に「スタック」する可能性があります。メモリの圧迫やガベージコレクションがハイパードライブに移行したり、テストに巻き込まれなかった無限ループなど、多くの理由が考えられます。
一番下の行は：
- 1回の呼び出しで連鎖するサービスが多いほど、これらのいずれかがうまくいかない可能性が高くなります
- 回路ブレーカーパターンを使用すると、スタックしたマイクロサービスの問題を緩和し、適切に失敗するようになります
- このシナリオの問題をデバッグするには、何らかの形式のオープントレーシングを使用することをお勧めします
- 非同期メッセージキューを介した呼び出しにより、APIの応答性が大幅に向上する可能性があります
発信者に意味のある応答を送信できる時間が早ければ早いほど、アプリケーションの応答性が高くなります。実行する必要がある追加の処理があるかもしれませんが、ユーザーはそれが完了すると信頼できる限り、座ってすべてが完了するのを待つ必要はありません。
一般的な経験則として：
- あるサービスから別のサービスへの非常に短い期間の通話は問題ありません。例：認証サービスがユーザー管理サービスを呼び出して、セッショントークンを生成するための重要な要素を見つけます。
- サービスからサービスへの長時間の呼び出しは、タイムアウトのリスクがあります。可能であれば非同期通信を使用します。
- 多くのサービス間呼び出しを行わなければならない場合は、サービスの責任を適切に分割していない可能性があります。
- 長いサービス呼び出しチェーン（つまり、サービス1がサービス2を呼び出し、サービス2がサービス3を呼び出すなど）を回避します。おそらく非同期呼び出しでそれを簡素化できます。
では、これがスパゲッティアーキテクチャになるかどうかが主な関心事ですか。さて、なぜドキュメンテーションを使わないのですか！？これは、この種の問題を改善するための十分にテストされたプラクティスです。すべてのプロセスを文書化するだけで、各矢印がどこを指しているかがわかります。
さらに、ゲートウェイの懸念。
I want to use MVC App like an API Gateway and handle all microservice communication. However, that creates an overhead especially for big files since it first has to go to API gateway over network then to my execution service.
ゲートウェイを使用してこれをベンチマークし、これがニーズを満たしていないと結論付けましたか？そうすれば、純粋な理論があなたの邪魔にならないはずです。理論は問題を解決するためのものであり、新しい制約を作成するものではありません。直接のコミュニケーションのために行き、適切に処理してください（上記のドキュメントで：P）。
追加
ゲートウェイは、複数のアプリを接続し、おそらくインターフェースを公開する方法です（他の理由の中でも）。新しいゲートウェイとして新しいインターフェースにアプローチする場合、より多くのインターフェースが存在するという事実は、重要な境界線ではないはずです。したがって、クライアントアプリの観点からは、2つのインターフェイスしかありません。 （ホリスティック対分析的思考を参照してください..：P）。もう1つの追加：フロントエンドのバックエンドと呼ばれるパターンがあります。まあ、あなたはバックエンドのフロントエンドになることができます！そして、まだマイクロサービスのエコシステム内にあります。まあ、正確ではありませんが、私が言いたいのは、ここではバックエンドインターフェイスを分離する正当な理由がある可能性があるということです。
お役に立てれば幸いです。