微服务限流
常见的限流策略
固定窗口限流: 将时间分割成固定大小的窗口，每个窗口内允许的最大请求数是固定的。这种方法简单，但可能在窗口切换的瞬间遇到两倍于限流值的流量。
滑动窗口限流: 该策略是固定窗口的一个变种，通过在固定窗口的基础上增加更细粒度的子窗口来平滑流量。
漏桶算法: 将请求想象为水滴流入漏桶，桶以恒定的速率漏水（处理请求）。如果桶满了，则新的请求会被丢弃或排队等待。
令牌桶算法: 以固定的速率向桶中添加令牌，处理请求时需要从桶中获取令牌。如果桶空，则请求等待或被丢弃。与漏桶算法相比，令牌桶允许一定程度的突发流量。
实现限
流通常涉及以下几个层面：
-
应用层限流:
- 在代码中直接实施限流，可以是在服务入口或者业务逻辑之前。
- 可以使用限流算法如固定窗口、滑动窗口、漏桶算法、令牌桶算法等。
- 可以利用开源框架如Netflix的Hystrix、Google的Guava RateLimiter、阿里巴巴的Sentinel等。
-
中间件层限流:
- 在API网关层进行限流，如使用Kong、Zuul等网关中间件提供的限流功能。
- 在消息队列（如RabbitMQ、Kafka）中控制消息的生产和消费速率。
-
负载均衡器限流:
- 在负载均衡器（如Nginx、HAProxy）配置请求限制。
- 依赖负载均衡器的内置算法或通过脚本扩展实现定制限流逻辑。
-
数据库限流:
- 通过数据库的事务和并发控制机制来限制对数据库资源的访问率，防止数据库层面的过载。
-
基础设施层限流:
- 在入口路由器或防火墙设置流量控制策略，限制网络流量。
- 在操作系统层面通过内核参数或网络工具（如tc，iptables）进行限制。
示例：API Gateway限流实现
以Spring Cloud Gateway为例，可以很容易地在网关层面实现限流。Spring Cloud Gateway提供了一个RequestRateLimiter过滤器，它使用Redis来实现令牌桶算法：
spring:cloud:gateway:routes:- id: myserviceuri: lb://MYSERVICE # 使用服务发现的服务IDfilters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 10redis-rate-limiter.burstCapacity: 20key-resolver: "#{@userKeyResolver}" # SpEL表达式指向Bean的名称
replenishRate 是每秒钟向令牌桶中添加的令牌数量，burstCapacity 是令牌桶的最大容量。key-resolver 是一个指向Spring Bean的引用，用于确定限流的维度，例如用户、IP等。
在Spring Boot应用中，可以定义key-resolver Bean如下：
@Configuration
public class RateLimiterConfig {@BeanKeyResolver userKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getHostName());}}
这个配置定义了一个按客户端IP地址限流的策略。
注意事项
当实现限流时，应考虑以下因素：
- 粒度：在什么层面上进行限流？是对整个服务的限流，还是对特定接口的限流？
- 限流算法：选择一个适合你服务特性的限流算法。
- 性能：确保限流机制在高流量下不会成为性能瓶颈。
- 弹性：限流可能会导致请求被拒绝，确保系统能够优雅地处理这些情况，例如通过排队、重试或者提供错误信息。
- 配置与监控：限流策略应便于配置和调整，并有相应的监控和报警机制，以便及时响应潜在问题。
限流实施的最佳位置取决于系统架构、业务需求和流量特性。通常，建议在系统的边缘，即服务的入口处进行限流，这样可以尽早发现和阻止过量流量，保护系统的其他部分。