微服务网关限流算法（网关限流实现）

本篇文章给大家谈谈微服务网关限流算法，以及网关限流实现对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关限流算法的知识，其中也会对网关限流实现进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Spring Cloud Zuul微服务网关的API限流
• 2、Spring Cloud Gateway 网关限流
• 3、限流和常见的三种算法
• 4、Spring Cloud Gateway 之限流操作
• 5、SpringCloud使用Zuul限流（spring-cloud-zuul-ratelimit）
• 6、关于API网关（四）——限流

Spring Cloud Zuul微服务网关的API限流

微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端微服务网关限流算法的请求速率能在一定程度上抵御短信轰炸攻击，降低损失。

微服务网关是每个请求的必经入口，非常适合做一些API限流、认证之类的操作，这里有一个基于zuul微服务网关的API限流库微服务网关限流算法：

https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit

比如我们要对 user-service 这个服务进行限流，限制每个请求源每分钟最多只能请求10次。

首先在项目中添加 spring-cloud-zuul-ratelimit 依赖：

然后再添加如下配置即可：

对API限流是基于Zuul过滤器完成的，默认情况下限流数据是记录在内存中的，实际上是用ConcurrentHashMap保存，当然也提供了多种存储方式，包括Redis、Consul、Spring Data JPA，使用这三种存储方式要添加相关依赖。

然后再添加存储配置，比如使用Redis的配置：

限流过滤器是在请求被转发之前调用的

限流类型主要包括url、origin、user三种

在过滤器的run方法中判断请求剩余次数，小于0就拦截请求：

可以看到，单位时间内剩余请求次数小于0时抛出ZuulRuntimeException，直接返回客户端TOO_MANY_REQUESTS异常消息，达到拦截请求的效果。

https://github.com/yunTerry/spring-cloud-netflix

Spring Cloud Gateway 网关限流

在微服务网关限流算法我们平时开发过程中，一般一个请求都是需要经过多个微服务微服务网关限流算法的， 比如： 请求从A服务流过B服务，如果A服务请求过快，导致B服务响应慢，那么必然会导致系统出现问题。因为，我们就需要有限流操作。

限流微服务网关限流算法的key 生成规则，默认是 PrincipalNameKeyResolver 来实现
限流算法，默认是 RedisRateLimiter 来实现，是令牌桶算法。

在 Spring Cloud Gateway 中默认提供了 RequestRateLimiter 过滤器来实现限流操作。

配置文件中的写法(部分)

配置文件中的写法(部分)

注意⚠️：
这个类需要加上 @Primary 注解。

https://gitee.com/huan1993/spring-cloud-alibaba-parent/tree/master/gateway-redis-limiter

1、 https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#the-redis-ratelimiter

限流和常见的三种算法

限流的三种算法
https://www.cnblogs.com/forezp/p/10140316.html

限流要解决的问题

典型限流的应用场景：

如何限流？
一般网关都有这种功能。 gateway、nginx、zuul等

限流：一定时间内，只允许N次请求。
从计算机友好的角度出发，是希望能在单位时间内均摊掉请求，使用漏斗算法可以达到这种效果。
但是漏斗算法有个弊端，就是先快后慢的这种请求，那么峰值的请求也只能排队等待被消费。实际上计算机是具备一定的高并发处理能力的，只要不是一直处于高并发下即可。所以 计数器限流和 漏洞限流折中的算法，令牌限流成为现在最主流的算法。

（Redis 结合expire方案可以实现)
第一次请求开始计时，例如1s以内，达到100次请求就拒绝访问了，直到1s过后，重新开始计数。

优点：

缺点：短暂的峰值过高对服务器不友好。服务器希望能把请求尽量的均摊开来，这样可以充分利用计算机资源。

消费的速度是恒定的，对于服务器而言是最友好的。
在算法实现方面，可以准备一个队列，用来保存请求，另外通过一个线程池（ScheduledExecutorService）来定期从队列中获取请求并执行，可以一次性获取多个并发执行。
参数：消费速度、桶容量（超过就抛弃，可以避免内存过大，有过多的等待的任务)

优点：

缺点：

令牌桶算法是比较常见的限流算法之一，大概描述如下：
1）所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；
2）根据限流大小，设置按照一定的速率往桶里添加令牌；
3）桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃活着拒绝；
4）请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；
5）令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

这种算法，既可以保证系统由一定的高并发能力，比如当前令牌桶容量是100，一开始直接消费掉100个请求。有保证服务器不会因为短暂的爆发，而导致server端空闲，因为令牌桶还会持续的生产令牌。

既有一定的并发能力，又不至于完全失去控制，可控的兼具并发力和流量控制的限流算法.是计数器算法（一定的并发处理能力）和漏洞限流（高峰过后仍然会持续的产生令牌）的折中算法。

Spring Cloud Gateway 之限流操作

高并发系统常用三板斧来保护系统： 缓存 、 降级 和 限流 ，API网关作为所有请求的入口，请求量大，可以通过对并发访问的请求进行限速来保护系统的可用性。

常用的限流算法比如有令牌桶算法，漏桶算法，计数器算法等，在Zuul中我们可以自己去实现限流的功能，Spring Cloud Gateway的出现本身就是用来替代Zuul的，要想替代那肯定得有强大的功能，除了性能上的优势之外，Spring Cloud Gateway还提供了很多新功能，比如限流操作，使用起来非常简单。

目前限流提供了基于Redis的实现，首先引入依赖，

然后就可以以通过KeyResolver来指定限流的Key,比如我们需要根据用户来做限流，IP来做限流等等。

通过exchange对象可以获取到请求信息，这边用了HostName。

通过exchange对象可以获取到请求信息，获取当前请求的用户ID或者用户名，使用这种方式限流，请求路径中必须携带userId参数。

获取请求地址的uri作为限流key。

配置好后就可以进行限流测试了，注意观察redis中的数据。

SpringCloud使用Zuul限流（spring-cloud-zuul-ratelimit）

简述：
Spring Cloud Zuul RateLimit项目Github地址：
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
该包实现了在Zuul对每个服务进行限流

微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端的请求速率能在一定程度上抵御短信轰炸攻击，降低损失。微服务网关是每个请求的必经入口，非常适合做一些API限流、认证之类的操作，本文介绍Zuul如何进行限流操作

个人建议：如果在网关做细粒度的限流，后面微服务业务变化的话网关也要跟着变，而且后面涉及到微服务之间的调用，这个网关限流做不了。所以在网关上不能做细粒度的限流，网关主要为服务器硬件设备的并发处理能力做限流，细粒度的限流还是交给专门的熔断限流微服务去处理，这样利于各微服务之间的解构和各团队的协同开发

1、限流策略

2、可用的实现

Bucket4j实现需要相关的bean @Qualifier("RateLimit"):

3、常见的配置属性

policy的相关属性

4、发生错误如何处理

1、导入依赖

2、启动类标注解

3、配置文件

4、启动后进行访问
由于我们配置的是一秒只允许3个请求，当我们超过时，会抛出过多请求异常

5、自定义Key策略
如果希望自己控制key的策略，可以通过自定义RateLimitKeyGenerator的实现来增加自己的策略逻辑。

实例：

根据请求上的参数来对请求进行限流。比如有一个请求是 http://localhost:9070/api-a//hello2?name=kevin ，对相同的name值进行限流。我们设置了1分钟内，限流10次，那么如果1分钟内，name是kevin的请求超过10次，就会发生限流。

自定义RateLimitKeyGenerator的实现：

到此本文就结束啦！
参考：

关于API网关（四）——限流

通俗的说，流量控制就是控制用户请求的策略，主要包括：权限、限流、流量调度。
权限上一篇已经讲过了，这一篇讲限流，下一篇讲流量调度。
限流是指限制用户调用的频率（QPS/QPM）或者次数。

流量限制，站在用户或者运营的角度看，最直观能感受到的作用是——收费
各大主流开放平台的对外API，一般都有一些免费的额度，可以供个人测试用，一旦想大规模调用，就需要付费购买更大的额度（频率、次数），根据调用次数或者频率进行收费。一旦超过拥有的额度，就会被限制调用。

其实这才是限流最大的用处，只是用户或者运营同学无感，所以不太被大多数人了解。
网关后面是各个服务，各个服务的接口通过网关透出去给用户调用。理论上说，用户的流量是不可预知的，随时可能来一波，一旦流量的峰值超过了服务的承载能力，服务就挂了，比如有大新闻发生时的某浪微博，比如前些年的12306.
所以， 网关必须保证，放过去到达后端服务的流量一定不可以超过服务可以承载的上限 。这个上限，是网关和各个服务协商出来的。

由简到难，限流可以 分为单机限流、单集群限流、全集群限流 。
这里不讨论具体的如漏桶、令牌桶等限流算法，只说概念和思想。

单机限流的思想很简单，就是每个机器的限流值 x 机器数量 = 总的限流值。
举个例子，A用户的QPS限制是100，网关部署了10台机器，那么，每台机器限制10QPS就可以了。
先说好处，这种方法实现起来非常简单，每台机器在本地内存计算qps就可以了，超过阈值就拒流。
不过单机限流的缺陷也十分明显，主要体现在两点：
 当网关部署的机器数量发生变化时，每台机器的限流值需要根据机器数调整。现实中，因为扩容、缩容、机器宕机等原因，机器数的变化是常有的事。
 单机限流的前提是，每台网关承载的用户的流量是平均的，但是事实上，在某些时间，用户的流量并不是完全平均分布在每台机器上的。
举个例子：
10台机器，每台限qps10，其中3台每台实际qps是15，因为超限导致用户流量被拒。其余7台每台qps是7。这样用户总的qps = 15 * 3 + 7 * 7 = 94. 用户qps并没有超限，但是却有一部分流量被拒了，这样就很有问题。
实际上，单台限流的阈值也会设置的稍微大一些，以抵消流量不均的问题。
因为上面的问题， 单机限流通常作为一种兜底的备用手段，大多数时候用的还是集群限流 。

先来看一个示意图：

相比单机限流，集群限流的计数工作上移到redis集群内进行，解决了单机限流的缺陷。
但是集群限流也不是完美的，因为引入了redis，那么，当网关和redis之间的网络抖动、redis本身故障时，集群限流就失效了，这时候，还是得依靠单机限流进行兜底。
也就是说， 集群限流 + 单机限流配合，才是一个比稳妥的方案 。

接下来我们来思考这样一个问题：大型网关一般都是多机房、多地域部署的，当然，后端的服务也是多机房、多地域部署的，在保护服务这一点来说，集群限流是够用了。但是对用户来说，还是有一些问题：
比如，用户购买的QPS上限是30，我们的网关部署在中国北、中、南三个地域，那么这30QPS怎么分配呢？
平均肯定不行，用户的流量可能是明显不均衡的，比如用户的业务主要集中在中国北方，那么用户的流量大部分都会进入北方的网关，网关如果限制QPS为10的话，用户肯定来投诉。
那每个地域都限制为30行不行？也不行，如果用户的流量比较均匀的分布在各个地域，那么用户购买了30QPS，实际上可能使用了90QPS，这太亏了。
按照解决单机限流流量不均的思路，搞一个公共的redis集群来计数行不行？
也不行，受限于信号传播速度和天朝的广阔疆域，每个流量都计数，肯定不现实，rt太高会导致限流失去意义，带宽成本也会变得极其昂贵，对redis的规格要求也会很高。总之，很贵还解决不了问题。
有一种巧妙的解决办法是：本地集群阶梯计数 + 全集群检查。
还是刚才的例子：
限流阈值时90，那么三个地域各自计数，当本地域的数值达到30时，去其他两个地域取一次对方当前的计数值，三个地域的计数值加起来，如果超了，告诉另外两个地域超了，开始拒流。如果没超，本地QPS每上涨10，重复一次上述的动作。
这样就能有效的减少与redis的交互次数，同时实现了全地域真·集群限流。
当然，这种全地域集群限流，因为rt和阶梯计数间隔的存在，一定是不准的，但是，比单集群限流还是好很多。

当某个用户流量特别大的时候，redis计数就会遇到典型的热点key问题，导致redis集群单节点压力过大， 有两种办法可以解决这个问题：打散和抽样。

打散是指，把热点key加一些后缀，使其变成多个key，从而hash到不通的redis节点上，均摊压力。
比如热点key是abcd，那么打散后，key变成了abcd1、abcd2、abcd3、abcd4。技术时，轮流加1、2、3、4的后缀就可以了。

抽样是指，针对热点key，不是每个每个请求到来时都进行计数，而是进行一个抽样，比如每10个请求记一次数，这样redis的压力就会降低到十分之一。

说着把流量调度的也说完了哈哈，那下一篇再说说监控好了，顺便推一下我现在在用的国产网关：GOKU，来自Eolinker。我觉得比KONG好用，感兴趣的同学可以自行去了解一下。
www.eolinker.com

关于微服务网关限流算法和网关限流实现的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关限流算法的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于网关限流实现、微服务网关限流算法的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。