Is that possible to control rate limit dynamically? about spring-cloud-zuul-ratelimit

[marcosbarbero]

I don't believe that's possible to achieve in the current implementation

[willswl]

I worked around this problem, but seems it's hard to integrate my solution to the current zuul-ratelimit inplementation.

What I did : created a rate limit checker in zuul filter by using "es.moki.ratelimitj", and defined a policy as below:

ratelimit:

    repository: Redis
    policy-list:
      - service-name: service#1 
        limit: 5
        refresh-interval: 1
        sharable: false  # can not be stolen 
      - service-name: service#2
        limit: 6           
        refresh-interval: 1
        sharable: false # can not be stolen 
      - service-name: service#2
        limit: 4
        refresh-interval: 1
        sharable: true # can be stolen

[marcosbarbero]

How did you do that?
I never used this ratelimitj before

[willswl]

It's totally a new implementation, but I did refer to your solution to define my policy and the limiting process. I would try to implement that by extending zuul-ratelimit after my busy project work finished.

My solution is simple: I leverage ratelimitj as a standalone limiter, and defined all the three limiters with ratelimitj. When a request comes in, firstly I checked the service name, and found the corresponding limiter that is not sharable. if the limiter is full, I will then look for another limiter that is sharable.

[marcosbarbero]

Now I got it, based on that I'm sure there will be necessary some redesign in the actual implementation.

@lchayoun WDYT about this proposal?

[lchayoun]

well, making two policies use the same allocation (limit / quota) should be easy enough by adding a property to the policy name and in the other policies add a property that specify they consume the other policy quota.
But that not exactly what described here.
Making one policy overflow to another one as described will be harder but it also doable.
We can add a property to specify the overflow policy and on failure to consume try to take it from the other policy.

I think this request is a combination of those two capabilities

[dchack]

I think if you overwrite filter(RateLimitPostFilter and
) , and do some thing for your customer implementation will control rate limit dynamically.