spring cloud gateway限流常见算法

目次
一、网关限流
1、限流的作用
1. 掩护后端服务
2. 包管服务质量 (QoS)
3. 克制滥用和恶意攻击
4. 镌汰资源浪费
5. 进步体系可扩展性和稳固性
6. 控制差异用户的访问频率
7. 提升用户体验
8. 克制API滥用和负载过高
9. 监控与分析
10. 克制体系瓦解
2、网关限流的常见算法
1. 令牌桶算法 (Token Bucket)
2. 漏桶算法 (Leaky Bucket)
3. 计数器算法 (Counter-based)
3、令牌桶算法在gateway中的具体实现

---

   前言：
          我们在很多时间应该会遇到一种环境吧，好比说某些秒杀范例的商品在抢购的时间，你显着的感觉到这种环境，再比方大门生们应该都履历过的一件事，那就是每个学期必须履历的选课，每当选课开始的时间是不是总会革新的时间不绝进不去，这也是做了限流的缘故原由。
  一、网关限流

1、限流的作用

1. 掩护后端服务

        网关限流可以有用地控制进入体系的哀求流量，克制后端服务因吸收到过多的哀求而过载大概瓦解。特殊是在高并发场景下，后端体系的处理惩罚本事大概有限，限流可以确保哀求不会超出后端服务的最大承载本事。
2. 包管服务质量 (QoS)

        通过限流，网关可以确保全部用户或哀求都有公平的机遇访问体系资源，克制某些用户或哀求因过分占用体系资源而影响其他正常用户的体验。限流有助于均衡体系负载，克制部门突发哀求导致服务质量降落。
3. 克制滥用和恶意攻击

        限流可以大概有用防止恶意用户或爬虫等非正常流量对体系的恶意攻击。好比，针对DDoS攻击（分布式拒绝服务）或暴力破解等恶意流量，网关通过限流可以限定每个IP大概每个用户的哀求次数，从而防止体系被过载。
4. 镌汰资源浪费

        如果没有限流，过多的哀求大概会让体系资源（如CPU、内存、数据库毗连等）处于超负荷状态，导致资源浪费大概资源耗尽。限流可以公道地限定哀求数目，确保体系资源被有用利用，而不是被不须要的哀求耗尽。
5. 进步体系可扩展性和稳固性

        通过公道设置限流战略，网关可以大概资助体系均衡流量，确保体系稳固运行，克制因负载过高而发生宕机或性能瓶颈。通过动态调解限流战略，还可以应对差异流量颠簸，进步体系的可扩展性。
6. 控制差异用户的访问频率

        网关可以根据差异用户、IP地点大概API接口的差异需求设置差异的限流规则。好比，可以为VIP用户提供更高的哀求频率限定，而平凡用户则可以设置更严酷的限流规则。这有助于实现服务质量差异化管理。
7. 提升用户体验

        通过限流，可以克制体系在流量高峰期间过载导致的哀求失败、相应延长等标题，从而提升用户的体验。当体系可以大概连续稳固相应用户哀求时，用户满意度会进步，且体系负载可以大概保持在公道范围。
8. 克制API滥用和负载过高

        尤其在微服务架构中，API网关起到至关紧张的作用。通过限流，API网关可以大概控制每个API接口的访问频率，防止某个API接口被频仍调用导致的性能标题，确保整个体系的API接口资源公道分配。
9. 监控与分析

        限流机制还可以作为监控的一部门，资助运营职员分析哀求模式。通过纪录哪些哀求被限流，体系可以更好地相识哪些用户或哪些功能地区的负载较高，进而优化体系架构或流量分配。
10. 克制体系瓦解

        如果网关不举行限流，体系在高并发流量下大概会因承载过多哀求而瓦解，导致不可用。通过提前限定哀求流量，网关可以有用克制这种环境，保持体系稳固运行。
2、网关限流的常见算法

1. 令牌桶算法 (Token Bucket)

        令牌桶算法是最常见的限流算法之一，它通过控制哀求的速率来实现限流。

• 工作原理：令牌桶会以固定的速率天生令牌，每当一个哀求到达时，网关会查抄桶中是否有令牌。如果有，则答应哀求通过，而且从桶中斲丧一个令牌；如果没有，则哀求被拒绝大概等候令牌的天生。
  
• 优点：答应哀求的突发流量，由于令牌桶可以存储令牌，支持哀求的突发。
  
• 实用场景：实用于那些偶尔有突发流量的应用，好比API接口。
  

2. 漏桶算法 (Leaky Bucket)

        漏桶算法也常用于限流，其根本头脑是控制流量的均匀速率。

• 工作原理：漏桶算法利用一个固定巨细的桶，当哀求到达时，如果桶中有空间，则哀求可以进入桶中；如果桶已经满了，则新的哀求会被扬弃。哀求从桶中以固定速率“漏出”。
  
• 优点：防止突发流量导致体系过载，包管哀求的流量是安稳的。
  
• 实用场景：实用于渴望平滑流量，克制突发流量影响体系的场景。
  

3. 计数器算法 (Counter-based)

计数器算法通过对哀求计数并举行周期性重置来实现限流。

• 工作原理：每次吸收到哀求时，都会增长一个计数器的值，当计数器到达预设的限定时，新的哀求将被拒绝。计数器会在一段时间后（如每秒、每分钟）被重置为零。
  
• 优点：简单易实现。
  
• 缺点：大概存在短时间内哀求数过多的标题，特殊是在哀求突发时。
  

3、令牌桶算法在gateway中的具体实现

        spring cloud gateway 默认利用redis的RateLimter限流算法来实现。以是我们要利用起首须要引入redis的依靠。

1. <!--redis-->
2. <dependency>
3.     <groupId>org.springframework.boot</groupId>
4.     <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
5.     <version>2.1.3.RELEASE</version>
6. </dependency>

复制代码

        在GatewayApplicatioin引导类中添加如下代码，KeyResolver用于盘算某一个范例的限流的KEY也就是说，可以通过KeyResolver来指定限流的Key。

1. //定义一个KeyResolver
2.     @Bean
3.     public KeyResolver ipKeyResolver() {
4.         return new KeyResolver() {
5.             @Override
6.             public Mono<String> resolve(ServerWebExchange exchange) {
7.                 return Mono.just(exchange.getRequest().getRemoteAddress().getHostName());
8.             }
9.         };
10.     }

复制代码

        修改application.yml中设置项，指定限定流量的设置以及REDIS的设置

1. spring:
2.   cloud:
3.     gateway:
4.       routes:
5.       - id: goods
6.         uri: lb://goods
7.         predicates:
8.         - Path=/goods/**
9.         filters:
10.         - StripPrefix= 1
11.         - name: RequestRateLimiter #请求数限流 名字不能随便写
12.           args:
13.             key-resolver: "#{@ipKeyResolver}"
14.             redis-rate-limiter.replenishRate: 1 #令牌桶每秒填充平均速率
15.             redis-rate-limiter.burstCapacity: 1 #令牌桶总容量
16.   redis:
17.     host: 192.168.200.128 #自己redis的ip和端口以及密码配置
18.     port: 6379

复制代码

表明：

• burstCapacity：令牌桶总容量。
  
• replenishRate：令牌桶每秒添补均匀速率。
  
• key-resolver：用于限流的键的分析器的 Bean 对象的名字。它利用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象。
  

        通过在replenishRate和中设置雷同的值来实现稳固的速率burstCapacity。设置burstCapacity高于时，可以答应临时突发replenishRate。在这种环境下，须要在突发之间答应速率限定器一段时间（根据replenishRate），由于2次一连突发将导致哀求被扬弃（HTTP 429 - Too Many Requests）key-resolver: "#{@userKeyResolver}" 用于通过SPEL表达式来指定利用哪一个KeyResolver.
如上设置：
        表现 一秒内，答应 一个哀求通过，令牌桶的添补速率也是一秒钟添加一个令牌。最大突发状态 也只答应 一秒内有一次哀求，可以根据业务来调解 。
        在做好以上的全部设置之后，当你再次访问具体的微服务的时间，如果你访问的哀求凌驾了每秒1个的速率，那么你就会被限流，页面会表现429错误。如图所示：