gateway限流 redisRateLimiter

起因

作为sduoj开发组的成员，承担起一定的责任和义务（主要是因为自己比较闲没事情干），主动负责给oj添加gateway限流的工作

查看官方文档

gateway官方文档

然而文档里面只说了非常简单的用法，在配置中心去配置单独的路由，显而易见，这种做法非常简单粗暴，但是配置中心可能会乱七八糟，无法直视。

追求更好更简约

显然上述的方法绝对是我们（主要是学长）不能接受，so我开始尝试阅读RedisRateLimiter类的源代码，

发现了里面的有个内部类Config，用来储存速率和桶容量

在父类里面查到了config，是一个Map，用来储存我们不同的限流设置。

再去看一下redisRateLimiter这个类的主要实现函数isAllowed

routeid就是这个map里面的key，需要我们再配置中心进行配置，然后传入对应的routeid获得config里面的Config（是不是有点绕），id就传入需要限制的设置，如果想限制ip访问，就把对应的用户ip传入，如果想限制路径访问，就把对应路径传入，然后这个函数就执行一个lua脚本去跟redis发生关系

返回的是一个Mono<‘Response’>，先说里面的这个类，也是父类里面的内部类

实际上只取header里面的桶容量就可以了，那个allowed可以不用，外部的mono是响应式编程的流，当时的我绝对没想到，这个简单的mono一套在外面，想要拿出来里面的东西可没那么简单。

年轻人，你为什么要block

显然我们目标明确，调用完isAllowed就想要吧mono这个外壳扔掉，只给我里面的response做一下判断，但是想要完成这个事情，还是要先从响应式编程开始讲起。
响应式编程就是异步非堵塞的处理方式，当你调用这个函数返回一个Mono类时，它内部并没有真的去执行，而是返回了一个处理流，如果你不使用block去堵塞这个流，它就永远不会执行。
但是当你block阻塞的时候，会报错

block()/blockFirst()/blockLast() are blocking, which is not supported
in thread reactor-http-nio-

翻译过来就是线程阻塞了，新的请求挡在外面。
查了下google，找到了另外一种方法，subscribe，用来消费这个响应流，听起来和阻塞差不多（我猜测可能是另开一个线程进行处理），于是写了下面的东东

但是异步非阻塞，导致判断的时候脚本还没有执行完

然后我就想，既然不能让临时变量改变，那就让固定的static值改变，

然后依靠这个值去判定，这样会溜掉一个，但是在限流几百上千的情况下，

这种误差可以忽略。

然后用上面的方法就实现了，dont_limit就是类内的一个静态变量

但是还是不好用

但实际我是


好吧不得不说学长提的这种想法真的十分方便，于是我想大概可以再封装一次，然后再操作操作达到这种目的。

于是乎就有了下面的版本（另外在中途发现了dont_limit用来判断的弊端，所以把它改成了Map，对于每一个url开一个对应的dont_limit，这样防止端口共同阻塞的奇怪情况）

 Optional.of(redisRateLimiter)
                .map(redisRateLimiter -> redisRateLimiter.isAllowed(chooseLimit(requestUrl),requestUrl))
                .get()
                .doOnNext(response -> {
   
                    //这里有问题，对于每个接口应该定义一个不同的dont_limit，否则会互相影响
                    if(response.getHeaders().get("X-RateLimit-Remaining").equals("0")) dont_limit.put(requestUrl,"0");
                    else dont_limit.put(requestUrl,"1");
                }).subscribe();
        if (dont_limit.containsKey(requestUrl)&&dont_limit.get(requestUrl).equals("0")) return returnNoPermission(exchange, " 访问过频! ");

我还是喜欢白色的代码片，不能设置真是一个糟糕的事情

private String chooseLimit(String requestUrl) {
   
        Integer getvalue = Integer.valueOf(filterProp.getLimitPaths().get("default")) ;
        for (Map.Entry<String, String> allowPath : filterProp.getLimitPaths().entrySet())
            if (requestUrl.replace("/","").startsWith(allowPath.getKey()))  getvalue = Integer.valueOf(allowPath.getValue()) ;
        if(redisRateLimiter.getConfig().get(requestUrl) == null)
            redisRateLimiter.getConfig().put(requestUrl,new RedisRateLimiter.Config().setReplenishRate(getvalue).setBurstCapacity(getvalue*2));
        return requestUrl;
    }

然后对应的配置中心也是十分好看

大功告成，大概？

痛苦面具

很遗憾的是，腾哥并不满意，并表达了希望代码更加优美的想法。

嗯

腾哥很优秀，但是有些强迫症一般的性格真的不好啊啊啊啊

也许会有一些联系，学不来学不来。

然后

我就开始改了，加了一个对于ip的过滤，so现在不仅有对于全局的过滤，还有针对一个用户访问某个接口的过滤，very 科学，very痛苦，在腾哥的提议和指引之下，我把redisratelimiter类重写了，重写了两个，然后分别写了他们对应的config配置类。

@Slf4j
public class GlobalRateLimiter extends RedisRateLimiter {
   

    @Autowired
    private ReactiveRedisTemplate<String, String> redisTemplate;

    private AtomicBoolean initialized = new AtomicBoolean(false);

    private RedisScript<List<Long>> script;

    public GlobalRateLimiter(ReactiveRedisTemplate<String, String> redisTemplate,
                             RedisScript<List<Long>> script,
                             Validator validator) {
   
        super(redisTemplate, script, validator);
        this.script = script;
        initialized.compareAndSet(false, true);
    }

    @SuppressWarnings("unchecked")
    public Mono<Boolean> overwrite_isAllowed(String routeId, String id) {
   
        if (!this.initialized.get()) {
   
            throw new IllegalStateException("RedisRateLimiter is not initialized");
        }

        Config routeConfig = getConfig().get(routeId);

        in