マイクロサービス ゲートウェイの概要
記事ディレクトリ
導入
さまざまなマイクロサービスを実装した後、さまざまなマイクロサービスを外部アプリケーション呼び出しにどのように提供できるでしょうか? ?
もちろん、Rest API インターフェイスなので、外部クライアントが直接マイクロサービスを呼び出しても問題ありません。しかし、さまざまな理由から、これはあまり良い選択ではありません。クライアントが各マイクロサービスと直接通信すると、次のような問題が発生します。
- クライアントは異なるマイクロサービスを複数回リクエストするため、クライアントの複雑さが増大します。
- クロスドメインリクエストがあり、特定のシナリオでは処理が比較的複雑になります
- 認証の実装は複雑で、各マイクロサービスには独立した認証が必要です
- リファクタリングが難しく、プロジェクトの反復によりマイクロサービスの再分割が発生する可能性があります。クライアントがマイクロサービスと直接通信する場合、リファクタリングの実装が困難になります。
- 一部のマイクロサービスがファイアウォールやブラウザに適さないプロトコルを使用している場合、直接アクセスは困難になります
上記の問題をどのように解決すればよいでしょうか? サービスゲートウェイを通じて解決できます。マイクロサービス システムでは、マイクロサービス リソースは通常、外部クライアント アクセスに直接公開されないため、内部サービスを隠蔽して上記の問題を解決できるという利点があります。ゲートウェイには多くの重要な意味があり、それは次の側面に具体化されています。
- ゲートウェイはID認証や権限管理、不正な操作権限要求の防止などを行い、サービスを保護する上で一定の役割を果たします。
- ゲートウェイはすべてのマイクロサービスを統合的に管理し、外部に公開するため、外部システムはマイクロサービス アーキテクチャの相互呼び出しの複雑さを知る必要がなく、内部サービスの一部の機密情報の漏洩も回避します。
- 監視が簡単で、監視データをマイクロサービス ゲートウェイで収集し、分析のために外部システムにプッシュできます。
- クライアントはサービス ゲートウェイのみを処理するため、クライアントと各マイクロサービス間の対話の数が削減されます。
- マルチチャネルのサポート。さまざまなクライアント (WEB、モバイル、デスクトップなど) に応じてさまざまな API ゲートウェイを提供できます。
- ゲートウェイはトラフィック監視に使用できます。同時実行性が高い場合、サービスを制限してダウングレードする
- ゲートウェイはサービスを内部から分離するため、テストに便利です
マイクロサービスゲートウェイは、ルーティングや負荷分散などのさまざまな機能を実現できます。Nginxやリバースプロキシと同様の機能。マイクロサービス アーキテクチャでは、バックエンド サービスは呼び出し元に対して直接開かれないことがよくありますが、リクエストの URL に従って API ゲートウェイを介して対応するサービスにルーティングされます。API ゲートウェイが追加されると、サードパーティの呼び出し元との間で、 API ゲートウェイでアクセス許可を制御するためにウォールが作成され、同時に API ゲートウェイは負荷分散された方法でアクセス許可をバックエンド サービスに送信します。マイクロサービス ゲートウェイ アーキテクチャ:
1. Spring Cloud Gateway の概要
springCloud は、Spring 5.0、spring Boot 2.0、Project Reactor などのテクノロジーに基づいて開発されたゲートウェイである Spring Cloud の新しいプロジェクトであり、マイクロサービス アーキテクチャ向けのシンプルかつ効果的な統合 API 管理手法を提供することを目的としています。
Spring Cloud エコシステムのゲートウェイとして、SpringCloud Gateway は Zuul を置き換えることを目的としています。Spring Cloud 2.0 より上のバージョンでは、Zuul 2.0 の新しいバージョンの最新の高パフォーマンス バージョンが統合されておらず、依然として古いバージョンの Reactor モードが使用されています。 Zuul 2.0.より前では、ゲートウェイのパフォーマンスを向上させるために、Spring Cloud Gateway は WebFlux フレームワークに基づいて実装されており、WebFlux フレームワークの最下層では高性能な Reactor モード通信フレームワーク Netty が使用されています。
Spring Cloud Gateway の目標は、統一されたルーティング方法を提供するだけでなく、セキュリティ、監視/インジケーター、電流制限などのフィルター チェーンに基づいたゲートウェイの基本機能も提供することです。
2. 特徴
SpringCloud は、次のように SpringCloud Gateway の機能を正式に導入します。
- Spring Framework 5、Project Reactor、Spring Boot 2.0 に基づく
- Spring Cloud Discovery クライアントを統合する
- 述語とフィルターは特定のルートに作用し、述語とフィルターを簡単に作成できます
- ゲートウェイのいくつかの高度な機能、動的ルーティング、電流制限、パス書き換え
- 内蔵ヒューズサーキットブレーカー
上記の特徴から、Zuul と大きな違いはありませんが、Spring Cloud Gateway と Zuul の主な違いは、基礎となる通信フレームワークにあります。
上記の 3 つの用語を簡単に説明します。
-
フィルター (フィルター) は
、概念的には Zuul のフィルターに似ており、リクエストをインターセプトして変更し、ダウンストリームの応答で二次処理を実行するために使用できます。 -
Route (ルーティング)
ゲートウェイ構成の基本コンポーネント モジュールは、Zuul のルーティング構成モジュールに似ています。Route モジュールは、ID、ターゲット URI、アサーションのセット、およびフィルターのセットによって定義されます。アサーションが true の場合、ルートは一致し、ターゲット URI にアクセスされます。 -
述語 (アサーション)
これは Java8 述語であり、ヘッダーやパラメーターなど、HTTP リクエストの任意のコンテンツと一致するために使用できます。アサーションの入力タイプは ServerWebExchange です。
3. ルーティングの設定方法
ルーティングは、Zuul のルーティング構成モジュールと同様、ゲートウェイ構成の基本的な構成要素です。Route モジュールは、ID、ターゲット URI、アサーションのセット、およびフィルターのセットによって定義されます。アサーションが true の場合、ルートは一致し、ターゲット URI にアクセスされます。
1. 基本的なルーティング設定方法:
要求されたアドレスが単一の URI リソース パスである場合、設定ファイルは次のようになります。
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
- id: service1
uri: https://blog.csdn.net
predicates:
- Path=/csdn
各フィールドの意味は以下のとおりです。
● id: カスタム ルート ID。一意に保ちます。
● uri: ターゲット サービス アドレス
● 述語: ルーティング条件。述語は入力パラメータを受け入れ、ブール値の結果を返します。このインターフェイスには、述語を他の複雑なロジック (AND、OR、NOT など) に組み合わせるためのさまざまなデフォルト メソッドが含まれています。
上記の設定は、url-proxy-1 という ID を持つ URI プロキシ ルールが設定されていることを意味します。ルーティング ルールは、アドレス http://localhost:8080/csdn/1.jsp にアクセスすると、上流アドレス https://blog.csdn.net/1.jsp
2. コードベースのルーティング設定
転送機能はコードを通じて実装することもできます。スタートアップ クラス GateWayApplication にメソッド CustomRouteLocator() を追加して、転送ルールをカスタマイズできます。
@SpringBootApplication
@EnableDiscoveryClient
public class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class, args);
}
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
return builder.routes()
.route("path_route", r -> r.path("/csdn")
.uri("https://blog.csdn.net"))
.build();
}
}
3. 登録センターと組み合わせたルーティング設定方法
uri のスキーマ プロトコル部分はカスタム lb: タイプです。これは、マイクロサービス レジストリ (Eureka など) からサービスをサブスクライブし、負荷分散を通じてサービスをルーティングすることを意味します。コードは以下のように表示されます。
server:
port: 9005
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
- id: service1
uri: https://blog.csdn.net
predicates:
- Path=/csdn
- id: service2
# uri: http://127.0.0.1:9001
uri: lb://cloud-payment-service
predicates:
- Path=/payment/**
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:9004/eureka
4. ルーティング一致ルール
Spring Cloud Gateway の主な機能はリクエストを転送することであり、転送ルールの定義には主に 3 つの部分が含まれます。
- ルート (ルーティング): ルートはゲートウェイの基本単位であり、ID、URI、述語のセット、およびフィルターのセットで構成され、述語に従って照合および転送されます。
- Predicate（述語、アサーション）：ルーティング転送の判断条件 現在 SpringCloud Gateway ではパス、クエリ、メソッド、ヘッダー等の様々な形式をサポートしている 記述方法は key = value の形式に従う必要がある
- フィルター (フィルター): フィルターは、リクエストが転送されるときに通過するフィルタリング ロジックであり、リクエストと応答の内容を変更するために使用できます。
5. 高度な機能
- ヒューズのダウングレード 分散
システムでは、ゲートウェイがトラフィックの入り口となるため、大量のリクエストがゲートウェイに入り、他のサービスへの呼び出しが開始されます。他のサービスは必然的に呼び出しに失敗します (タイムアウト、例外)。障害が発生すると、リクエストはゲートウェイ上で蓄積できないため、すぐに失敗してクライアントに戻る必要があり、この要件を達成するには、ゲートウェイ上でヒューズとダウングレードの操作を実行する必要があります。
ゲートウェイでのリクエストの失敗をすぐにクライアントに返す必要があるのはなぜですか? なぜなら、クライアントのリクエストが失敗すると、そのリクエストは常にゲートウェイに蓄積されるからです。もちろん、そのようなリクエストは 1 つだけであり、ゲートウェイには問題がないはずです (1 つのリクエストがシステム全体を麻痺させる可能性がある場合、システムは棚から取り出すこともできます）が、ゲートウェイに蓄積されると、コアビジネスの正常な動作を確保し、同時に顧客とほとんどの顧客の正しい応答を維持するために、ゲートウェイ、さらにはサーバー全体に大きな圧力がかかります。したがって、ゲートウェイでのリクエストの失敗はすぐにクライアントに返される必要があります。
CircuitBreaker フィルターは、Spring Cloud CircuitBreaker API を使用してゲートウェイ ルートをサーキット ブレーカーにラップします。Spring Cloud CircuitBreaker は、Spring Cloud Gateway で使用できるいくつかのサーキット ブレーカー ライブラリをサポートしています。たとえば、Spring Cloud はすぐに Resilience4j をサポートします。