如何实现Spring Cloud Gateway动态限流？

Question

在使用 Spring Cloud Gateway 实现动态限流时，常见的一个技术问题是：**如何在不重启网关服务的前提下，实现限流规则的实时更新？** Spring Cloud Gateway 默认整合了 Redis 和 Gateway 的限流组件，但其配置通常定义在 application.yml 中，无法动态调整。因此，如何通过自定义 RateLimiter 实现，并结合 Nacos、Apollo 或数据库等配置中心，动态推送限流策略至网关实例，成为关键问题。 该问题涵盖了配置监听、限流算法选择（如令牌桶或漏桶）、Redis脚本原子操作以及网关过滤器链的扩展等多个技术点，是构建高可用、弹性限流系统必须解决的核心难题。

Answer 1

1. Spring Cloud Gateway限流机制概述

Spring Cloud Gateway 提供了基于 Redis 的限流组件，默认使用的是令牌桶算法，并通过 Lua 脚本保证操作的原子性。但其核心配置如 redis-rate-limiter.replenishRate 和 redis-rate-limiter.burstCapacity 通常写死在 application.yml 中，无法动态修改。

要实现动态更新，必须绕过默认配置方式，自定义 RateLimiter 实现，并结合外部配置中心进行实时推送。

2. 动态限流的核心挑战与技术点

• 配置监听：如何感知配置变化并触发规则刷新？
• 限流算法选择：令牌桶 vs 漏桶，哪种更适合分布式场景？
• Redis脚本优化：如何编写可复用、高效且线程安全的Lua脚本？
• 过滤器链扩展：如何自定义 GatewayFilter 并集成到全局过滤器链中？

3. 配置中心的选择与集成策略

目前主流的配置中心包括 Nacos、Apollo、Consul Config、数据库等。以下是一个对比表格：

配置中心	热更新支持	集成复杂度	适用场景
Nacos	✅	低	微服务架构下推荐使用
Apollo	✅	中	大型企业级系统
数据库	需自行实现	高	需要持久化配置或与业务耦合

4. 自定义 RateLimiter 的实现步骤

1. 继承 AbstractRateLimiter 类，重写 isAllowed() 方法。
2. 引入 RedisTemplate，用于调用 Lua 脚本。
3. 使用配置中心监听器（如 Nacos 的 @RefreshScope）监听配置变更。
4. 将新配置加载进 RateLimiter 实例，替换旧参数。

@Component
public class DynamicRedisRateLimiter extends AbstractRateLimiter {

    private final RedisTemplate redisTemplate;
    private volatile Config currentConfig;

    public DynamicRedisRateLimiter(RedisTemplate redisTemplate) {
        super(Config.class);
        this.redisTemplate = redisTemplate;
        this.currentConfig = new Config();
    }

    public void updateConfig(Config newConfig) {
        this.currentConfig = newConfig;
    }

    @Override
    public Mono isAllowed(String routeId, String id) {
        // 调用 Lua 脚本判断是否允许请求
        return redisTemplate.execute(...);
    }
}
    

5. Redis Lua 脚本的设计与优化

为了确保限流逻辑的原子性和高性能，应使用 Lua 脚本控制 Redis 操作。例如，以下是一个典型的令牌桶实现脚本：

local tokens_key = KEYS[1]
local timestamp_key = KEYS[2]

local rate = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local fill_time = capacity / rate
local ttl = math.floor(fill_time * 2)

local last_tokens = tonumber(redis.call("get", tokens_key))
if last_tokens == nil then
    last_tokens = capacity
end

local last_refreshed = tonumber(redis.call("get", timestamp_key))
if last_refreshed == nil then
    last_refreshed = now
end

local delta = math.max(0, now - last_refreshed)
local filled_tokens = math.min(capacity, last_tokens + delta * rate)
local allowed = filled_tokens >= requested
local new_tokens = filled_tokens
if allowed then
    new_tokens = filled_tokens - requested
end

redis.call("setex", tokens_key, ttl, new_tokens)
redis.call("setex", timestamp_key, ttl, now)

return { allowed, new_tokens }
    

6. 网关过滤器链的整合

在网关启动时，注册自定义的 RateLimiter Bean，并在路由配置中引用它：

@Bean
public DynamicRedisRateLimiter dynamicRedisRateLimiter(RedisTemplate redisTemplate) {
    return new DynamicRedisRateLimiter(redisTemplate);
}

// 在路由配置中：
.route(r -> r.path("/api/**")
    .filters(f -> f.requestRateLimiter(c -> c.setRateLimiter(dynamicRedisRateLimiter)))
    .uri("lb://service"))
    

7. 动态配置监听与刷新流程图

以下是整个动态限流系统的整体流程图：

graph TD
            A[配置中心] -->|配置变更通知| B(网关监听器)
            B --> C{判断是否为限流配置?}
            C -->|是| D[构建新的限流规则对象]
            D --> E[调用 RateLimiter.updateConfig()]
            C -->|否| F[忽略]
            G[客户端请求到达网关]
            G --> H[执行 isAllowed()]
            H --> I{是否超过配额?}
            I -->|是| J[拒绝请求]
            I -->|否| K[放行]