Spring Cloud—GateWay之限流

RequestRateLimiter

RequestRateLimiter GatewayFilter 工厂使用 RateLimiter 实现来确定是否允许当前请求继续进行。如果不允许，就会返回 HTTP 429 - Too Many Requests（默认）的状态。

这个过滤器需要一个可选的 keyResolver 参数和特定于速率限制器的参数。

keyResolver 是一个实现了 KeyResolver 接口的Bean。在配置中，使用SpEL来引用Bean的名字。#{@myKeyResolver} 是一个SpEL表达式，它引用了一个名为 myKeyResolver 的bean。下面的列表显示了 KeyResolver 的接口。

Example 42. KeyResolver.java

public interface KeyResolver {
    Mono resolve(ServerWebExchange exchange);
}

KeyResolver 接口让可插拔的策略导出限制请求的key。在未来的里程碑版本中，会有一些 KeyResolver 的实现。

KeyResolver 的默认实现是 PrincipalNameKeyResolver，它从 ServerWebExchange 中检索 Principal 并调用 Principal.getName()。

默认情况下，如果 KeyResolver 没有找到一个 key，请求会被拒绝。你可以通过设置 spring.cloud.gateway.filter.request-rate-limiter.deny-empty-key（true 或 false）和 spring.cloud.gateway.filter.request-rate-limiter.empty-key-status-code 属性来调整这种行为。

RequestRateLimiter 不能用 "快捷方式" 来配置。下面的例子是无效的。

Example 43. application.properties

# 无效的快捷方式配置
spring.cloud.gateway.routes[0].filters[0]=RequestRateLimiter=2, 2, #{@userkeyresolver}

Redis RateLimiter

​Redis的实现是基于 Stripe 的工作。它需要使用 spring-boot-starter-data-redis-reactive Spring Boot Starter。 使用的算法是 令牌桶算法。

常用的更平滑的限流算法有两种：漏桶算法 和 令牌桶算法。

漏桶算法

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水（接口有响应速率），当水流入速度过大会直接溢出（访问频率超过接口响应速率），然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。

可见这里有两个变量，一个是桶的大小，支持流量突发增多时可以存多少的水（burst），另一个是水桶漏洞的大小（rate）。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使流突发（burst）到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。

令牌桶算法

令牌桶算法 和漏桶算法 效果一样但方向相反的算法，更加容易理解。随着时间流逝，系统会按恒定 1/QPS 时间间隔（如果 QPS=100，则间隔是 10ms）往桶里加入 Token（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个 Token，如果没有 Token 可拿了就阻塞或者拒绝服务。

令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率，则按需提高放入桶中的令牌的速率。一般会定时（比如 100 毫秒）往桶中增加一定数量的令牌，有些变种算法则实时的计算应该增加的令牌的数量。

redis-rate-limiter.replenishRate 属性定义了每秒钟允许多少个请求（不算放弃的请求）。这是令牌桶被填充的速度。

redis-rate-limiter.burstCapacity 属性是一个用户在一秒钟内允许的最大请求数（不算放弃的请求）。这是令牌桶可以容纳的令牌数量。将此值设置为零会阻止所有请求。

redis-rate-limiter.requestedTokens 属性是指一个请求要花费多少令牌。这是为每个请求从桶中提取的令牌数量，默认为 1。

一个稳定的速率是通过在 replenishRate 和 burstCapacity 中设置相同的值来实现的。可以通过设置高于补给率的 burstCapacity 来允许临时的突发。在这种情况下，速率限制器需要在突发之间允许一些时间（根据 replenishRate），因为连续两次突发会导致请求被放弃（HTTP 429 - Too Many Requests）。下面的列表配置了一个 redis-rate-limiter。

低于 1个请求/s 的速率限制是通过将 replenishRate 设置为想要的请求数， requestTokens 设置为秒数，burstCapacity 设置为 replenishRate 和 requestTokens 的乘积来完成的。例如，设置 replenishRate=1，requestedTokens=60，burstCapacity=60，结果是1个请求/分钟的限制。

Example 44. application.yml

spring:
  cloud:
    gateway:
      routes:
      - id: requestratelimiter_route
        uri: https://example.org
        filters:
        - name: RequestRateLimiter
          args:
            redis-rate-limiter.replenishRate: 10
            redis-rate-limiter.burstCapacity: 20
            redis-rate-limiter.requestedTokens: 1

下面的例子在Java中配置了一个 KeyResolver。

Example 45. Config.java

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

这定义了每个用户的请求率限制为10。爆发20次是允许的，但是，在下一秒，只有10个请求可用。KeyResolver 是一个简单的，获得 user 请求参数。

你也可以把速率限制器定义为一个实现 RateLimiter 接口的bean。在配置中，你可以用SpEL来引用bean的名字。#{@myRateLimiter} 是一个SpEL表达式，它引用了一个名为 myRateLimiter 的 bean。下面的清单定义了一个速率限制器，它使用了前面清单中定义的 KeyResolver。

Example 46. application.yml

spring:
  cloud:
    gateway:
      routes:
      - id: requestratelimiter_route
        uri: https://example.org
        filters:
        - name: RequestRateLimiter
          args:
            rate-limiter: "#{@myRateLimiter}"
            key-resolver: "#{@userKeyResolver}"