微服务网关：Gateway 中的路由和谓词有何应用？

 微服务网关：Gateway 中的路由和谓词有何应用？

在上篇文章中，我们了解了 Spring Cloud Gateway 网关在微服务架构中的定位，我还介绍了 Gateway 的三大核心组件路由、谓词和过滤器的基本概念。

今天，就来进一步认识 Gateway 的内置功能，了解在 Gateway 中如何声明一个路由，以及路由中的谓词判断逻辑有什么作用。Spring Cloud Gateway（以下简称 Gateway）提供了非常丰富的内置谓词，你可以通过内置谓词来构建复杂的路由条件，甚至连“整点秒杀”这个场景都能在网关层做控制。这些内置谓词就像乐高积木一样，你可以随意组合在自己的业务逻辑中，构建五花八门的网关层判断逻辑。

如果这还不够，那么 Gateway 还提供了自定义的谓词工厂扩展点，让你构建自定义谓词。由于这些个谓词都要附着于一个路由之上，所以在介绍谓词之前，我得先和你聊一下怎么声明一个路由。这一节不涉及微服务项目改造，只是让你能够用最直观的方式体验 Gateway 的功能特点。

声明路由的几种方式

在上一篇文章中我们讲到，路由是 Gateway 中的一条基本转发规则。网关在启动的时候，必须将这些路由规则加载到上下文中，它才能正确处理服务转发请求。那么网关可以从哪些地方加载路由呢？

Gateway 提供了三种方式来加载路由规则，分别是 Java 代码、yaml 文件和动态路由。让我们先来一睹为快，近距离感受一下这三种风格迥异的加载方式。第一种加载方式是 Java 代码声明路由，它是可读性和可维护性最好的方式，也是我比较喜欢使用的方式。

你可以使用一种链式编程的 Builder 风格来构造一个 route 对象，比如在下面的例子里，相信就算我不解释，你也能看明白这段代码做的事情。它声明了两个路由，根据 path 的匹配规则将请求转发到不同的地址。

@Bean
public RouteLocator declare(RouteLocatorBuilder builder) {
    return builder.routes()
            .route("id-001", route -> route
                    .path("/geekbang/**")
                    .uri("http://time.geekbang.org")
            ).route(route -> route
                    .path("/test/**")
                    .uri("http://www.test.com")
            ).build();
}

第二种方式是通过配置文件来声明路由，你可以在 application.yml 文件中组装路由规则。我把前面定义的 Java 路由规则改写成了 yml 版，你可以参考一下。

spring:
  cloud:
    gateway:
      routes:
        - id: id-001
          uri: http://time.geekbang.org
          predicates:
            - Path=/geekbang2/**
        - uri: http://www.test.com
          predicates:
            - Path=/test2/**

不管是 Java 版还是 yml 版，它们都是通过“hardcode”的方式声明的静态路由规则，这些 Route 只会在项目启动后被加载一次。如果你想要在 Gateway 运行期更改路由逻辑，那么就要使用第三种方式：动态路由加载。

动态路由也有不同的实现方式。如果你在项目中集成了 actuator 服务，那么就可以通过 Gateway 对外开放的 actuator 端点在运行期对路由规则做增删改查。但这种修改只是临时性的，项目重新启动后就会被打回原形，因为这些动态规则并没有持久化到任何地方。

动态路由还有另一种实现方式，是比较推荐的，那就是借助 Nacos 配置中心来存储路由规则。Gateway 通过监听 Nacos Config 中的文件变动，就可以动态获取 Nacos 中配置的规则，并在本地生效了。

Gateway 的内置谓词都有哪些

Gateway 的内置谓词可真不少，我这里捡一些比较常用的谓词，为你介绍下它们的用法。我把这些谓词大致分为三个类型：寻址谓词、请求参数谓词和时间谓词。我将使用基于 Java 代码的声明方式，带你挨个来看下如何在路由中配置谓词。

寻址谓词，顾名思义，就是针对请求地址和类型做判断的谓词条件。比如这里我们用到的 path，其实就是一个路径匹配条件，当请求的 URL 和 Path 谓词中指定的模式相匹配的时候，这个谓词就会返回一个 True 的判断。而 method 谓词则是根据请求的 Http Method 做为判断条件，比如我这里就限定了只有 GET 和 POST 请求才能访问当前 Route。

.route("id-001", route -> route
      .path("/test/**")
      .and().method(HttpMethod.GET, HttpMethod.POST)
      .uri("http://time.test.org")

在上面这段代码中，我添加了不止一个谓词。在谓词与谓词之间，你可以使用 and、or、negate 这类“与或非”逻辑连词进行组合，构造一个复杂判断条件。

接下来是请求参数谓词，这类谓词主要对服务请求所附带的参数进行判断。这里的参数不单单是 Query 参数，还可以是 Cookie 和 Header 中包含的参数。比如下面这段代码，如果请求中没有包含指定参数，或者指定参数的值和我指定的 regex 表达式不匹配，那么请求就无法满足当前路由的谓词判断条件。

.route("id-001", route -> route
    // 验证cookie
    .cookie("myCookie", "regex")
    // 验证header
    .and().header("myHeaderA")
    .and().header("myHeaderB", "regex")
    // 验证param
    .and().query("paramA")
    .and().query("paramB", "regex")
    .and().remoteAddr("远程服务地址")
    .and().host("pattern1", "pattern2")

如果你要对原始服务请求的远程地址或 Header 中的 Host 参数做些文章，那么你也可以通过 remoteAddr 和 host 谓词进行判断。

在实际项目中，非必要情况下，我并不推荐把过多的参数谓词条件定义在网关层，因为这些参数往往携带了业务层的逻辑。如果这些业务参数被大量引入到网关层，从职责分离的角度来讲，并不合适。

网关层的逻辑一般来说比较“轻薄”，主要只是一个请求转发，最多再夹带一些简单的鉴权和登录态检查就够了。

最后一组是时间谓词。你可以借助 before、after、between 这三个时间谓词来控制当前路由的生效时间段。

.route("id-001", route -> route
   // 在指定时间之前
   .before(ZonedDateTime.parse("2022-12-25T14:33:47.789+08:00"))
   // 在指定时间之后
   .or().after(ZonedDateTime.parse("2022-12-25T14:33:47.789+08:00"))
   // 或者在某个时间段以内
   .or().between(
        ZonedDateTime.parse("起始时间"),
        ZonedDateTime.parse("结束时间"))

拿一项秒杀活动来说，如果开发团队做了一个新的秒杀下单入口，我要限定该入口的生效时间在秒杀时间点之后，那么我就可以使用 after 谓词。对于固定时间窗口的秒杀活动来说，你还可以使用 between 来限定生效时间窗口。再结合前面我们讲到的请求参数谓词，你还可以实现更加复杂的路由判断逻辑，比如通过 query 谓词针对特定商品开放不同的秒杀时段。

如果 Gateway 的内置谓词还差那么点意思，你想要实现自定义的谓词逻辑，那么你可以通过 Gateway 的可扩展谓词工厂来实现自定义谓词。Gateway 组件提供了一个统一的抽象类 AbstractRoutePredicateFactory 作为谓词工厂，你可以通过继承这个类来添加新的谓词逻辑。

我把实现一个自定义谓词的代码框架放到了这里，你可以参考一下。

// 继承自通用扩展抽象类AbstractRoutePredicateFactory
public class MyPredicateFactory extends 
    AbstractRoutePredicateFactory<MyPredicateFactory.Config> {

   public MyPredicateFactory() {
      super(Config.class);
   }
   
   // 定义当前谓词所需要用到的参数
   @Validated
   public static class Config {
       private String myField;
   }
   
   @Override
   public List<String> shortcutFieldOrder() {
      // 声明当前谓词参数的传入顺序
      // 参数名要和Config中的参数名称一致
      return Arrays.asList("myField");
   }
   
   // 实现谓词判断的核心方法
   // Gateway会将外部传入的参数封装为Config对象
   @Override
   public Predicate<ServerWebExchange> apply(Config config) {
      return new GatewayPredicate() {
      
         // 在这个方法里编写自定义谓词逻辑
         @Override
         public boolean test(ServerWebExchange exchange) {
            return true;
         }
         
         @Override
         public String toString() {
            return String.format("myField: %s", config.myField);
         }
      };
   }
}

这个实现的过程非常简单，相信看了上面的源码就能明白。这里面的关键步骤就两步，

• 一是定义 Config 结构来接收外部传入的谓词参数，
• 二是实现 apply 方法编写谓词判断逻辑。

我将会留一道课后作业让你自己动手实现一个专属谓词。

到这里，我们就了解了 Gateway 的路由和谓词是如何完成请求转发的。