SpringCloudプロジェクトの構築方法を教えます (13) Gatewayの統合 新世代サービスゲートウェイ

マイクロサービスとは何ですか? シリーズが一目でわかる！

1. SpringCloudプロジェクトのビルド方法を教えます (1) 写真とテキストで詳しく説明、アホのような操作

2. SpringCloud プロジェクトの構築方法を教える (2) プロデューサーとコンシューマー

3. SpringCloudプロジェクトの構築方法を教えます (3) Eurekaサービス登録センターの統合

4. SpringCloudプロジェクトの構築方法を教えます (4) Eurekaクラスタのバージョン構築

5. SpringCloudプロジェクトのビルド方法を教えます (5) プロデューサークラスターバージョンをビルドします

6. SpringCloudプロジェクトの構築方法を教えます (6) Eurekaはサービスディスカバリを実現します

7. SpringCloudプロジェクトの構築方法を教える (7) Consulサービス登録センターを統合する

8. SpringCloudプロジェクトの構築方法を教えます (8) 統合リボンロードバランサ

9. SpringCloud プロジェクトの構築方法を説明します (9) OpenFeign サービス インターフェイス呼び出しの統合

10. SpringCloud プロジェクトの構築方法を教えます (10) Hystrix サービスのダウングレードの統合

11. SpringCloud プロジェクトの構築を教える (11) Hystrix のサービス ヒューズの統合

12. SpringCloud プロジェクトの構築方法を教える (12) Hystrix のグラフィカル ダッシュボードのリアルタイム モニタリングを統合する

13. SpringCloud プロジェクトの構築方法を教える (13) 新世代のゲートウェイを統合する

14. SpringCloudプロジェクトの構築方法を教えます (14) Integrated Config Distributed Configuration Center

15. SpringCloudプロジェクトの構築方法を教えます (15) Integrated Busメッセージバス

16. SpringCloud プロジェクトの構築方法を説明します (16) 統合された Stream メッセージ ドライバー

17. SpringCloud プロジェクトの構築方法を説明します (17) Sleuth 分散リンク追跡の統合

これからも更新していきますので、いいねやフォロー大歓迎です！

ゲートウェイの概要

1. APIゲートウェイとは何ですか?

API フレームワークとして、API サービスへのアクセスを保護、強化、制御するために使用されます。API ゲートウェイは、アプリケーションやサービス (REST API インターフェース サービスを提供する) の前にあるシステムであり、認可、アクセス制御、トラフィック制限などを管理するために使用されます。これにより、REST API インターフェース サービスは API ゲートウェイによって保護され、透過的になります。すべての発信者に。その結果、API ゲートウェイの背後に隠されたビジネス システムは、これらの戦略的インフラストラクチャを扱う代わりに、サービスの作成と管理に集中できます。

2. APIゲートウェイにはどのような機能がありますか?

3. APIゲートウェイの分類と機能は何ですか?

4. ゲートウェイとは

Spring Cloud Gateway は、Spring 5.0、Spring Boot 2.0、Project Reactor などのテクノロジーに基づいて Spring によって開発された公式ゲートウェイであり、マイクロサービス アーキテクチャ向けのシンプルかつ効果的な統合 API ルーティング管理方法を提供することを目的としています。Spring Cloud エコシステムのゲートウェイとして、Spring Cloud Gateway は ZUUL を置き換えることを目指しており、統一されたルーティング方法を提供するだけでなく、セキュリティ、監視/埋め込み、フィルタ チェーンに基づいたゲートウェイの基本機能も提供します。電流制限待ち。

5. ゲートウェイを使用する理由

Spring Cloud Gateway は Zuul 1.x のアップグレード版であり、Zuul 2 よりも早く Netty を使用して非同期 IO を実装することで、シンプルかつ Zuul 1.x より効率的で Spring Cloud に近いゲートウェイを実現しています。 APIゲートウェイ。

Spring Cloud Gateway は Router と Filter を明確に区別しており、すぐに使える機能が多数組み込まれており、それらのすべてが SpringBoot 設定または手動のコーディング チェーン呼び出しを通じて使用できることが大きな特徴です。
たとえば、10 個の内蔵ルーターがあるため、それらを直接設定し、ヘッダー、パス、ホスト、クエリに従ってルーティングを行うことができます。

例えば、一般フィルターとグローバルフィルターが区別されており、20種類のフィルターと9種類のグローバルフィルターが内蔵されており、すべてを直接使用することができます。もちろんカスタムフィルターも非常に便利です。

6. 最も重要な概念

1. ルート (ルーティング): これはゲートウェイの基本的な構成要素であり、ID、URI、一連のアサーション、および一連のフィルターによって定義されます。アサーションが true の場合、ルートは一致します。

2. 述語 (アサーション): 入力クラスは ServerWebExchange です。これを使用して、ヘッダーなど、HTTP リクエストのあらゆるものと一致させることができます。リクエストがアサーションと一致する場合、ルーティングが発生します。

3. フィルター (フィルター): Spring フレームワークの GatewayFilter のインスタンス フィルターを使用すると、リクエストをルーティングする前または後に変更できます。

7. ワークフロー

クライアントは Spring Cloud Gateway にリクエストを送信し、ゲートウェイ ハンドラー マッピングでリクエストに一致するルートを見つけてゲートウェイ Web ハンドラーに送信します。

ハンドラーは、指定されたフィルター チェーンを通じて実際のサービス ビジネス ロジックにリクエストを送信し、戻ります。フィルターはプロキシ要求の前 (「前」) または後 (「後」) にビジネス ロジックを実行する可能性があるため、フィルターは点線で区切られています。

「pre」タイプのフィルタではパラメータ検証、権限検証、トラフィック監視、プロトコル変換などが行えます。「post」タイプのフィルターでは、応答内容、応答ヘッダー、ログ出力、トラフィック監視などを変更することができ、非常に重要な役割を果たします。

メインコアはルーティング転送 + 実行フィルターチェーン

2. 設定の開始

サービス名がcloud-gateway-gateway9527である新しいモジュールを作成し、pom.xmlファイルを変更して、主にゲートウェイの依存関係を追加します。マイニングのヒント。Web 依存関係を導入しないでください。導入しないと、エラーが報告され、プロジェクトが開始されません。以下に示すように:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>mcroservice</artifactId>
        <groupId>com.study.springcloud</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
 
    <artifactId>cloud-gateway-gateway9527</artifactId>
    <dependencies>
        <!--gateway-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>
        <!-- eureka-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
    <!--  通用包-->
        <dependency>
            <groupId>com.study.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>${project.version}</version>
        </dependency>
 
        <!--监控-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
 
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
 
    </dependencies>
 
</project>

以下に示すように、新しい yml 構成ファイルを作成します。

server:
  port: 9527
 
spring:
  application:
    name: cloud-gateway  
eureka:
  instance:
    hostname: cloud-gateway-service
  client: #服务提供者provider注册进eureka服务列表内
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

以下に示すように、新しいメイン起動クラスを作成します。

package com.buba.springcloud.gateway;
 
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
 
@SpringBootApplication
@EnableEurekaClient
public class GatewayMain {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(GatewayMain.class,args);
    }
}

次に、Eureka7001 サービスと新しいゲートウェイのゲートウェイ サービスを開始して、ゲートウェイ サービスが Eureka 登録センターに正常に登録されているかどうかを確認します。

ゲートウェイ Gateway が登録センターに正常に登録されたことがわかります。では、ゲートウェイはどのようにマッピングを行うのでしょうか? これをマッピングする例として、cloud-provide-payment プロデューサー サービスを取り上げてみましょう。PaymentControler コントロール層を開き、get と lb の 2 つのメソッドをデモンストレーションします。これまでの訪問はすべて http://localhost:8001/payment/get/1 ですが、訪問時にはポート 8001 を使用します。ポート 8001 は公開されています。これは安全ではありませんが、実際の 8001 ポート番号を公開したくなく、ゲートウェイ ポート 9527 の層を 8001 の外側にラップしたいと考えています。これには、yml 設定で新しいルーティング設定が必要です。以下に示すように:

server:
  port: 9527
 
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      routes:
        - id: payment_route # 路由的id,没有规定规则但要求唯一,建议配合服务名
         #匹配后提供服务的路由地址
          uri: http://localhost:8001
          predicates:
            - Path=/payment/get/** # 断言，路径相匹配的进行路由
        - id: payment_route2
          uri: http://localhost:8001
          predicates:
            Path=/payment/lb/** #断言,路径相匹配的进行路由
 
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    fetch-registry: true
    register-with-eureka: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

次に、http://localhost:9527/payment/get/1 にアクセスすると、正常にアクセスでき、ゲートウェイのルーティングとアサーションが正常に構成されていることを示します。以下に示すように:

現在構成しているのは YML 構成であり、別の構成ソリューションはハードコーディングによるものです。これは、YML ファイル構成が多すぎたり、ファイルが大きすぎたりする問題を解決するために、コード内の RouteLocator に挿入される Bean です。それから舐め始めてください！9527 ゲートウェイを介して外部ネットワーク上の Baidu News の Web サイトにアクセスする方法を示すだけで済みます。

以下に示すように、新しい config 構成ファイルを作成します。

package com.buba.springcloud.gateway.config;
 
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
 
/**
 * 配置了一个id为routr-name的路由规则
 * 当访问地址http://localhost:9527/guonei时会自动转发到http://news.baidu.com/guonei
 * */
@Configuration
public class GateWayConfig
{
    
    
    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder routeLocatorBuilder){
    
    
        RouteLocatorBuilder.Builder routes = routeLocatorBuilder.routes();
        routes.route("patn_route_buba",r -> r.path("/guonei").uri("http://news.baidu.com/guonei")).build();
        return routes.build();
    }
}

構成が完了したら、サービスを再起動し、http://localhost:9527/guonei にアクセスすると、次のインターフェイスに正常に転送できます。これは、GateWay がエンコードによってルーティング マッピング構成を実行していることを示しています。

3. ダイナミックルーティングの実現

YML 構成ファイルを見ると、http://localhost:8001 はハードコーディングされていますが、マイクロサービスではプロデューサー サービスがマシンを持つことは不可能であるため、ロード バランシングを構成する必要があります。

デフォルトでは、Gateway はレジストリに登録されたサービスリストに基づいて動的ルートを作成し、レジストリ上のマイクロサービス名を使用して転送することで、動的ルーティングの機能を実現します。次に、ゲートウェイの YML 構成ファイルを変更し、レジストリからルートを動的に作成する機能を有効にし、ルーティングにマイクロサービス名を使用し、照合後にサービス プロバイダーのルーティング アドレスをプロデューサーのサービス名に変更する必要があります。具体的な構成は次のとおりです。次のように：

server:
  port: 9527
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true # 开启从注册中心动态创建路由的功能，利用微服务名称j进行路由
      routes:
        - id: payment_route # 路由的id,没有规定规则但要求唯一,建议配合服务名
          #匹配后提供服务的路由地址
          #uri: http://localhost:8001
          uri: lb://MCROSERVICE-PAYMENT
          predicates:
            - Path=/payment/get/** # 断言，路径相匹配的进行路由
        - id: payment_route2
          #uri: http://localhost:8001
          uri: lb://MCROSERVICE-PAYMENT
          predicates:
            Path=/payment/lb/** #断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    fetch-registry: true
    register-with-eureka: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

ロード バランシングをテストするには、Eureka7001 を起動し、プロデューサー サービス 8001 および 8002 を起動し、ゲートウェイ サービスを起動し、リターン ポートの lb メソッドを 8002 サービスに忘れずに追加する必要があります。負荷分散が正常に達成されました。テストは次のとおりです。

4. 一般的に使用される述語アサーション

Cloud-gateway-gateway9527 サービスを開始すると、コンソールに次のインターフェイスがあることがわかります。

Spring Cloud Gateway は、基本的な Spring WebFlux HandlerMapping フレームワークの一部としてルート マッチングを使用します。これには多くの組み込み RoutePredicateFactories が含まれており、そのすべてが HTTP リクエストのさまざまな属性に一致します。複数のルート述語ファクトリーを結合します。Spring Cloud Gateway が Route オブジェクトを作成するとき、RoutePredicateFactory を使用して Predicate オブジェクトを作成します。Predicate オブジェクトは Route に割り当てることができます。Spring Cloud Gateway には多くの組み込み Route Predicate Factories が含まれています。これらの述語はすべて、HTTP のさまざまな属性と一致します。複数の述語ファクトリーを組み合わせて、論理 and を渡すことができます。

次に、YML 構成ファイル内のルーティング構成も確認できます。パスを使用します。つまり、要求されたパス (パス) が構成値と一致します。以下に示すように:

一般的に使用されるルーティング設定は、リクエストが処理する対応するルートを見つけられるように、一連の一致ルールを実装することです。以下に示すように:

After を例に挙げますが、他も同様ですが、公式 Web サイトが次の図のようにどのように構成されているかを見てみましょう。

赤い部分に一連の時間が表示されます。公式 Web サイトでは外国時間が使用されていますが、現在時刻を使用するにはどうすればよいですか? 現在の国内時刻を取得するには、次のクラスを使用します。デフォルトは上海です。以下に示すように:

package com.buba.test;
 
import java.time.ZonedDateTime;
 
public class T2 {
    
    
    public static void main(String[] args) {
    
    
        ZonedDateTime time =  ZonedDateTime.now();//使用默认时间
        System.out.println(time);
 
 
    }
}

時間を取得したら、次の図に示すように、YML ファイルを構成します。支払い/取得メソッドのみを構成します。

server:
  port: 9527
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true # 开启从注册中心动态创建路由的功能，利用微服务名称j进行路由
      routes:
        - id: payment_route # 路由的id,没有规定规则但要求唯一,建议配合服务名
          #匹配后提供服务的路由地址
          #uri: http://localhost:8001
          uri: lb://MCROSERVICE-PAYMENT
          predicates:
            - Path=/payment/get/** # 断言，路径相匹配的进行路由
            - After=2020-09-08T21:11:46.662+08:00[Asia/Shanghai] #断言在当前时间之后才可以访问
        - id: payment_route2
          #uri: http://localhost:8001
          uri: lb://MCROSERVICE-PAYMENT
          predicates:
            Path=/payment/lb/** #断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    fetch-registry: true
    register-with-eureka: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

次に、次の図に示すように、現在時刻が構成された時刻よりも後である必要があるため、まずアクセスが成功するかどうかをテストしましょう。

次の図に示すように、時間を変更して時間を 1 日戻してから、支払い/取得メソッドをテストしてみましょう。

設定後はアクセスできないことがわかります。このように後は、新しい機能をリリースするときに使用できます。たとえば、会社が午後 10 時にオンラインになる場合、事前にオンラインにすることができます。設定した時間が有効になるまで待ちます。次に、次の図に示すように、After アサーションを使用せずにpayment/lb メソッドをテストして、アクセスが成功するかどうかを確認してみましょう。

アクセスが成功したことは、設定が正しいことを示していることがわかります。必要に応じて 11 個のアサーションを設定できます。

五、フィルターの使用

フィルタは、ゲートウェイの 3 つのコアの 1 つです。ルート フィルタは、受信した HTTP リクエストと返された HTTP 応答を変更するために使用できます。ルート フィルタは、ルートを指定することによってのみ使用できます。Gateway にはさまざまな組み込みルーティング フィルターがあり、それらはすべて GatewayFilter プロジェクト クラスによって生成されます。

フィルターの役割

下図のようにユーザーサービス、物品サービス、販売サービスなど多数のサービスがある場合、クライアントが各サービスのAPIをリクエストすると、各サービスは認証など同じことを行う必要があります。電流制限、ログ出力など

このような繰り返しの作業をより効率的に行う方法はないでしょうか。答えは「はい」です。グローバル アクセス制御、電流制限、ログ出力の API ゲートウェイ サービスをマイクロサービスの上位層に追加し、リクエストを特定のビジネス サービス層に転送します。この API ゲートウェイ サービスはサービス境界として機能し、システムにアクセスする外部リクエストは最初にゲートウェイ層を通過する必要があります。

フィルターのライフサイクル

Spring Cloud Gateway は zuul に似ていますが、ライフサイクルの前後のみがあります。ルーティング処理の前に「pre」型のフィルタで処理する必要があり、処理が応答を返した後は「post」型のフィルタで処理できます。「pre」タイプのフィルタはパラメータ検証、権限検証、トラフィック監視、ログ出力、プロトコル変換などを行うことができ、「post」タイプのフィルタは応答内容、応答ヘッダの変更、ログ出力、トラフィック監視などを行うことができます。 。

たとえば、上図のユーザー サービスは、ビジネス サービスからの応答を受信した後、「post」タイプのフィルターによって処理され、最終的にクライアントに応答を返します。

zuulとは異なり、Spring Cloud Gatewayでは「pre」と「post」に分かれたフィルタに加えて、アクションの範囲からさらに2つのタイプにフィルタを分けることができます。1つは単一ルートフィルタのゲートウェイであり、これは次のように記述されます。構成ファイル内は、predict と同様で、もう 1 つはすべてのルートのグローバル ゲートウェイ ファイラーです。次に、これら 2 つのフィルターをスコープ分割の次元から説明します。

Spring Cloud Gatewayのフィルタタイプは、GatewayFilter（シングル）とGlobalFilter（グローバル）に分かれています。

Spring Cloud Gateway根据作用范围划分为GatewayFilter和GlobalFilter，二者区别如下：

GatewayFilter : 需要通过spring.cloud.routes.filters 配置在具体路由下，只作用在当前路由上或通过spring.cloud.default-filters配置在全局，作用在所有路由上。

GlobalFilter : 全局过滤器，不需要在配置文件中配置，作用在所有的路由上，最终通过GatewayFilterAdapter包装成GatewayFilterChain可识别的过滤器，它为请求业务以及路由的URI转换为真实业务服务的请求地址的核心过滤器，不需要配置，系统初始化时加载，并作用在每个路由上。

GatewayFilter の概要

GatewayFilter ファクトリは、前の記事で紹介した Predicate ファクトリに似ています。構成ファイル application.yml で構成されます。規則は構成よりも重要であるという考えに従っています。構成する必要があるのは、GatewayFilter ファクトリの名前だけですたとえば、AddRequestHeaderGatewayFilterFactory では、構成ファイルに AddRequestHeader のみを記述する必要があり、すべてのクラス名を記述する必要はありません。構成ファイルで構成された GatewayFilter ファクトリは、最終的に対応するフィルタ ファクトリ クラスによって処理されます。

Spring Cloud Gateway の組み込みフィルターファクトリーのリストは次のとおりです。

各フィルター ファクトリの詳細な使用例は公式ドキュメントで説明されています。現在 30 のバージョンがあります。クリックして公式 Web サイトを表示します。よくわからない場合は、org.springframework.cloud.gateway.filter.factory で各フィルターを参照することもできます。デバイス ファクトリのソース コード。在我们实际的开发过程中，一般GatewayFilter是无法满足的，就需要我们自定义过滤器。

それでは、フィルターを自分でカスタマイズしてみましょう。

主なことは、次の図に示すように、これら 2 つのインターフェイス GlobalFilter、Ordered を実装し、次に特定のビジネス ロジックを実装することです。

package com.buba.springcloud.gateway.filter;
 
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;
 
import java.util.Date;
 
@Component
@Slf4j
public class MyLogGatewatFilter implements GlobalFilter, Ordered {
    
    
    //你要访问我时候需要一个指定的用户名才能进行访问，
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    
    
        log.info("************come in MyLogGatewatFilter "+ new Date());
        //判断是否携带uname的key
        String uname = exchange.getRequest().getQueryParams().getFirst("uname");
        //非法用户请离开
        if(uname==null){
    
    
            log.info("************用户名为null，非法用户");
            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
            return exchange.getResponse().setComplete();
        }
        //合法用户进行下一个过滤链进行过滤验证
        return chain.filter(exchange);
    }
    //这个0数字代表加载过滤器的顺序，就是越小优先级越高，因为是全局的，所以必须是第一位的。
    @Override
    public int getOrder() {
    
    
        return 0;
    }
}

このフィルタは主にアクセスされるパスです。パラメータ uname を指定する必要があります。自分で指定しない場合、検証は無効になり、エラーが報告され、アクセスできなくなります。のみ注文が書かれ、それが合法であれば、アクセスは成功します。テストのために http://localhost: 9527/payment/get/1?uname=zs にアクセスしてみましょう。成功は次のとおりです。

次に、パラメータなしでアクセスすると、次の図に示すように失敗します。

GlobalFilter の概要

Spring Cloud Gateway フレームワークに組み込まれている GlobalFilter は次のとおりです。

上図の各 GlobalFilter は各ルーター上で動作し、ほとんどの要件を満たすことができます。ただし、ビジネスのカスタマイズが発生した場合は、ニーズを満たす GlobalFilter を作成する必要がある場合があります。以下のケースでは、独自の GlobalFilter の書き方を説明します この GlobalFilter は、リクエストにリクエストパラメータ「token」が含まれているかどうかを検証します リクエストパラメータ「token」が含まれていない場合、ルートは転送されませんそれ以外の場合は、通常のロジックが実行されます。コードは以下のように表示されます。

public class TokenFilter implements GlobalFilter, Ordered {
    
    
 
    Logger logger=LoggerFactory.getLogger( TokenFilter.class );
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    
    
        String token = exchange.getRequest().getQueryParams().getFirst("token");
        if (token == null || token.isEmpty()) {
    
    
            logger.info( "token is empty..." );
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }
 
    @Override
    public int getOrder() {
    
    
        return -100;
    }
}
 

上記の TokenFilter は GlobalFilter インターフェイスと Ordered インターフェイスを実装する必要があります。これは GatewayFilter の実装と非常によく似ています。次に、ServerWebExchange に従って ServerHttpRequest を取得し、ServerHttpRequest にパラメーター トークンが含まれているかどうかに応じて、含まれていない場合はリクエストを完了して転送を終了し、そうでない場合は通常のロジックを実行します。

次に、プロジェクトのスタートアップ クラスの Spring Ioc コンテナに TokenFilter を挿入する必要があります。コードは次のとおりです。

@Bean
public TokenFilter tokenFilter(){
    
    
        return new TokenFilter();
}

プロジェクトを開始するには、curl コマンドを使用して以下を要求します。

 curl localhost:8081/customer/123

リクエストが転送されず、リクエストが終了し、次のログがコンソールに出力されることがわかります。

2018-11-16 15:30:13.543  INFO 19372 --- [ctor-http-nio-2] gateway.TokenFilter                      : token is empty...

上記のログは、リクエストが「トークン」を渡さないロジックに入ったことを示しています。

ここで Spring Cloud Gateway の学習は完了しました。とても簡単です。

次の記事では、Spring Cloud Config 分散構成センターについて学びます。記事は引き続き更新されます。ご注目ください。