アプリケーションシナリオ
1.南北交通
トラフィック ゲートウェイとマイクロサービス ゲートウェイを併用して、統合 HTTP アクセス ポイントを備えた内部マイクロサービス機能を提供し、外部にサービスを提供する必要があります。
トラフィック ネットワーク管理は主にアクセス トラフィックの負荷分散を実行し、上流のマイクロサービス ゲートウェイのアドレスと数はあまり変化しておらず、サービス検出の要件も高くありません。
マイクロサービス ゲートウェイは、外部リクエストを内部マイクロサービスにマッピングします。マイクロサービスのノード アドレスと数は頻繁に変更されますが、ルーティング ルールの変更は基本的に安定しています。マイクロサービス ゲートウェイは、サービス検出を便利に解決します。
2. 東西交通
同じビジネス ドメイン内のマイクロサービス通信はサービス ディスカバリ メカニズムを使用しており、上流ノードの負荷分散は robbin と Feign を通じて解決でき、集中サービスを提供するためのマイクロサービス ゲートウェイは必要ありません。
ビジネス ボリュームが比較的大きい一部のシステムでは、一連のマイクロサービスがビジネス ドメインに応じて分離されている場合があります。たとえば、2 つの大きなビジネス ドメイン サービス (支払いとトランザクション) をそれぞれ、多くのきめの細かいマイクロサービスに分割できます。南北方向でも東西方向でもアクセスでき、東西方向の場合はマイクロサービスゲートウェイを利用できるので、均一にサービスを提供できることが望まれます。
比較と今後
springcloudゲートウェイの機能は非常に弱く、ルーティングルールを設定するためのコードと設定ファイルのみをサポートしており、ルーティングルールの動的な設定はサポートしていない（自分で実装する必要がある）ため、十分実用的ではありません。
apisix のような任意のゲートウェイを使用して、Spring Cloud Gateway を爆破することができます。動的に定義されたルーティング ルール設定は、再起動せずに有効になります。Eureka サービス ディスカバリもずっと前に実装されています。
kubenetesをインストールした後はサービスディスカバリにサービスを直接利用するので、ゲートウェイどころかEurekaも必要ありません。
長期的には、すべてのアプリケーションで k8s が使用されることは避けられず、springcloud ゲートウェイは必然的に衰退します。