API 限流与熔断：保护微服务的两道防线

# API 限流与熔断 ## 一、为什么需要限流？ 在高并发场景下，如果不对请求进行限制，后端服务可能被大量请求压垮，导致雪崩效应。限流是保护系统的第一道防线。 ## 二、三种限流算法 ### 1. 令牌桶（Token Bucket） ```java // 使用 Guava RateLimiter RateLimiter limiter = RateLimiter.create(100.0); // 100 QPS @GetMapping("/api/data") public Result getData() { if (!limiter.tryAcquire(1, TimeUnit.SECONDS)) { return Result.error(429, "请求过于频繁"); } return doQuery(); } ``` 特点：允许突发流量（桶中有令牌就可以消费）。 ### 2. 滑动窗口（Sliding Window） ```java // Redis 实现滑动窗口限流 public boolean isAllowed(String key, int maxRequests, int windowSeconds) { long now = System.currentTimeMillis(); String windowKey = "ratelimit:" + key; // 使用 Redis sorted set Pipeline p = jedis.pipelined(); p.zremrangeByScore(windowKey, 0, now - windowSeconds * 1000); p.zadd(windowKey, now, String.valueOf(now)); p.zcard(windowKey); p.expire(windowKey, windowSeconds); List results = p.syncAndReturnAll(); long count = (Long) results.get(2); return count supplier = CircuitBreaker.decorateSupplier( breaker, () -> paymentService.charge(order) ); Try result = Try.ofSupplier(supplier) .recover(CallNotPermittedException.class, e -> { // 熔断时的降级逻辑 return PaymentResult.pending("服务暂时不可用，请稍后重试"); }); ``` ### Spring Boot 集成 ```yaml # application.yml resilience4j: circuitbreaker: instances: paymentService: failure-rate-threshold: 50 wait-duration-in-open-state: 30s sliding-window-size: 10 ratelimiter: instances: apiLimit: limit-for-period: 100 limit-refresh-period: 1s timeout-duration: 500ms ``` ```java @Service public class OrderService { @CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback") @RateLimiter(name = "apiLimit") public PaymentResult processPayment(Order order) { return paymentClient.charge(order); } private PaymentResult paymentFallback(Order order, Exception e) { return PaymentResult.pending("支付服务暂不可用"); } } ``` ## 四、熔断器状态 ``` CLOSED ---(失败率超阈值)---> OPEN ^ | | (等待超时) | v +-----(成功)---- HALF_OPEN ----(失败)---> OPEN ``` ## 五、最佳实践 1. 限流放在网关层（如 Nginx、Kong），避免请求到达后端 2. 熔断器保护外部依赖（支付、短信等第三方服务） 3. 限流 + 熔断 + 降级三位一体，缺一不可 4. 监控熔断器状态变化，及时告警