深度剖析Gateway在微服务治理中的关键角色

一、多层网关

二、Gateway 路由规则

2.1 路由

2.2 谓词

2.3 过滤器

三、路由声明规则

3.1 谓词

寻址谓词

请求参数谓词

时间谓词

自定义谓词

一、多层网关

首先我们先了解下一个请求是如何到达服务端并得到相应的。过程如图所示：

首先网址解析的第一步是 DNS 解析。当用户在浏览器输入网址后，这个网址会被 DNS 层解析成一个可被访问的 IP 地址。为了避免单点故障，可以在这一层加双保险，比如将域名映射成多个 IP 地址做主备，又或者根据用户 IP 所属区域做 Loadbanacer，将请求导向就近的 IP 地址。

每一个 IP 地址只是所谓的虚 IP，后面会映射到一个大型的网关集群，这个集群便是我们业务系统外的第一道网关。在这个环节，使用最广泛而且最经济实惠技术选型就是 Nginx 反向代理。因为它拥有超强的并发能力，而且很节省内存资源。

一个请求抵达最外层的 Nginx 服务之后，还可能会经历多级 LVS+Nginx 集群的转发。大公司之所以这么做，主要是出于对网络安全的考虑。他们往往会根据业务系统的属性和安全级别来设置不同的网络分区，而这些网络分区之间是相互独立的，分区之间需要开通白名单或者防火墙才能打通连接。比如有的网络分区可以直接对外，而有的高安全级别的分区（比如金融类业务）则部署在更底层。这就和我们使用跳板机访问线上机房是一个道理。

然后，请求经过了多级网关服务的转发，抵达了最后的微服务层。在这一层上，Gateway 就需要出马来负责请求转发了。

Gateway 既然叫“微服务网关”，就说明它自己就是一个微服务。换句话说，它也是 Nacos服务注册中心的一员。既然 Gateway 能连接到 Nacos，那么就意味着它可以轻松获取到 Nacos中所有服务的注册表。这样一来，Gateway 就可以根据本地的路由规则，将请求精准无误地送达到每个微服务组件中。

使用 Gateway 有一个显而易见的好处，那就是高可扩展性。当你对后台的微服务集群做扩容或缩容的时候，Gateway 可以从 Nacos 注册中心轻松获取所有服务节点的变动，不需要任何额外的配置，一切都在无感知的情况下自然而然地发生。如果使用其他技术方案，你可能还需要花些力气修改节点列表，将新增的机器手动添加到列表中，还要把移除的机器从列表中删除。

二、Gateway 路由规则

Gateway 的路由规则主要有三个部分，分别是路由、谓词和过滤器。如下图：

2.1 路由

路由是 Gateway 的一个基本单元，路由都有一个目标地址，这个目标地址就是当前路由规则要调用的目标服务。那么一条路由规则在什么情况下会调用目标服务呢？这就看路由的谓词设置了。

2.2 谓词

所谓谓词，实际上就是路由的判断规则，一个路由中可以添加多个谓词组合。如果一个服务请求满足某个路由里所有谓词规则，这时 Gateway 就会把请求转发到设置的目标地址。

打个比方，你可以为某个路由设置一条谓词规则，约定访问路径的匹配规则为 Path=/user/*，在这种情况下只有以 /user 打头的请求才会被当前路由选中。

Gateway 为我们提供了非常丰富的内置谓词，你可以通过内置谓词构建复杂的路由条件，甚至连“整点秒杀”这个场景都能在网关层做控制。

2.3 过滤器

过滤器和路由、目标地址之间是什么关系呢？其实 Gateway 在把请求转发给目标地址的过程中，把这个任务全权委托给了 Filter（过滤器）来处理。如下图：

Gateway 组件使用了一种 FilterChain 的模式对请求进行处理，每一个服务请求（Request）在发送到目标服务之前都要被一串 FilterChain 处理。同理，在 Gateway 接收服务响应（Response）的过程中也会被 FilterChain 处理一把。

Gateway 的过滤器主要分为两种，一种是 GlobalFilter，也就是“全局过滤器”；另一种是 GatewayFilter，也就是对指定路由生效的“局部过滤器”。

Gateway 还有一系列用来做路径转发、请求跨域、WebSocket、WebClient 和 Loadbalancer 功能支持的全局过滤器。

三、路由声明规则

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

Gateway 提供了三种方式来加载路由规则，分别是 Java 代码、ymal 文件和动态路由。

第一种加载方式是 Java 代码声明路由，它是可读性和可维护性最好的方式，可以使用一种链式编程的 Builder 风格来构造一个 route 对象，比如在下面的例子里。它声明了两个路由，根据 path 的匹配规则将请求转发到不同的地址。

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

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

spring:
  cloud:
    gateway:
      httpclient:
        connect-timeout: 30000
        response-timeout: 30s
      routes:
      - id: user
        uri: http://user.test.com
        predicates:
        - Path=/user/**
        filters:
        - name: HttpPostBodyEnhance
        - name: RequestRateLimiter
          args:
            redis-rate-limiter.replenishRate: 1000
            redis-rate-limiter.burstCapacity: 1000
            redis-rate-limiter.requestedTokens: 1
            key-resolver: '#{@uriKeyResolver}'
        metadata:
          response-timeout: 20000
          connect-timeout: 20000
      - id: product
        uri: http://product.test.com
        predicates:
        - Path=/product/**
        metadata:
          response-timeout: 120000
          connect-timeout: 120000

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

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

动态路由还有另一种实现方式，那就是借助 Nacos 配置中心来存储路由规则。Gateway 通过监听 Nacos Config 中的文件变动，就可以动态获取 Nacos 中配置的规则，并在本地生效了。我将在后面的课程中带你落地一套 Nacos+Gateway 的动态路由。

3.1 谓词

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

寻址谓词

针对请求地址和类型做请求判断的谓词条件，比如这里用到的 path，其实就是一种路径匹配条件，当请求的 URL 和 path 谓词指定的模式相匹配时，这个谓词就会返回一个 TRUE 的判断，而 method 谓词则是根据请求的 http method 作为判断条件，比如这里就限定了只有 GET 和 POST 请求才能访问当前 Route。

.route("id-1", route -> route
      .path("/user/**")
      .and().method(HttpMethod.GET, HttpMethod.POST)
      .uri("http://user.test.com")

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

请求参数谓词

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

.route("id-1", 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")

时间谓词

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

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

自定义谓词

如果内置谓词不满足要求，想要实现自定义谓词，可以通过 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);
         }
      };
   }
}

往期经典推荐

手把手教你实现服务高可用性-CSDN博客

决胜微服务架构：OpenFeign轻量级REST客户端的魅力解析_feign配置loadbalancer-CSDN博客

一文看懂Nacos如何实现高效、动态的配置中心管理_nacos 动态配置-CSDN博客

TiDB内核解密：揭秘其底层KV存储引擎如何玩转键值对_tidb 的key value是如何做到的-CSDN博客

深入剖析MongoDB集群架构设计_mongodb 集群-CSDN博客