Spring Cloud Gateway奪命連環十問?
                    這篇文章介紹下微服務中的一個重要角色:網關,對於網關如何選擇,由於阿里系暫時未出網關,當然是選擇了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幾個必知的術語?
- 路由(route):gateway的基本構建模塊。它由ID、目標URI、斷言集合和過濾器集合組成。如果聚合斷言結果為真,則匹配到該路由。
 - 斷言(Predicate ):參照Java8的新特性Predicate,允許開發人員匹配HTTP請求中的任何內容,比如頭或參數。
 - 過濾器(filter):可以在返回請求之前或之後修改請求和響應的內容。
 
網關如何搭建?

為什麼要放這張圖?
一定要按照上圖中的版本進行適配,否則會出現意想不到的BUG,陳某遇到過,都是淚............
新建cloud-gateway9023,添加如下依賴:
<!--gateway-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 
注意:一定要去掉spring-boot-starter-web依賴,否則啟動報錯

好了,項目搭建完成,其實就添加這麼一個依賴,關於詳細的配置下文介紹。
什麼是Predict(斷言)?
Predicate來自於java8的接口。Predicate接受一個輸入參數,返回一個布爾值結果。該接口包含多種默認方法來將Predicate組合成其他復雜的邏輯(比如:與,或,非)。關注公z號:碼猿技術專欄,回復關鍵詞:1111 獲取阿里內部性能調優手冊!
可以用於接口請求參數校驗、判斷新老數據是否有變化需要進行更新操作。
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- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 - 18.
 - 19.
 - 20.
 - 21.
 - 22.
 - 23.
 - 24.
 - 25.
 - 26.
 - 27.
 
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:
            - AddRespnotallow=X-Response-Foo, Bar- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 
瀏覽器請求,發現響應頭中已經有了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;
    }
}- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 - 18.
 - 19.
 - 20.
 - 21.
 - 22.
 - 23.
 - 24.
 - 25.
 - 26.
 - 27.
 - 28.
 - 29.
 - 30.
 - 31.
 - 32.
 - 33.
 - 34.
 - 35.
 - 36.
 - 37.
 - 38.
 - 39.
 - 40.
 - 41.
 - 42.
 - 43.
 - 44.
 - 45.
 - 46.
 - 47.
 - 48.
 - 49.
 - 50。
 - 51.
 - 52.
 - 53.
 - 54.
 - 55.
 - 56.
 - 57.
 - 58.
 - 59.
 - 60.
 - 61.
 - 62.
 - 63.
 - 64.
 - 65.
 - 66.
 - 67.
 - 68.
 
局部過濾器需要在路由中配置才能生效,配置如下:
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:
            - AddRespnotallow=X-Response-Foo, Bar
            ## AuthorizeGatewayFilterFactory自定义过滤器配置,值为true需要验证授权,false不需要
            - Authorize=true- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 
此時直接訪問: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);
        }));
    }
}- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 - 18.
 - 19.
 - 20.
 - 21.
 - 22.
 - 23.
 - 24.
 - 25.
 
好了,全局过滤器不必在路由上配置,注入到IOC容器中即可全局生效。
此时发出一个请求,控制台打印信息如下:
请求路径:/gateway/provider/port,远程IP地址:/0:0:0:0:0:0:0:1:64114,响应码:200 OK- 1.
 
如何集成注册中心?
上述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>- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 
启动类上开启注册中心功能,如下图:

配置文件中指定nacos注册中心的地址:
spring:
  application:
    ## 指定服务名称,在nacos中的名字
    name: cloud-gateway
  cloud:
    nacos:
      discovery:
        # nacos的服务地址,nacos-server中IP地址:端口号
        server-addr: 127.0.0.1:8848- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 
路由配置中唯一不同的就是路由的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:
            - AddRespnotallow=X-Response-Foo, Bar- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 - 18.
 - 19.
 - 20.
 - 21.
 - 22.
 - 23.
 
为什么指定了lb就可以开启负载均衡,前面说过全局过滤器LoadBalancerClientFilter就是负责路由寻址和负载均衡的,可以看到如下源码:

如何实现动态路由?
上述例子都是将网关的一系列配置写到项目的配置文件中,一旦路由发生改变必须要重新项目,这样维护成本很高。
其实我们可以将网关的配置存放到配置中心中,这样由配置中心统一管理,一旦路由发生改变,只需要在配置中心修改,这样便能达到一处修改,多出生效的目的。
这里当然要使用Nacos作为配置中心了,添加依赖如下:
<!--    nacos配置中心的依赖-->
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    </dependency>- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 
在bootstrap.yml文件中指定Nacos作为配置中心的一些相关配置:
spring:
  application:
    ## 指定服务名称,在nacos中的名字
    name: cloud-gateway
  cloud:
    nacos:
      ## todo 此处作为演示,仅仅配置了后缀,其他分组,命名空间根据需要自己配置
      config:
        server-addr: 127.0.0.1:8848
        ## 指定文件后缀未yaml
        file-extension: yaml- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 
在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]);
   }
  }));
 }
}- 1.
 - 2.
 - 3.
 - 4.
 - 5.
 - 6.
 - 7.
 - 8.
 - 9.
 - 10.
 - 11.
 - 12.
 - 13.
 - 14.
 - 15.
 - 16.
 - 17.
 - 18.
 - 19.
 - 20.
 - 21.
 - 22.
 - 23.
 - 24.
 - 25.
 - 26.
 - 27.
 - 28.
 - 29.
 - 30.
 - 31.
 - 32.
 - 33.
 - 34.
 - 35.
 - 36.
 - 37.
 - 38.
 - 39.
 - 40.
 
好了,全局异常处理已经定制完成了,在测试一下,此时正常返回JSON数据了,如下图:

JSON的样式根据架构需要自己定制。
总结
Spring Cloud Gateway今天就分享到这里,主要介绍了以下几个知识点:
- 为什么需要网关?网关的基本功能
 - 如何从零搭建一个微服务网关
 - Predict(断言)的概念
 - 过滤器的概念、Spring Cloud Gateway内置的过滤器以及如何自定义
 - 如何集成Nacos注册中心并且实现负载均衡
 - 如何集成Nacos实现动态路由,达到一处修改,多出生效的作用
 - 全局异常的处理
 
你认为Spring Cloud Gateway就介绍完了?不可能,后续还有更深入以及实战的介绍,下篇文章介绍.....