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

如果内置谓词不满足要求，想要实现自定义谓词，可以通过 Gateway 的可扩展谓词工厂来实现自定义谓词，Gateway 组件提供了一个统一的抽象类 AbstractRoutePredicateFactory 作为谓词工厂，你可以通过继承这个类来添加新的谓词逻辑。// 继承自通用扩展抽象类AbstractRoutePredicateFactory// 定义当前谓词所需要用到的参数@Validated

qq_39209927

865人浏览 · 2024-04-19 12:37:03

qq_39209927 · 2024-04-19 12:37:03 发布

一、多层网关

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

首先网址解析的第一步是 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博客