程序员进阶

Spring Cloud Gateway作为Spring Cloud框架的第二代网关，在功能上要比Zuul更加的强大，性能也更好。随着Spring Cloud的版本迭代，Spring Cloud官方有打算弃用Zuul的意思。在笔者调用了Spring Cloud Gateway的使用和功能上，Spring Cloud Gateway替换掉Zuul的成本上是非常低的，几乎可以无缝切换。Spring Cloud Gateway几乎包含了Zuul的所有功能。

# 一、网关定义

API 网关是一个反向路由，屏蔽内部细节，为调用者提供统一入口，接收所有调用者请求，通过路由机制转发到服务实例。API 网关是一组“过滤器 Filter”集合，可以实现一系列与核心业务无关的横切面功能，如安全认证、限流熔断、日志监控。

网关在系统中所处的位置：

Apollo

# 二、Zuul 与 Spring Cloud Gateway 比较

优点 缺点
Gateway 1、线程开销小
2、使用轻量级 Netty 异步IO实现通信
3、支持各种长连接，WebSocket
4、Spring 官方推荐，重点支持，功能较 Zuul更丰富，支持限流监控等
Zuul 1、编码模型简单
2、开发调试运维简单

Zuul 与 Gateway 压测结果： 休眠时间模仿后端请求时间，线程数 2000，请求时间 360秒=6分钟。配置情况：Gateway 默认配置，Zuul网关的 Tomcat 最大线程数为 400，hystrix 超时时间为 100000。

休眠时间 测试样本，单位=个
Zuul/Gateway		 平均响应时间，单位=毫秒
Zuul/Gateway		 99%响应时间，单位=毫秒
Zuul/Gateway		 错误次数，单位=个
Zuul/Gateway		 错误比例
Zuul/Gateway
休眠100ms 294134/1059321 2026/546 6136/1774 104/0 0.04%/0%
休眠300ms 101194/399909 5595/1489 15056/1690 1114/0 1.10%/0%
休眠600ms 51732/201262 11768/2975 27217/3203 2476/0 4.79%/0%
休眠1000ms 31896/120956 19359/4914 46259/5115 3598/0 11.28%/0%

测试结果：Gateway在高并发和后端服务响应慢的场景下比 Zuul的表现要好

# 三、Spring Cloud GateWay 架构图

Apollo

客户端向Spring Cloud Gateway发出请求。 在Gateway Handler Mapping中找到请求相的匹配路由（这个时候就用到predicate），则将其发送到Gateway web handler处理。 handler处理请求时会经过一系列的过滤器链。 过滤器链被虚线划分的原因是过滤器链可以在发送代理请求之前或之后执行过滤逻辑。 先执行所有 “pre”过滤器逻辑，然后进行代理请求。 在发出代理请求之后，收到代理服务的响应之后执行 “post”过滤器逻辑。这跟 Zuul的处理过程很类似。在执行所有 “pre”过滤器逻辑时，往往进行了鉴权、限流、日志输出等功能，以及请求头的更改、协议的转换；转发之后收到响应之后，会执行所有“post”过滤器的逻辑，在这里可以响应数据进行了修改，比如响应头、协议的转换等。在上面的处理过程中，有一个重要的点就是将请求和路由进行匹配，这时候就需要用到predicate，它是决定了一个请求走哪一个路由。

# 四、Spring Cloud Gateway 的几个概念

【1】Route 路由： Gateway的基本构建模块，它由ID、目标URL、断言集合和过滤器集合组成。如果聚合断言结果为真，则匹配到该路由。Gateway 依赖如下：

Route 路由-动态路由实现： 网关管理平台实现增删改查路由信息到 mysql。网关管理平台发布，发布后将路由信息通过配置中心 openapi 保存到配置中心服务中。网关监听配置中心配置变化，动态刷新到内存中。

Apollo

【2】Predicate 断言： 这是一个Java 8 Function Predicate。输入类型是Spring Framework ServerWebExchange。允许开发人员匹配来自 HTTP请求的任何内容，例如 Header或参数。Predicate 接受一个输入参数，返回一个布尔值结果。Spring Cloud Gateway内置了许多Predict，这些 Predict的源码在org.springframework.cloud.gateway.handler.predicate包中，如果读者有兴趣可以阅读一下。现在列举各种 Predicate如下图：

Apollo

在上图中，有很多类型的 Predicate，比如说时间类型的 Predicated[AfterRoutePredicateFactory BeforeRoutePredicateFactory BetweenRoutePredicateFactory]，当只有满足特定时间要求的请求会进入到此 Predicate中，并交由 Router处理；Cookie类型的 CookieRoutePredicateFactory，指定的 Cookie满足正则匹配，才会进入此 Router。以及host、method、path、querparam、remoteaddr类型的 Predicate，每一种 Predicate都会对当前的客户端请求进行判断，是否满足当前的要求，如果满足则交给当前请求处理。如果有很多个Predicate，并且一个请求满足多个Predicate，则按照配置的顺序第一个生效。

Predicate 断言配置：

server:
  port: 8080
spring:
  application:
    name: api-gateway
  cloud:
    gateway:
      routes:
        - id: gateway-service
          uri: https://www.baidu.com
          order: 0
          predicates:
            - After=2017-01-20T17:42:47.789-07:00[America/Denver]
            - Host=**.foo.org
            - Path=/headers
            - Method=GET
            - Header=X-Request-Id, \d+
            - Query=foo, ba.
            - Query=baz
            - Cookie=chocolate, ch.p
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

在上面的配置文件中，配置了服务的端口为8080，配置spring cloud gateway相关的配置，id标签配置的是router的id，每个router都需要一个唯一的id，uri配置的是将请求路由到哪里，本案例全部路由到https://www.baidu.com。

Predicates： After=2017-01-20T17:42:47.789-07:00[America/Denver] 会被解析成PredicateDefinition对象name =After ，args= 2017-01-20T17:42:47.789-07:00[America/Denver]。需要注意的是Predicates的After这个配置，遵循契约大于配置的思想，它实际被 AfterRoutePredicateFactory这个类所处理，这个After就是指定了它的Gateway web handler类为AfterRoutePredicateFactory，同理，其他类型的Predicate也遵循这个规则。当请求的时间在这个配置的时间之后，请求会被路由到指定的URL。跟时间相关的Predicates还有 Before Route Predicate Factory、Between Route Predicate Factory，读者可以自行查阅官方文档，再次不再演示。

Query=baz： Query的值以键值对的方式进行配置，这样在请求过来时会对属性值和正则进行匹配，匹配上才会走路由。经过测试发现只要请求汇总带有baz参数即会匹配路由[localhost:8080?baz=x&id=2]，不带 baz参数则不会匹配。 Query=foo, ba.：这样只要当请求中包含foo属性并且参数值是以 ba开头的长度为三位的字符串才会进行匹配和路由。使用curl测试，命令行输入：curl localhost:8080?foo=bab测试可以返回页面代码，将foo的属性值改为babx再次访问就会报404，证明路由需要匹配正则表达式才会进行路由。

Header=X-Request-Id, \d+：使用curl测试，命令行输入：curl http://localhost:8080 -H "X-Request-Id:88" 则返回页面代码证明匹配成功。将参数-H "X-Request-Id:88"改为-H "X-Request-Id:spring"再次执行时返回404证明没有匹配。

【3】Filter 过滤器：方案一：写死在代码中

@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
        //openapi路由转发
        .route("openapi_route", p -> p.path( "/openapi/**").filters(f->f.removeRequestHeader("Expect"))
        .uri("lb://order-openapi-service"))
        .build();
}
1
2
3
4
5
6
7
8

方案二：配置文件(yml)

# gateway 的配置形式
 routes:
 - id: order-service #路由ID，没有规定规则但要求唯一，建议配合服务名。
   uri: lb://order-service
   predicates:
   - Path=/order/**
   filters:
   - ValidateCodeGatewayFilter
1
2
3
4
5
6
7
8

Filter过滤器：Filter按处理顺序Pre Filter / Post Filter

Apollo

Filter 按作用范围分为： GlobalFilter全局过滤器。GatewayFilter 指定路由的过滤器。
Filter 过滤器-扩展自定义Filter： Filter支持通过 spi 扩展。实现GatewayFilter，Ordered接口。
Filter 方法： 过滤器处理逻辑。getOrder：定义优先级，值越大优先级越低。

public class TokenFilter implements GlobalFilter, Ordered {

    Logger logger=LoggerFactory.getLogger( TokenFilter.class );
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getQueryParams().getFirst("token");
        if (token == null || token.isEmpty()) {
            logger.info( "token is empty..." );
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {
        return -100;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 五、快速开始

网关启动步骤（代码演示）：

【1】添加依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
1
2
3
4

【2】配置文件

spring:
  cloud:
    gateway:
      routes:
      - id: product   #路由ID，根据业务自行定义
        uri: http://bin.org:80/get  #路由的地址
        predicates:
        - Path=/**
      #开启根据服务名进行转发，需要将服务注册到注册中心
      discovery:
        locator:
           enabled: true
1
2
3
4
5
6
7
8
9
10
11
12

# 六、Gateway 限流

在Spring Cloud Gateway中，有 Filter过滤器，因此可以在“pre”类型的 Filter中自行实现上述三种过滤器。但是限流作为网关最基本的功能，Spring Cloud Gateway官方就提供了RequestRateLimiterGatewayFilterFactory这个类，适用 Redis和 Lua脚本实现了令牌桶【链接】的方式。具体实现逻辑在RequestRateLimiterGatewayFilterFactory类中，Lua脚本在如下图所示的文件夹中：

Apollo

具体源码不打算在这里讲述，读者可以自行查看，代码量较少，先以案例的形式来讲解如何在 Spring Cloud Gateway中使用内置的限流过滤器工厂来实现限流。首先在工程的 pom文件中引入 Gateway的起步依赖和 Redis的 Reactive依赖，代码如下：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifatId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
1
2
3
4
5
6
7
8
9

在配置文件中做以下的配置：

server:
  port: 8081
spring:
  cloud:
    gateway:
      routes:
      - id: limit_route
        uri: lb://PRODUCTCENTOR   # PRODUCTCENTOR是注册到注册中心的服务名，格式为 lb://服务名
        predicates:
        - Path=/**
        filters:
        - StripPrefix=1
        - name: RequestRateLimiter  #拦截器，会对上述的请求进行拦击
          args:
            key-resolver: '#{@hostAddrKeyResolver}'
            redis-rate-limiter.replenishRate: 1
            redis-rate-limiter.burstCapacity: 3
  application:
    name: gateway-limiter
  redis:
    host: localhost
    port: 6379
    database: 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

过滤器 StripPrefix，作用是去掉请求路径的最前面n个部分截取掉。 StripPrefix=1就代表截取路径的个数为1，比如前端过来请求/test/good/1/view，匹配成功后，路由到后端的请求路径就会变成http://localhost:8888/good/1/view。

在上面的配置文件，指定程序的端口为8081，配置了 Redis的信息，并配置了 RequestRateLimiter的限流过滤器，该过滤器需要配置三个参数：
【1】burstCapacity：令牌桶总容量。
【2】replenishRate：令牌桶每秒填充平均速率。
【3】key-resolver：用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象。

KeyResolver需要实现 resolve方法，比如根据 Hostname进行限流，则需要用 hostAddress去判断。实现完 KeyResolver之后，需要将这个类的 Bean注册到 Ioc容器中。

public class HostAddrKeyResolver implements KeyResolver {

    @Override
    public Mono<String> resolve(ServerWebExchange exchange) {
        return Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
    }

}

@Bean
public HostAddrKeyResolver hostAddrKeyResolver() {
    return new HostAddrKeyResolver();
}
1
2
3
4
5
6
7
8
9
10
11
12
13

可以根据 URL去限流，这时 KeyResolver代码如下：

public class UriKeyResolver  implements KeyResolver {

    @Override
    public Mono<String> resolve(ServerWebExchange exchange) {
        return Mono.just(exchange.getRequest().getURI().getPath());
    }

}

@Bean
public UriKeyResolver uriKeyResolver() {
    return new UriKeyResolver();
}
1
2
3
4
5
6
7
8
9
10
11
12
13

也可以以用户的维度去限流：

@Bean
KeyResolver userKeyResolver() {
    return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("user"));
}
1
2
3
4

用 jmeter进行压测，配置 10thread去循环请求lcoalhost:8081，循环间隔1s。从压测的结果上看到有部分请求通过，由部分请求失败。通过 redis客户端去查看 redis中存在的key。如下：

Apollo

可见，RequestRateLimiter是使用Redis来进行限流的，并在redis中存储了2个key。关注这两个key含义可以看 lua源代码。

#

(adsbygoogle = window.adsbygoogle || []).push({});

← Nacos 实现 AP+CP原理[Raft 算法] →