Spring Cloud Gateway - 擴展

[TOC]

---

Spring Cloud Gateway的監控端點

說到監控，就應該能想到Spring Boot Actuator。而Spring Cloud Gateway基於Actuator提供了許多的監控端點。只需要在項目中添加spring-boot-starter-actuator依賴，並將 gateway 端點暴露，即可獲得若干監控端點。配置示例：

management:
  endpoints:
    web:
      exposure:
        include: gateway  # 或者配置“*”暴露全部端點

Spring Cloud Gateway的監控端點如下表：

端點	請求方法	描述
globalfilters	GET	展示所有的全局過濾器信息
routefilters	GET	展示所有的過濾器工廠信息
refresh	POST（無消息體）	清空路由緩存，即刷新路由信息
routes	GET	展示所有的路由信息列表
routes/{id}	GET	展示指定id的路由的信息
routes/{id}	POST（有消息體）	新增一個路由
routes/{id}	DELETE（無消息體）	刪除一個路由

Gateway所有的監控端點都掛載在 /actuator/gateway 路徑下，例如globalfilters端點的完整訪問路徑是 /actuator/gateway/globalfilters。該端點主要是查看Gateway啓用了哪些全局過濾器以及它們的執行順序（數字越小越優先執行）。所以當我們不知道Gateway啓用了哪些全局過濾器，或者不知道這些全局過濾器的執行順序，就可以訪問該端點進行查看：

同理，如果不知道Gateway啓用了哪些過濾器工廠，則可以訪問routefilters端點查看：

若想知道Gateway裏定義了哪些路由又不想查看配置文件的話，那麼就可以通過routes端點查看所有的路由信息列表：

如果出現自定義的路由配置不生效或行爲與預期不符，那麼可以通過routes/{id}端點查看該路由具體的詳細信息：

routes/{id}端點還可以用於動態添加路由，只需發送POST請求並定義一個消息體即可。消息體示例：

{
  "predicates": [
    {
      "name": "Path",
      "args": {
        "_genkey_0": "/test"
      }
    }
  ],
  "filters": [
    {
      "name": "AddRequestHeader",
      "args": {
        "_genkey_0": "X-Request-Foo",
        "_genkey_1": "Bar"
      }
    },
    {
      "name": "PreLog",
      "args": {
        "_genkey_0": "a",
        "_genkey_1": "b"
      }
    }
  ],
  "uri": "https://www.example.com",
  "order": 0
}

消息體其實是有規律的，你可以先在配置文件中配置一個路由規則，然後訪問 routes 端點，route_definition字段裏的內容就是消息體，如下：

接下來我們實際測試一下，複製該消息體，然後稍微修改一下並進行發送，如下：

路由添加成功後，訪問 routes 端點，就可以看到新添加的路由：

注：如果沒有實時生效，使用 refresh 端點刷新一下路由信息即可

官方文檔：

• Gateway Actuator API

---

關於Gateway的調試、排錯

1、Gateway的監控端點：

上一小節介紹了Gateway的監控端點，這些監控端點可以幫助我們分析全局過濾器、過濾器工廠、路由詳情等

2、日誌：

設置一些相關包的日誌級別，打印更詳細的日誌信息，可按需將如下包的日誌級別設置成 debug 或 trace：

• org.springframework.cloud.gateway
• org.springframework.http.server.reactive
• org.springframework.web.reactive
• org.springframework.boot.autoconfigure.web
• reactor.netty
• redisratelimiter

配置示例：

logging:
  level:
    org.springframework.cloud.gateway: trace

3、Wiretap Logger【需Greenwich SR3及更高版本纔會支持】：

Reactor Netty的 HttpClient 以及 HttpServer 可啓用 Wiretap。需將 reactor.netty 包設置成 debug 或 trace ，然後在配置文件中添加如下配置：

• spring.cloud.gateway.httpserver.wiretap=true：開啓 HttpServer 的Wiretap
• spring.cloud.gateway.httpclient.wiretap=true：開啓 HttpClient 的Wiretap

wiretap其實是Reactor Netty的概念，用於打印對端之間的流量詳情，相關文檔：

• HttpClient Wire Logger
• HttpServer Wire Logger

---

過濾器執行順序

我們都知道全局過濾器使用@Order 註解或實現 Ordered 接口來配置一個決定執行順序的數字，該數字越小的過濾器越靠前執行。

但是在路由規則上所配置的過濾器工廠並沒有配置類似Order之類的東西，那麼是如何決定執行順序的呢？其實，過濾器工廠默認也會被設置一個Order，該Order按配置順序從1開始遞增，也是Order越小越靠前執行。如下：

routes:
  - id: test-route
    uri: lb://user-center
    predicates:
      - TimeBetween=上午9:00,下午5:00
    filters:
      # 按配置順序從1開始遞增
      - AddRequestHeader=Y-Header, Bar    # Order爲1
      - AddResponseHeader=X-Header, Bar   # Order爲2
      - PreLog=testName,testValue         # Order爲3

使用default-filters配置的默認過濾器也是同理，但如果配置了默認過濾器，則會先執行相同Order的默認過濾器：

default-filters: 
  - AddRequestHeader=Y-Foo, Bar    # Order爲1
  - AddResponseHeader=X-Foo, Bar   # Order爲2
routes:
  - id: test-route
    uri: lb://user-center
    predicates:
      - TimeBetween=上午9:00,下午5:00
    filters:
      # 按配置順序從1開始遞增
      - AddRequestHeader=Y-Header, Bar    # Order爲1
      - AddResponseHeader=X-Header, Bar   # Order爲2
      - PreLog=testName,testValue         # Order爲3

如需自行控制過濾器工廠的Order，可返回OrderedGatewayFilter，如下示例：

@Slf4j
@Component
public class PreLogGatewayFilterFactory extends AbstractNameValueGatewayFilterFactory {

    @Override
    public OrderedGatewayFilter apply(NameValueConfig config) {
        return new OrderedGatewayFilter((exchange, chain) -> {
            ...
            return chain.filter(exchange);
        }, -1);
    }
}

核心代碼:

• org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#loadGatewayFilters：爲過濾器設置了Order 數值，從1開始
• org.springframework.cloud.gateway.route. RouteDefinitionRouteLocator#getFilters：加載默認過濾器 & 路由過濾器，並對過濾器做了排序
• org.springframework.cloud.gateway.handler.FilteringWebH .andler#handle：構建過濾器鏈並執行

---

Spring Cloud Gateway跨域配置

Gateway支持CORS相關配置，可以通過不同的URL規則匹配不同的CORS策略。配置示例：

spring:
  cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/**]':
            allowedOrigins: "http://docs.spring.io"
            allowedMethods:
            - GET

除此之外，還可以通過自定義過濾器來解決跨域問題，具體代碼如下：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.reactive.CorsWebFilter;
import org.springframework.web.cors.reactive.UrlBasedCorsConfigurationSource;
import org.springframework.web.util.pattern.PathPatternParser;

@Configuration
public class CorsConfig {

    @Bean
    public CorsWebFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedMethod("*");
        config.addAllowedOrigin("*");
        config.addAllowedHeader("*");

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(new PathPatternParser());
        source.registerCorsConfiguration("/**", config);

        return new CorsWebFilter(source);
    }
}

---

Spring Cloud Gateway限流相關

在高併發的系統中，限流往往是一個繞不開的話題，我們都知道網關是流量的入口，所以在網關上做限流也是理所當然的。Spring Cloud Gateway內置了一個過濾器工廠，用於提供限流功能，這個過濾器工廠就是是RequestRateLimiterGatewayFilterFactory，該過濾器工廠基於令牌桶算法實現限流功能。

目前，該過濾器工廠默認使用 RedisRateLimiter 作爲限速器，需要依賴Redis來存儲限流配置，以及統計數據等。當然你也可以實現自己的RateLimiter，只需實現 org.springframework.cloud.gateway.filter.ratelimit.RateLimiter 接口，或者繼承 org.springframework.cloud.gateway.filter.ratelimit.AbstractRateLimiter抽象類

Tips：

Redis Rate Limiter的實現基於這篇文章：Scaling your API with rate limiters
Spring官方引用的令牌桶算法文章：Token bucket

關於令牌桶之類的限流算法可以參考另一篇文章，這裏就不過多贅述了：

• 應用限流及其常見算法

---

動手實踐

1、添加Redis依賴：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>

2、添加如下配置：

spring:
  cloud:
    gateway:
      routes:
        - id: user-center
          uri: lb://user-center
          predicates:
            - Path=/user-center/**
          filters:
            - StripPrefix=1
            - name: RequestRateLimiter
              args:
                # 令牌桶每秒填充平均速率
                redis-rate-limiter.replenishRate: 1
                # 令牌桶的上限
                redis-rate-limiter.burstCapacity: 2
                # 使用SpEL表達式從Spring容器中獲取Bean對象
                key-resolver: "#{@pathKeyResolver}"
  # redis相關              
  redis:
    host: 127.0.0.1
    port: 6379

3、編寫一個KeyResolver，用於定義針對什麼進行限流。例如按照訪問路徑限流，就寫一個針對訪問路徑的KeyResolver；按照請求參數限流，那就寫一個針對請求參數的KeyResolver，以此類推。這裏我們按照訪問路徑限流，具體實現代碼如下：

@Configuration
public class RaConfiguration {

    /**
     * 按照Path限流
     *
     * @return key
     */
    @Bean
    public KeyResolver pathKeyResolver() {
        return exchange -> Mono.just(
                exchange.getRequest()
                        // 獲取path
                        .getPath()
                        .toString()
        );
    }
}

從代碼的實現不難看出，實際就只是返回了一個訪問路徑，這樣限流規則就會作用到訪問路徑上。例如訪問：http://${GATEWAY_URL}/users/1，對於這個路徑，它的redis-rate-limiter.replenishRate = 1，redis-rate-limiter.burstCapacity = 2。

訪問：http://${GATEWAY_URL}/shares/1，對於這個路徑，它的redis-rate-limiter.replenishRate = 1，redis-rate-limiter.burstCapacity = 2；以此類推......

測試

接下來進行一個簡單的測試，看看限流是否起作用了。持續頻繁訪問某個路徑，當令牌桶的令牌被消耗完了，就會返回 429 這個HTTP狀態碼。如下：

然後迅速查看Redis中存儲的key，會發現其格式如下：

從key的格式可以看出來，實際上 KeyResolver 的目的就是用來獲取一個請求的唯一標識（這個標識可以是訪問路徑，可以是某個請求參數，總之就是可以從這個請求裏獲取出來的東西），並用其生成key以及解析key，以此實現針對性的限流。

拓展

如果請求會攜帶一個名爲user的參數，其值爲用戶名，那麼我們就可以通過這個請求參數來實現針對用戶的限流。如下：

@Bean
public KeyResolver userKeyResolver() {
    return exchange -> Mono.just(
        exchange.getRequest()
            .getQueryParams()
            .getFirst("user")
    );
}

同理，我們還可以針對請求的來源IP進行限流。如下：

@Bean
public KeyResolver ipKeyResolver() {
    return exchange -> Mono.just(
      exchange.getRequest()
          .getHeaders()
          .getFirst("X-Forwarded-For")
    );
}