SpringCloud 核心组件解析：服务熔断和降级

SpringCloud 核心组件解析：服务熔断与降级（Resilience4J）

技术栈 ：Spring Boot 3.2.0 + Spring Cloud 2023.0.0 + Resilience4J

已不维护 ：Netflix Hystrix → 替代用 Resilience4J

Alibaba 方案：Sentinel（见 Alibaba 系列第 4 章）

4.1 是什么 --- 熔断/降级/限流概念与类比

4.1.1 生活化类比：家庭电路的保险丝

复制代码

         ┌─────────┐
电网 ───→│ 电表    │──┬── 空调（大功率）
         └────┬────┘  ├── 冰箱
              │       ├── 电视
           ┌──┴──┐    └── 热水器 ──💥 短路！
           │保险丝│
           └─────┘
              │ 熔断！整屋断电
              │
              ↓
         保护了所有电器和线路

保险丝的作用：某个支路短路时，保险丝熔断切断整屋电源，防止火灾烧毁整栋楼。

微服务中的"保险丝"就是熔断器（Circuit Breaker）：某个下游服务故障时，快速切断对该服务的调用，防止级联雪崩把整个系统拖垮。

4.1.2 三个核心概念对比

概念	比喻	触发条件	效果
熔断 Circuit Breaker	保险丝	失败率超过阈值	断开链路，快速失败
降级 Fallback	备选方案	熔断后或服务不可用	返回预设兜底值
舱壁 Bulkhead	船舱隔板	并发数超限	隔离资源，防止耗尽
限流 Rate Limiter	收费站	QPS 超阈值	拒绝超额请求

4.1.3 熔断器状态机

复制代码

     ┌──────────┐
     │  CLOSED   │ ← 正常状态，所有请求正常通过
     │  (闭合)    │
     └─────┬─────┘
           │ 失败率达到阈值（如 50%）
           ▼
     ┌──────────┐
     │   OPEN    │ ← 熔断状态，所有请求直接拒绝（快速失败）
     │  (断开)    │   等待 waitDurationInOpenState（如 5s）
     └─────┬─────┘
           │ 等待时间到
           ▼
     ┌──────────┐
     │HALF_OPEN  │ ← 半开状态，允许少量试探请求
     │  (半开)    │
     └─────┬─────┘
           │
      ┌────┴────┐
      │         │
   成功       失败
      │         │
      ▼         ▼
   CLOSED     OPEN
  (恢复正常)  (重新熔断)

4.2 为什么 --- 从 Hystrix 到 Resilience4J

4.2.1 Hystrix 的辉煌与落幕

Hystrix 是 Netflix 开源的熔断器库，2011 年发布，是微服务容错的先驱。

Hystrix 的核心贡献（概念被后续所有框架继承）：

复制代码

┌─────────────────────────────────────┐
│             Hystrix                 │
│  ┌──────────┐  ┌───────────────┐   │
│  │线程池隔离  │  │  信号量隔离    │   │
│  └──────────┘  └───────────────┘   │
│  ┌──────────┐  ┌───────────────┐   │
│  │  熔断器   │  │   Fallback    │   │
│  └──────────┘  └───────────────┘   │
│  ┌──────────────────────────────┐   │
│  │        Hystrix Dashboard     │   │
│  └──────────────────────────────┘   │
└─────────────────────────────────────┘

为什么被抛弃：

原因	详情
官方停更	2018 年 Netflix 宣布进入维护模式，不再开发新功能
重量级	运行时依赖多，对性能有可见影响
设计缺陷	线程池隔离默认策略导致大量线程切换开销
替代品成熟	Resilience4J 更轻量、函数式设计、性能更好

4.2.2 Resilience4J 的优势

对比维度	Hystrix	Resilience4J
架构	外部依赖多	纯 Java 库，零外部依赖
API 风格	命令式（继承 HystrixCommand）	函数式（高阶装饰器）
隔离策略	线程池（默认）+ 信号量	信号量 + 线程池（可选）
Spring Boot 集成	Spring Cloud Netflix	Spring Cloud Circuit Breaker 抽象
模块化	单体 jar	按需引入 core/bulkhead/retry/timelimiter
内存占用	较大	较小

4.3 怎么做 --- Resilience4J 完整实战

4.3.1 小 Demo：先暴露痛点

没有熔断保护的情况：

java 复制代码

// ❌ 危险写法：无限重试
@GetMapping("/feign/pay/get/{id}")
public ResultData getPayInfo(@PathVariable("id") Integer id) {
    try {
        return payFeignApi.getPayInfo(id);
    } catch (Exception e) {
        // 疯狂重试，耗尽线程池！
        return payFeignApi.getPayInfo(id);  // 又抛异常
        // → 级联雪崩：一个服务拖死所有调用方
    }
}

后果：

支付服务故障 → 订单服务线程全部卡在等待 → Tomcat 线程池耗尽 → 整个订单服务不可用
调用链路中的其他服务也被拖垮 → 级联故障（Cascading Failure）

4.3.2 引入 Resilience4J

步骤 ①：依赖

xml 复制代码

<!-- Resilience4J 已包含在 Spring Cloud 依赖管理中 -->
<!-- 通过 spring-cloud-starter-openfeign 的 circuitbreaker 启用 -->

步骤 ②：开启断路器

yaml 复制代码

# cloud-consumer-feign-order80/application.yml
spring:
  cloud:
    openfeign:
      circuitbreaker:
        enabled: true  # ← 关键开关！

4.3.3 模式一：熔断（Circuit Breaker）--- COUNT_BASED

原理：在一个滑动窗口内（如 6 个请求），如果失败率达到阈值（如 50%），断路器打开。

yaml 复制代码

resilience4j:
  circuitbreaker:
    configs:
      default:
        failureRateThreshold: 50       # 失败率 50% 触发熔断
        slidingWindowType: COUNT_BASED # 基于请求次数统计
        slidingWindowSize: 6           # 窗口大小 = 6 个请求
        minimumNumberOfCalls: 6        # 至少 6 个请求才开始计算失败率
        automaticTransitionFromOpenToHalfOpenEnabled: true
        waitDurationInOpenState: 5s    # OPEN → HALF_OPEN 等 5 秒
        permittedNumberOfCallsInHalfOpenState: 2  # 半开最多放 2 个请求试探
        recordExceptions:
          - java.lang.Exception
    instances:
      cloud-payment-service:
        baseConfig: default

过程模拟：

复制代码

请求 1-2: ✅ ✅  → 失败率 0%
请求 3-4: ❌ ❌  → 失败率 50%
请求 5-6: ❌ ❌  → 失败率 66% > 50% → 🔴 OPEN!
请求 7-8: 直接拒绝（5 秒内）
请求 9-10: 半开试探 → ✅ ✅ → CLOSED (恢复)

代码：

java 复制代码

// Consumer 端
@GetMapping(value = "/feign/pay/circuit/{id}")
@CircuitBreaker(name = "cloud-payment-service", fallbackMethod = "myCircuitFallback")
public String myCircuitBreaker(@PathVariable("id") Integer id) {
    return payFeignApi.myCircuit(id);
}

// fallback 签名必须：原方法参数 + Throwable
public String myCircuitFallback(Integer id, Throwable t) {
    return "myCircuitFallback，系统繁忙，请稍后再试-----/(ㄒoㄒ)/~~";
}

注解参数说明：

参数	说明
`name`	断路器实例名，对应配置中的 `instances` key
`fallbackMethod`	降级方法名（反射调用，签名必须匹配）

4.3.4 模式一补充：TIME_BASED

yaml 复制代码

resilience4j:
  timelimiter:
    configs:
      default:
        timeout-duration: 10s  # ⚠️ 神坑！默认才 1s，不配置直接超时
  circuitbreaker:
    configs:
      default:
        failureRateThreshold: 50
        slowCallDurationThreshold: 2s   # 超过 2s 视为慢调用
        slowCallRateThreshold: 30       # 慢调用比例 > 30% 就熔断
        slidingWindowType: TIME_BASED   # 基于时间窗口
        slidingWindowSize: 2            # 2 秒窗口
        minimumNumberOfCalls: 2
        waitDurationInOpenState: 5s

4.3.5 模式二：舱壁（Bulkhead）--- SEMAPHORE vs THREADPOOL

什么是舱壁：船底的隔板设计------一个舱进水，其他舱不受影响。

复制代码

无舱壁：                    有舱壁（maxConcurrentCalls=2）：
┌──────────────┐            ┌──────────────┐
│ 共享线程池    │            │ 舱壁1 (2线程) │→ 耗时的支付服务
│ (耗尽!)      │            ├──────────────┤
│ ├ 支付服务🔴  │            │ 舱壁2 (2线程) │→ 正常的订单查询
│ ├ 订单查询🔴  │            └──────────────┘
│ └ 用户服务🔴  │
└──────────────┘

信号量模式（轻量）：

yaml 复制代码

resilience4j:
  bulkhead:
    configs:
      default:
        maxConcurrentCalls: 2    # 最大并发 2 个
        maxWaitDuration: 1s      # 超出的请求等待 1s 就进 fallback
    instances:
      cloud-payment-service:
        baseConfig: default

线程池模式（重量，完全隔离）：

yaml 复制代码

resilience4j:
  timelimiter:
    configs:
      default:
        timeout-duration: 10s
  thread-pool-bulkhead:
    configs:
      default:
        core-thread-pool-size: 1
        max-thread-pool-size: 1
        queue-capacity: 1
    instances:
      cloud-payment-service:
        baseConfig: default
# ⚠️ 线程池模式需要 spring.cloud.openfeign.circuitbreaker.group.enabled = false

代码（线程池模式）：

java 复制代码

@GetMapping(value = "/feign/pay/bulkhead/{id}")
@Bulkhead(name = "cloud-payment-service", fallbackMethod = "myBulkheadPoolFallback",
          type = Bulkhead.Type.THREADPOOL)  // ← 切换为线程池模式
public CompletableFuture<String> myBulkheadTHREADPOOL(@PathVariable("id") Integer id) {
    System.out.println(Thread.currentThread().getName() + "\t" + "---开始进入");
    try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
    System.out.println(Thread.currentThread().getName() + "\t" + "---准备离开");
    return CompletableFuture.supplyAsync(() ->
        payFeignApi.myBulkhead(id) + "\t" + "Bulkhead.Type.THREADPOOL");
}

public CompletableFuture<String> myBulkheadPoolFallback(Throwable t) {
    return CompletableFuture.supplyAsync(() ->
        "隔板超出最大数量限制，系统繁忙，请稍后再试-----/(ㄒoㄒ)/~~");
}

对比	SEMAPHORE	THREADPOOL
隔离级别	同一线程，信号量计数	独立线程池
性能开销	低	高（线程切换）
超时支持	不支持异步超时	支持
返回值	同步	`CompletableFuture<T>` 异步
适用场景	非阻塞/轻量	需要完全隔离/可能长时间阻塞

4.3.6 模式三：限流（Rate Limiter）

yaml 复制代码

resilience4j:
  ratelimiter:
    configs:
      default:
        limitForPeriod: 2          # 每次刷新周期最多 2 个
        limitRefreshPeriod: 1s     # 每 1s 刷新一次
        timeout-duration: 1        # 等待许可的最长时间(ms)
    instances:
      cloud-payment-service:
        baseConfig: default

java 复制代码

@GetMapping(value = "/feign/pay/ratelimit/{id}")
@RateLimiter(name = "cloud-payment-service", fallbackMethod = "myRatelimitFallback")
public String myBulkhead(@PathVariable("id") Integer id) {
    return payFeignApi.myRatelimit(id);
}

public String myRatelimitFallback(Integer id, Throwable t) {
    return "你被限流了，禁止访问/(ㄒoㄒ)/~~";
}

4.4 深入原理 --- Resilience4J 装饰器模式

复制代码

@CircuitBreaker + @Bulkhead + @RateLimiter + @Retry + @TimeLimiter

调用链：
┌─────────────┐
│ @TimeLimiter│ ← 超时控制（最外层）
│     ↓       │
│ @CircuitBreaker│ ← 熔断判断
│     ↓       │
│  @Retry     │ ← 重试机制
│     ↓       │
│ @Bulkhead   │ ← 并发限制
│     ↓       │
│ @RateLimiter│ ← 速率控制
│     ↓       │
│  实际调用    │
└─────────────┘

Resilience4J 使用函数式装饰器模式：每个能力都是一个 Decorator，像俄罗斯套娃一样嵌套包裹实际的调用。

4.5 对比分析

特性	Resilience4J	Hystrix	Sentinel
维护状态	活跃 ✅	停止 ❌	活跃 ✅
API 风格	函数式	命令式	注解+控制台
Spring 集成	`@CircuitBreaker` 等	`@HystrixCommand`	`@SentinelResource`
控制台	❌	Dashboard（已废）	✅ Sentinel Dashboard
规则热更新	配置文件	配置文件	控制台实时下发
适用场景	中小型项目	遗留项目	大型/阿里生态

4.6 面试题

Q1：Hystrix 的线程池隔离和信号量隔离有什么区别？

答：

线程池隔离：每个依赖服务分配独立线程池，完全隔离，支持超时和异步。但线程切换开销大。
信号量隔离：主线程内用信号量控制并发数，轻量但无法处理超时，不适用于网络调用。
Resilience4J 中对应 Bulkhead.Type.THREADPOOL 和 Bulkhead.Type.SEMAPHORE。

Q2：熔断和降级的关系？

答：熔断是手段，降级是结果。熔断器打开后，请求不再发往下游，而是执行 fallback 逻辑返回预设值------这个过程叫降级。简言之：熔断触发降级。

Q3：为什么 Resilience4J 的 TimeLimiter 默认超时只有 1 秒？

答：这是设计上的保守默认值，迫使用户主动配置。如果所有调用都无限等待，一旦下游变慢，线程池很快耗尽。生产环境必须根据 SLA 显式配置 timeout-duration，通常设为 5-30 秒。

4.7 踩坑指南

坑	现象	原因	解决
🔴 TimeLimiter 默认 1s	所有请求都进 fallback	默认 `timeout-duration: 1s`，大多数接口不够	显式设置 `resilience4j.timelimiter.configs.default.timeout-duration: 10s`
🔴 ThreadPoolBulkhead + Feign	Feign 调用不生效	线程池模式需关闭 Feign 分组	设置 `spring.cloud.openfeign.circuitbreaker.group.enabled: false`
🔴 fallbackMethod 不匹配	运行时 `NoSuchMethodException`	fallback 方法签名必须包含原参数 + Throwable	严格检查方法签名，IDEA 不会有编译提示
🔴 COUNT_BASED 不生效	明明失败 3 次了还没熔断	`minimumNumberOfCalls` 默认可能 > 实际请求数	确保 `minimumNumberOfCalls` ≤ `slidingWindowSize`
🔴 @Bulkhead + @CircuitBreaker 顺序	预期行为不符合	注解顺序影响执行链	推荐先熔断再舱壁：`@CircuitBreaker` 外层，`@Bulkhead` 内层

4.8 章节总结

要点	说明
三大保护机制	熔断（失败率过高自动切断）、舱壁（限制并发防止耗尽）、限流（控制 QPS）
状态机	CLOSED → OPEN → HALF_OPEN → CLOSED，`waitDurationInOpenState` 核心参数
TimeLimiter	默认 1s！必须显式配置，否则所有慢调用的请求都进 fallback
装饰器链	TimeLimiter → CircuitBreaker → Retry → Bulkhead → RateLimiter → 实际调用
与 Feign 整合	`spring.cloud.openfeign.circuitbreaker.enabled: true` 一步开启
Hystrix 遗留	了解线程池隔离、信号量隔离、Hystrix Dashboard 概念即可，时代已过