熔断降级深度解析：Resilience4j 状态机、Fallback 与限流算法

关键配置参数：

resilience4j:
  circuitbreaker:
    configs:
      default:
        failureRateThreshold: 60 # 失败率阈值（%）
        slowCallRateThreshold: 80 # 慢调用阈值（%）
        slowCallDurationThreshold: 1s # 慢调用定义（>1s 视为慢）
        waitDurationInOpenState: 10s # Open→Half-Open 等待时间
        permittedNumberOfCallsInHalfOpenState: 5 # 半开状态放行请求数
        minimumNumberOfCalls: 10 # 触发熔断的最小调用数（避免小样本误触发）
        slidingWindowSize: 100 # 统计窗口大小
        slidingWindowType: COUNT_BASED # 基于计数/时间窗口

3. 与 Hystrix 的核心差异

二、Fallback 函数：降级策略与实现

Fallback 是熔断后的兜底逻辑，需遵循快速失败、幂等性、业务无损原则。实际开发中，很多坑都出在这里。

1. 实现方式

方式一：注解式（Spring Boot）

这种方式最常用，适合大部分场景。注意 Fallback 方法必须与原方法签名一致（通常额外添加 Exception 参数）。

@Service
public class OrderService {
    @CircuitBreaker(name = "orderService", fallbackMethod = "getOrderFallback")
    public Order getOrder(Long orderId) {
        return restTemplate.getForObject("http://order-service/orders/" + orderId, Order.class);
    }

    private Order getOrderFallback(Long orderId, Exception ex) {
        log.warn("服务降级，orderId: {}", orderId, ex);
        // 策略 1：返回本地缓存
        return orderCache.get(orderId);
        // 策略 2：返回默认值
        // return new Order(orderId, "默认商品", 0);
        // 策略 3：抛出自定义异常（由上层处理）
        // throw new ServiceDegradeException("订单服务暂不可用");
    }
}

方式二：编程式（细粒度控制）

如果你需要更灵活的控制，比如动态决定要不要降级，可以用这种函数式写法。

CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("orderService");
Supplier<Order> decorated = CircuitBreaker.decorateSupplier(
    circuitBreaker,
    () -> restTemplate.getForObject("http://order-service/orders/" + orderId, Order.class)
);

// 执行并降级
Try<Order> result = Try.ofSupplier(decorated).recover(throwable -> {
    log.error("调用失败，执行降级", throwable);
    return getFromCache(orderId); // Fallback 逻辑
});

2. Fallback 策略矩阵

3. 生产陷阱与最佳实践

陷阱 1：Fallback 本身故障

千万别在降级逻辑里再去调可能挂掉的服务，否则就是雪上加霜。

// 错误：Fallback 中再次调用可能失败的服务
private Order fallback(Long id) {
    return anotherService.getOrder(id); // 若 anotherService 也挂了，级联失败
}

// 正确：Fallback 必须**本地处理**，禁止远程调用
private Order fallback(Long id) {
    return cache.get(id); // 仅本地缓存或默认值
}

陷阱 2：非幂等操作降级

如果是写操作（比如扣减库存），不能简单返回成功。应该记录待处理日志由定时任务补偿，或者明确返回操作失败让用户重试。

陷阱 3：降级风暴

当 A 服务降级调用 B 服务，B 服务又降级调用 C 服务……形成降级链。解决思路很简单：Fallback 中禁止再发起 Feign/HTTP 调用，保持本地快速返回。

三、限流算法：令牌桶 vs 漏桶

限流（Rate Limiting）是主动防御手段，防止流量突增压垮服务。选对算法能省不少事。

1. 令牌桶（Token Bucket）

原理：

• 桶以固定速率（如 10 个/秒）生成令牌
• 请求需获取令牌才能执行，桶空则拒绝或等待
• 桶容量（burst size）允许突发流量（如桶容量 100，可瞬间处理 100 请求）

Resilience4j 实现：

RateLimiterConfig config = RateLimiterConfig.custom()
    .limitForPeriod(10) // 每周期允许 10 个请求
    .limitRefreshPeriod(Duration.ofSeconds(1)) // 周期 1 秒
    .timeoutDuration(Duration.ofMillis(100)) // 获取令牌等待时间
    .build();
RateLimiter rateLimiter = RateLimiter.of("orderApi", config);
Supplier<Order> restrictedCall = RateLimiter.decorateSupplier(
    rateLimiter,
    () -> orderService.getOrder(id)
);

特点：

• ✅ 允许突发流量（桶内令牌可瞬间消耗）
• ✅ 平滑限流（长期速率稳定）
• ❌ 实现复杂（需维护令牌生成线程）

适用场景：API 网关、突发流量场景（如整点秒杀）

2. 漏桶（Leaky Bucket）

原理：

• 请求像水一样流入桶（任意速率）
• 桶以固定速率（如 10 个/秒）漏出处理
• 桶满则溢出（拒绝请求），强制平滑

实现方式（队列 + 定时器）：

// 漏桶简化实现
public class LeakyBucket {
    private final BlockingQueue<Request> queue;
    private final int capacity; // 桶容量
    private final int leakRate; // 漏出速率（个/秒）

    public boolean tryAcquire(Request request) {
        if (queue.remainingCapacity() == 0) {
            return false; // 桶满，拒绝
        }
        queue.offer(request);
        return true;
    }

    // 定时任务：按 leakRate 速率处理队列
    @Scheduled(fixedRate = 1000 / leakRate)
    public void leak() {
        Request req = queue.poll();
        if (req != null) process(req);
    }
}

特点：

• ✅ 绝对平滑（输出速率恒定，无突发）
• ✅ 实现简单（FIFO 队列）
• ❌ 无法应对突发（即使桶未满，也需排队等待漏出）
• ❌ 内存风险（桶满前请求堆积在内存）

适用场景：下游服务严格限流（如数据库连接池、第三方 API 配额）

3. 算法对比与选型

混合策略：

• 网关层：令牌桶（应对突发）
• 服务层：漏桶（保护数据库）
• 接口级：滑动窗口（精确控制）

4. 滑动窗口（Sliding Window）

Resilience4j 默认采用滑动窗口统计指标，也可用于限流：

计数滑动窗口：

• 将时间分为多个小窗口（如 1 秒分 10 个 100ms 窗口）
• 统计最近 N 个窗口的请求数
• 相比固定窗口，避免临界突发（如 1.9s 和 2.1s 各来 10 个请求，固定窗口认为合规，滑动窗口识别为 20 个/200ms）

// Resilience4j 滑动窗口限流
RateLimiterConfig config = RateLimiterConfig.custom()
    .limitForPeriod(100) // 窗口内 100 个请求
    .limitRefreshPeriod(Duration.ofMinutes(1)) // 窗口大小 1 分钟
    .build();

四、生产实践：熔断 + 降级 + 限流组合拳

1. 配置层级

resilience4j:
  circuitbreaker:
    instances:
      orderService:
        failureRateThreshold: 60
        waitDurationInOpenState: 10s
  ratelimiter:
    instances:
      orderApi:
        limitForPeriod: 1000
        limitRefreshPeriod: 1s
  retry:
    instances:
      orderRetry:
        maxAttempts: 3
        waitDuration: 500ms

2. 组合使用模式

@Service
public class OrderService {
    @CircuitBreaker(name = "orderService", fallbackMethod = "fallback")
    @RateLimiter(name = "orderApi") // 先限流，再熔断
    @Retry(name = "orderRetry") // 失败重试
    public Order getOrder(Long id) {
        return httpCall(id);
    }

    private Order fallback(Long id, Exception ex) {
        return cache.get(id);
    }
}

执行顺序：Retry → CircuitBreaker → RateLimiter → Business Logic

3. 监控指标

# Prometheus 端点暴露
management:
  endpoints:
    web:
      exposure:
        include: health, metrics, prometheus

关键指标：

• resilience4j_circuitbreaker_state：熔断器状态（0=closed, 1=open, 2=half_open）
• resilience4j_circuitbreaker_calls：调用总数（tag：status=successful/failed）
• resilience4j_ratelimiter_available_permissions：剩余令牌数

五、总结

终极原则：限流是预防，熔断是止损，降级是兜底。三者结合，构建弹性微服务架构。