Spring Cloud Gateway奪命連環10問？

大家好，我是不才陳某~

最近有很多小夥伴私信我催更 《Spring Cloud 進階》，陳某也總結了一下，最終原因就是陳某之前力求一篇文章將一個元件重要知識點講透，這樣導致了文章篇幅很長，寫的時間很長，小夥伴看的也累。

因此陳某決定後續的文章將每個元件拆分成不同的部分，每篇文章介紹一兩個知識點，這樣既能提高出文效率，小夥伴們也能更上進度及時的學習。

這是《Spring Cloud 進階》第七篇文章，往期文章如下：

• 五十五張圖告訴你微服務的靈魂擺渡者Nacos究竟有多強？
• openFeign奪命連環9問，這誰受得了？
• 阿里面試這樣問：Nacos、Apollo、Config配置中心如何選型？這10個維度告訴你！
• 阿里面試敗北：5種微服務註冊中心如何選型？這幾個維度告訴你！
• 阿里限流神器Sentinel奪命連環 17 問？
• 對比7種分散式事務方案，還是偏愛阿里開源的Seata，真香！(原理+實戰)

這篇文章介紹下微服務中的一個重要角色：閘道器，對於閘道器如何選擇，由於阿里系暫時未出閘道器，當然是選擇了Spring cloud Gateway，畢竟是親兒子。

文章目錄如下：

為什麼需要閘道器？

傳統的單體架構中只有一個服務開放給客戶端呼叫，但是微服務架構中是將一個系統拆分成多個微服務，那麼作為客戶端如何去呼叫這些微服務呢？如果沒有閘道器的存在，只能在本地記錄每個微服務的呼叫地址。

無閘道器的微服務架構往往存在以下問題：

• 客戶端多次請求不同的微服務，增加客戶端程式碼或配置編寫的複雜性。
• 認證複雜，每個服務都需要獨立認證。
• 存在跨域請求，在一定場景下處理相對複雜。

閘道器的基本功能？

閘道器是所有微服務的門戶，路由轉發僅僅是最基本的功能，除此之外還有其他的一些功能，比如：認證、鑑權、熔斷、限流、日誌監控等等.........

以上這些應用場景會在後續的文章詳細介紹，不是今天的重點。

為什麼選擇Spring cloud Gateway？

在1.x版本中都是採用的Zuul閘道器；但在2.x版本中，zuul的升級一直跳票，Spring Cloud最後自己研發了一個閘道器替代Zuul，那就是Spring Cloud Gateway。

肯定選擇親兒子Spring Cloud Gateway，它的很多思想都是借鑑zuul，所謂青出於藍而勝於藍，功能和效能肯定是優於zuul，不然Spring Cloud 為嘛要釋出它？

重要的一點原因：

Spring Cloud Gateway 基於Spring Boot 2.x、Spring WebFlux和[Project Reactor構建。

對於Spring Boot 的整合方便相容性以及效能方面不必擔心。

Spring Cloud Gateway幾個必知的術語？

1. 路由（route）：gateway的基本構建模組。它由ID、目標URI、斷言集合和過濾器集合組成。如果聚合斷言結果為真，則匹配到該路由。
2. 斷言（Predicate ）：參照Java8的新特性Predicate，允許開發人員匹配HTTP請求中的任何內容，比如頭或引數。
3. 過濾器（filter）：可以在返回請求之前或之後修改請求和響應的內容。

閘道器如何搭建？

為什麼要放這張圖？

一定要按照上圖中的版本進行適配，否則會出現意想不到的BUG，陳某遇到過，都是淚............

新建cloud-gateway9023，新增如下依賴：

<!--gateway-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

注意：一定要去掉spring-boot-starter-web依賴，否則啟動報錯

好了，專案搭建完成，其實就新增這麼一個依賴，關於詳細的配置下文介紹。

什麼是Predict（斷言）？

Predicate來自於java8的介面。Predicate接受一個輸入引數，返回一個布林值結果。該介面包含多種預設方法來將Predicate組合成其他複雜的邏輯（比如：與，或，非）。

可以用於介面請求引數校驗、判斷新老資料是否有變化需要進行更新操作。

Spring Cloud Gateway內建了許多Predict，這些Predict的原始碼在org.springframework.cloud.gateway.handler.predicate包中，有興趣可以閱讀一下。內建的一些斷言如下圖：

以上11種斷言陳某這裡就不再介紹如何配置了，官方文件寫的很清楚。

官方文件：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/

下面就以最後一種權重斷言為例介紹一下如何配置。配置如下：

spring:
  cloud:
    gateway:
      ## 路由
      routes:
        ## id只要唯一即可，名稱任意
        - id: gateway-provider_1
          uri: http://localhost:9024
          ## 配置斷言
          predicates:
            ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
            - Path=/gateway/provider/**
            ## Weight Route Predicate Factory，同一分組按照權重進行分配流量，這裡分配了80%
            ## 第一個group1是分組名，第二個引數是權重
            - Weight=group1, 8
            
        ## id必須唯一
        - id: gateway-provider_2
          ## 路由轉發的uri
          uri: http://localhost:9025
          ## 配置斷言
          predicates:
            ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
            - Path=/gateway/provider/**
            ## Weight Route Predicate Factory，同一分組按照權重進行分配流量，這裡分配了20%
            ## 第一個group1是分組名，第二個引數是權重
            - Weight=group1, 2

routes下就是配置的路由策略，各個元件如下：

• id：路由的唯一id，名稱任意
• uri：路由轉發的uri
• predicates：斷言配置，可以配置多個

Spring Cloud Gateway中的斷言命名都是有規範的，格式：xxxRoutePredicateFactory。

比如權重的斷言：WeightRoutePredicateFactory，那麼配置時直接取前面的Weight。

預設的路由轉發如果路由到了兩個，則是的按照配置先後順序轉發，上面都配置了路徑：Path=/gateway/provider/**，如果沒有配置權重，則肯定是轉發到http://localhost:9024。

但是既然配置配置了權重並且相同的分組，則按照權重比例進行分配流量。

什麼是過濾器？

過濾器這個概念很熟悉，在Spring mvc 就接觸過，Gateway的過濾器的作用以及生命週期都是類似的。

Gateway的生命週期：

• PRE：這種過濾器在請求被路由之前呼叫。我們可利用這種過濾器實現身份驗證、在叢集中選擇 請求的微服務、記錄除錯資訊等。
• POST：這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等。

Gateway 的Filter從作用範圍可分為兩種:

• GatewayFilter：應用到單個路由或者一個分組的路由上（需要在配置檔案中配置）。
• GlobalFilter：應用到所有的路由上（無需配置，全域性生效）

GatewayFilter（區域性過濾器）

Spring Cloud Gateway中內建了許多的區域性過濾器，如下圖：

區域性過濾器需要在指定路由配置才能生效，預設是不生效的。

以AddResponseHeaderGatewayFilterFactory這個過濾器為例，為原始響應新增Header，配置如下：

spring:
  cloud:
    gateway:
      ## 路由
      routes:
        ## id只要唯一即可，名稱任意
        - id: gateway-provider_1
          uri: http://localhost:9024
          ## 配置斷言
          predicates:
            ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
            - Path=/gateway/provider/**
          ## 配置過濾器（區域性）
          filters:
            - AddResponseHeader=X-Response-Foo, Bar

瀏覽器請求，發現響應頭中已經有了X-Response-Foo=Bar這個鍵值對，如下圖：

注意：過濾器的名稱只需要寫字首，過濾器命名必須是xxxGatewayFilterFactory（包括自定義）。

更多過濾器的配置可以看官方文件：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories

雖說內建的過濾器能夠解決很多場景，但是難免還是有些特殊需求需要定製一個過濾器，下面就來介紹一下如何自定義區域性過濾器。

場景：模擬一個授權驗證的過程，如果請求頭或者請求引數中攜帶token則放行，否則直接攔截返回401，程式碼如下：

/**
 * 名稱必須是xxxGatewayFilterFactory形式
 * todo：模擬授權的驗證，具體邏輯根據業務完善
 */
@Component
@Slf4j
public class AuthorizeGatewayFilterFactory extends AbstractGatewayFilterFactory<AuthorizeGatewayFilterFactory.Config> {

    private static final String AUTHORIZE_TOKEN = "token";

    //建構函式，載入Config
    public AuthorizeGatewayFilterFactory() {
        //固定寫法
        super(AuthorizeGatewayFilterFactory.Config.class);
        log.info("Loaded GatewayFilterFactory [Authorize]");
    }

    //讀取配置檔案中的引數 賦值到 配置類中
    @Override
    public List<String> shortcutFieldOrder() {
        //Config.enabled
        return Arrays.asList("enabled");
    }

    @Override
    public GatewayFilter apply(AuthorizeGatewayFilterFactory.Config config) {
        return (exchange, chain) -> {
            //判斷是否開啟授權驗證
            if (!config.isEnabled()) {
                return chain.filter(exchange);
            }

            ServerHttpRequest request = exchange.getRequest();
            HttpHeaders headers = request.getHeaders();
            //從請求頭中獲取token
            String token = headers.getFirst(AUTHORIZE_TOKEN);
            if (token == null) {
                //從請求頭引數中獲取token
                token = request.getQueryParams().getFirst(AUTHORIZE_TOKEN);
            }

            ServerHttpResponse response = exchange.getResponse();
            //如果token為空，直接返回401，未授權
            if (StringUtils.isEmpty(token)) {
                response.setStatusCode(HttpStatus.UNAUTHORIZED);
                //處理完成，直接攔截，不再進行下去
                return response.setComplete();
            }
            /**
             * todo chain.filter(exchange) 之前的都是過濾器的前置處理
             *
             * chain.filter().then(
             *  過濾器的後置處理...........
             * )
             */
            //授權正常，繼續下一個過濾器鏈的呼叫
            return chain.filter(exchange);
        };
    }

    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    public static class Config {
        // 控制是否開啟認證
        private boolean enabled;
    }
}

區域性過濾器需要在路由中配置才能生效，配置如下：

spring:
  cloud:
    gateway:
      ## 路由
      routes:
        ## id只要唯一即可，名稱任意
        - id: gateway-provider_1
          uri: http://localhost:9024
          ## 配置斷言
          predicates:
            ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
            - Path=/gateway/provider/**
          ## 配置過濾器（區域性）
          filters:
            - AddResponseHeader=X-Response-Foo, Bar
            ## AuthorizeGatewayFilterFactory自定義過濾器配置，值為true需要驗證授權，false不需要
            - Authorize=true

此時直接訪問：http://localhost:9023/gateway/provider/port，不攜帶token，返回如下圖：

請求引數帶上token：http://localhost:9023/gateway/provider/port?token=abcdcdecd-ddcdeicd12，成功返回，如下圖：

上述的AuthorizeGatewayFilterFactory只是涉及到了過濾器的前置處理，後置處理是在chain.filter().then()中的then()方法中完成的，具體可以看下專案原始碼中的TimeGatewayFilterFactory，程式碼就不再貼出來了，如下圖：

GlobalFilter（全域性過濾器）

全域性過濾器應用到全部路由上，無需開發者配置，Spring Cloud Gateway也內建了一些全域性過濾器，如下圖：

GlobalFilter的功能其實和GatewayFilter是相同的，只是GlobalFilter的作用域是所有的路由配置，而不是繫結在指定的路由配置上。多個GlobalFilter可以通過@Order或者getOrder()方法指定每個GlobalFilter的執行順序，order值越小，GlobalFilter執行的優先順序越高。

注意，由於過濾器有pre和post兩種型別，pre型別過濾器如果order值越小，那麼它就應該在pre過濾器鏈的頂層，post型別過濾器如果order值越小，那麼它就應該在pre過濾器鏈的底層。示意圖如下：

當然除了內建的全域性過濾器，實際工作中還需要定製過濾器，下面來介紹一下如何自定義。

場景：模擬Nginx的Access Log 功能，記錄每次請求的相關資訊。程式碼如下：

/**
 * 實現GlobalFilter
 */
@Slf4j
@Component
@Order(value = Integer.MIN_VALUE)
public class AccessLogGlobalFilter implements GlobalFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        //filter的前置處理
        ServerHttpRequest request = exchange.getRequest();
        String path = request.getPath().pathWithinApplication().value();
        InetSocketAddress remoteAddress = request.getRemoteAddress();
        return chain
                //繼續呼叫filter
                .filter(exchange)
                //filter的後置處理
                .then(Mono.fromRunnable(() -> {
            ServerHttpResponse response = exchange.getResponse();
            HttpStatus statusCode = response.getStatusCode();
            log.info("請求路徑:{},遠端IP地址:{},響應碼:{}", path, remoteAddress, statusCode);
        }));
    }
}

好了，全域性過濾器不必在路由上配置，注入到IOC容器中即可全域性生效。

此時發出一個請求，控制檯列印資訊如下：

請求路徑:/gateway/provider/port,遠端IP地址:/0:0:0:0:0:0:0:1:64114,響應碼:200 OK

如何整合註冊中心？

上述demo中並沒有整合註冊中心，每次路由配置都是指定固定的服務uri，如下圖：

這樣做有什麼壞處呢？

• 服務的IP的地址一旦修改了，路由配置中的uri必須修改
• 服務叢集中無法實現負載均衡

此時就需要整合的註冊中心，使得閘道器能夠從註冊中心自動獲取uri（負載均衡）。

這裡的註冊中心當然選擇Nacos，又不熟悉的小夥伴請看陳某《Spring Cloud 進階》專欄的第一篇文章：五十五張圖告訴你微服務的靈魂擺渡者Nacos究竟有多強？

pom檔案中新增Nacos依賴，如下：

<!--nacos註冊中心-->
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>

啟動類上開啟註冊中心功能，如下圖：

配置檔案中指定nacos註冊中心的地址：

spring:
  application:
    ## 指定服務名稱，在nacos中的名字
    name: cloud-gateway
  cloud:
    nacos:
      discovery:
        # nacos的服務地址，nacos-server中IP地址:埠號
        server-addr: 127.0.0.1:8848

路由配置中唯一不同的就是路由的uri，格式：lb://service-name，這是固定寫法：

• lb：固定格式，指的是從nacos中按照名稱獲取微服務,並遵循負載均衡策略
• service-name：nacos註冊中心的服務名稱，這裡並不是IP地址形式的

整合Nacos註冊中心完整的配置demo如下：

spring:
  application:
    ## 指定服務名稱，在nacos中的名字
    name: cloud-gateway
  cloud:
    nacos:
      discovery:
        # nacos的服務地址，nacos-server中IP地址:埠號
        server-addr: 127.0.0.1:8848
    gateway:
      ## 路由
      routes:
        ## id只要唯一即可，名稱任意
        - id: gateway-provider_1
        ## 使用了lb形式，從註冊中心負載均衡的獲取uri
          uri: lb://gateway-provider
          ## 配置斷言
          predicates:
            ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中
            - Path=/gateway/provider/**
          ## 配置過濾器（區域性）
          filters:
            - AddResponseHeader=X-Response-Foo, Bar

為什麼指定了lb就可以開啟負載均衡，前面說過全域性過濾器LoadBalancerClientFilter就是負責路由定址和負載均衡的，可以看到如下原始碼：

如何實現動態路由？

上述例子都是將閘道器的一系列配置寫到專案的配置檔案中，一旦路由發生改變必須要重新專案，這樣維護成本很高。

其實我們可以將閘道器的配置存放到配置中心中，這樣由配置中心統一管理，一旦路由發生改變，只需要在配置中心修改，這樣便能達到一處修改，多出生效的目的。

這裡當然要使用Nacos作為配置中心了，新增依賴如下：

<!--    nacos配置中心的依賴-->
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    </dependency>

在bootstrap.yml檔案中指定Nacos作為配置中心的一些相關配置：

spring:
  application:
    ## 指定服務名稱，在nacos中的名字
    name: cloud-gateway
  cloud:
    nacos:
      ## todo 此處作為演示，僅僅配置了字尾，其他分組，名稱空間根據需要自己配置
      config:
        server-addr: 127.0.0.1:8848
        ## 指定檔案字尾未yaml
        file-extension: yaml

在nacos中的public名稱空間中建立dataId為cloud-gateway.yaml的配置（未指定環境），配置內容如下：

到這裡已經配置完成了。至於效果自己動動小手試試吧...............

如何自定義全域性異常處理？

通過前面的測試可以看到一個現象：一旦路由的微服務下線或者失聯了，Spring Cloud Gateway直接返回了一個錯誤頁面，如下圖：

顯然這種異常資訊不友好，前後端分離架構中必須定製返回的異常資訊。

傳統的Spring Boot 服務中都是使用@ControllerAdvice 來包裝全域性異常處理的，但是由於服務下線，請求並沒有到達。

因此必須在閘道器中也要定製一層全域性異常處理，這樣才能更加友好的和客戶端互動。

Spring Cloud Gateway提供了多種全域性處理的方式，今天陳某隻介紹其中一種方式，實現還算比較優雅。

直接建立一個類GlobalErrorExceptionHandler，實現ErrorWebExceptionHandler，重寫其中的handle方法，程式碼如下：

/**
 * 用於閘道器的全域性異常處理
 * @Order(-1)：優先順序一定要比ResponseStatusExceptionHandler低
 */
@Slf4j
@Order(-1)
@Component
@RequiredArgsConstructor
public class GlobalErrorExceptionHandler implements ErrorWebExceptionHandler {

	private final ObjectMapper objectMapper;

	@SuppressWarnings({"rawtypes", "unchecked", "NullableProblems"})
	@Override
	public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
		ServerHttpResponse response = exchange.getResponse();
		if (response.isCommitted()) {
			return Mono.error(ex);
		}

		// JOSN格式返回
		response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
		if (ex instanceof ResponseStatusException) {
			response.setStatusCode(((ResponseStatusException) ex).getStatus());
		}

		return response.writeWith(Mono.fromSupplier(() -> {
			DataBufferFactory bufferFactory = response.bufferFactory();
			try {
				//todo 返回響應結果，根據業務需求，自己定製
				CommonResponse resultMsg = new CommonResponse("500",ex.getMessage(),null);
				return bufferFactory.wrap(objectMapper.writeValueAsBytes(resultMsg));
			}
			catch (JsonProcessingException e) {
				log.error("Error writing response", ex);
				return bufferFactory.wrap(new byte[0]);
			}
		}));
	}
}

好了，全域性異常處理已經定製完成了，在測試一下，此時正常返回JSON資料了，如下圖：

JSON的樣式根據架構需要自己定製。

總結

Spring Cloud Gateway今天就分享到這裡，主要介紹了以下幾個知識點：

• 為什麼需要閘道器？閘道器的基本功能
• 如何從零搭建一個微服務閘道器
• Predict（斷言）的概念
• 過濾器的概念、Spring Cloud Gateway內建的過濾器以及如何自定義
• 如何整合Nacos註冊中心並且實現負載均衡
• 如何整合Nacos實現動態路由，達到一處修改，多出生效的作用
• 全域性異常的處理

你認為Spring Cloud Gateway就介紹完了？不可能，後續還有更深入以及實戰的介紹，下篇文章介紹.....

專案原始碼已經上傳Github，公號【碼猿技術專欄】回覆關鍵詞：9528獲取！

最後說一句（求關注，別白嫖我）

陳某每一篇原創文章都是精心輸出，尤其是《Spring Cloud 進階》專欄的文章，知識點太多，要想講的細，必須要花很多時間準備，從知識點到原始碼demo。

如果這篇文章對你有所幫助，或者有所啟發的話，幫忙點贊、在看、轉發、收藏，你的支援就是我堅持下去的最大動力！