微服务网关: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 的路由和谓词是如何完成请求转发的。