熔断与舱壁

下游 持续失败 时，调用方应 快速失败 而非继续打挂掉的依赖。断路器（Circuit Breaker） 统计失败率，超阈值则 OPEN；舱壁（Bulkhead） 用 隔离线程池 限制故障域。

学习目标

• 理解 Closed / Open / Half-Open 三状态
• 区分熔断、重试、超时、降级的组合
• 深入 Resilience4j 见 sc-circuit-breaker

三状态

状态	行为
Closed	正常调用，统计失败率
Open	直接拒绝或 fallback
Half-Open	试探少量请求，成功则关闭

失败率 > 50% ──► OPEN (10s)
                    │
                    ▼ Half-Open：放 3 个试探请求
              成功 ──► Closed
              失败 ──► 继续 OPEN

舱壁隔离

┌─────────────────────────────────┐
│         backend 线程池           │
│  ┌──────────┐  ┌──────────┐    │
│  │ 核心 API │  │ 外部调用 │    │  ← 各自上限
│  │ pool 20  │  │ pool 5   │    │
│  └──────────┘  └──────────┘    │
└─────────────────────────────────┘
     外部慢 ──► 只耗尽 5 线程，核心 API 仍可用

集成模式视角见 ip-circuit。

Spring Cloud 示例

@FeignClient(name = "course-service", fallback = CourseClientFallback.class)
public interface CourseClient {
    @GetMapping("/courses/{slug}")
    Course getBySlug(@PathVariable String slug);
}

resilience4j:
  circuitbreaker:
    instances:
      course-service:
        slidingWindowSize: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 10s

单机 CodeRoadMap

即使 一个 jar，调外部 webhook、OSS、邮件 API 也应 独立熔断——避免第三方拖死主线程。指标：resilience4j_circuitbreaker_state（prom-metrics）。

合理组合

有限重试 → 超时 → 熔断 → fallback → 限流

练习

• 停掉 mock 下游，观察 Half-Open 恢复