服务熔断降级核心概念与选型

服务间依赖是雪崩的放大器：一个下游慢，上游线程池占满，最终拖垮整条链路。熔断、限流、降级是三道防线。本文讲清概念与策略，并给出三大主流库的选型对比。

三道防线：限流、熔断、降级

定义与区别

限流：保护自己不被流量打垮（入口控制）
  场景：秒杀、大促、恶意刷接口

熔断：保护自己不被打垮的下游拖垮（出口控制）
  场景：下游服务超时、异常率飙升

降级：主动放弃次要功能，保住核心链路（策略兜底）
  场景：搜索挂了 → 返回热门推荐；推荐挂了 → 返回空

机制	保护对象	触发条件	恢复方式
限流	自己	请求速率/并发超阈值	阈值下降后自动恢复
熔断	自己	下游错误率/慢调用超阈值	熔断窗口后试探恢复
降级	核心链路	依赖不可用/主动开关	依赖恢复后切换回

三者的关系

流量进入 → 限流（挡掉多余请求）
   │
   ▼
调用下游 → 熔断（下游异常时快速失败）
   │
   ▼
失败兜底 → 降级（返回默认值/缓存/提示）

熔断的原理

状态机

CLOSED（关闭，正常）
   │ 错误率 > 阈值（如 50%）或慢调用超阈值
   ▼
OPEN（打开，拒绝请求）
   │ 冷却时间到（如 5s）
   ▼
HALF_OPEN（半开，放行试探请求）
   │ 试探成功 → CLOSED
   │ 试探失败 → OPEN
   ▼
（循环）

CLOSED ──失败率超标──▶ OPEN
   ▲                      │
   │                      ▼
   └────试探成功───── HALF_OPEN（冷却期后放行少量请求）

关键参数

参数	含义
失败率阈值	触发熔断的错误比例（如 50%）
慢调用阈值	超过多少毫秒算慢调用
最小请求数	窗口内至少多少请求才评估（避免小流量误熔断）
滑动窗口	统计评估的时间窗（如 10s）
冷却时间	OPEN 保持时长（如 5s）

降级的策略

常见降级方式

策略	说明	例子
默认值	返回预设默认结果	推荐列表返回空
缓存兜底	用历史缓存数据	价格用上次成功缓存
快速失败	直接返回错误提示	提示稍后重试
兜底接口	降级到备用实现	主数据源 → 备数据源
静默	不阻塞主流程	统计上报失败直接忽略

降级分级

L1 核心链路：不可降级（支付、下单主流程）
L2 重要链路：可降级为缓存（价格、库存展示）
L3 次要链路：可降级为默认值/空（推荐、榜单）
L4 边缘链路：可静默丢弃（日志、埋点上报）

三大库对比

一览表

维度	Sentinel	Hystrix（已停更）	Resilience4j
维护状态	活跃（阿里）	已进入维护模式	活跃（Netflix 官方推荐）
编程模型	注解 + 切面	注解 + 命令包装	函数式装饰器
限流	强（令牌桶/漏桶/滑动窗口）	弱（仅线程池隔离）	RateLimiter 模块
熔断	基于响应时间/异常比例	基于错误率	CircuitBreaker 模块
隔离	信号量（默认无线程池）	线程池/信号量	Bulkhead（线程池/信号量）
集群流控	支持（Token Server）	不支持	不支持
动态规则	Nacos/Apollo 等数据源	无	配置中心配合
控制台	官方 Dashboard	有限	无（需集成 Prometheus）
预热/排队	WarmUp、排队等待	无	无
轻量级	中	重（依赖多）	轻（模块化）
Spring Cloud 整合	良好（Gate/Feign 适配）	旧版生态	官方推荐

选型建议

阿里巴巴/国内生态、需要集群流控与热点控制 → Sentinel
纯 Spring Cloud 新项目、追求轻量与模块化 → Resilience4j
老项目仍在用 Hystrix → 尽快迁移（停止更新）

Sentinel 特点详解

核心能力

1. 丰富的流控策略
   ├─ QPS 快速失败
   ├─ WarmUp 预热（冷启动保护）
   ├─ 排队等待（令牌桶）
   └─ 热点参数限流（按参数维度）

2. 熔断降级
   ├─ 慢调用比例
   ├─ 异常比例
   └─ 异常数

3. 生态整合
   ├─ 与 Nacos 规则下推
   ├─ 与 Gateway 网关流控
   ├─ 与 OpenFeign 适配
   └─ 官方控制台监控

场景示例

场景一：秒杀接口限流
  规则：QPS = 1000，超出排队/拒绝
  效果：保护下游数据库

场景二：下单接口熔断
  规则：响应时间 > 500ms 的比例 > 30% 熔断
  效果：支付服务故障时快速失败

场景三：热点商品限流
  规则：商品 ID 维度，爆款单独高阈值
  效果：正常商品不误伤

Resilience4j 特点详解

模块化设计

Resilience4j 按需引入模块：
  resilience4j-circuitbreaker  熔断
  resilience4j-ratelimiter     限流
  resilience4j-bulkhead        舱壁隔离
  resilience4j-retry           重试
  resilience4j-timelimiter     超时
  resilience4j-cache           缓存

函数式装饰器

// 装饰器链：重试 → 熔断 → 限流 → 超时
Retry.decorate(
    CircuitBreaker.decorate(
        RateLimiter.decorate(
            TimeLimiter.decorate(
                () -> orderService.createOrder(order))))
);

事件与指标

事件驱动：状态变更、失败、成功均有事件回调
指标输出：接入 Micrometer → Prometheus → Grafana

限流算法对比

算法	原理	特点
固定窗口	每秒一个计数器	简单，临界突刺问题
滑动窗口	时间切片统计	平滑，Sentinel 默认
漏桶	队列匀速流出	强行限速，处理突发差
令牌桶	按速率放令牌	允许突发，Guava/RateLimiter
滑动日志	逐请求记录时间戳	精确，内存开销大

令牌桶示意：
   每秒生成 r 个令牌 → 桶（容量 b）
   请求到来需消耗 1 个令牌
   桶空 → 拒绝/排队
   优点：允许短时突发（桶内积攒的令牌）

生产实践要点

配置模板

# Sentinel 限流
spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080

# Resilience4j 熔断
resilience4j:
  circuitbreaker:
    instances:
      orderService:
        failure-rate-threshold: 50
        wait-duration-in-open-state: 5s
        sliding-window-size: 10

注意事项

1. 熔断阈值要留余量：下游实际容量 × 80%
2. 降级结果要可辨识：日志记录"降级返回"，避免排查困惑
3. 限流与熔断叠加：入口限流 + 出口熔断
4. 规则要有开关：上线前演练，可一键关闭
5. 监控告警配套：熔断触发次数、降级比例要告警

常见问题

1. 限流和熔断先做哪个？ 先限流（保护自己），再熔断（保护依赖），最后降级（兜底体验）。
2. 熔断误伤怎么办？ 调整最小请求数与滑动窗口，避免小流量误判。
3. 降级数据一致性？ 降级返回的缓存/默认值标注来源，最终一致由补偿机制保证。
4. Hystrix 还能用吗？ 已停止更新，新项目不要用，老项目尽快迁移。