Sentinel熔断案例

本文目录导读：

1. 目录导读
2. 惨案回顾：一次未加熔断的分布式事故全记录
3. 核心拆解：Sentinel熔断的三大状态机与阈值算法
4. 手把手配置：基于Spring Cloud Alibaba的Sentinel熔断规则详解
5. 避坑指南：常见误区与性能损耗的平衡艺术
6. FAQ速答：关于熔断降级，你必须知道的5个问题

Sentinel熔断实战：一场由“雪崩效应”引发的紧急救援

目录导读

1. 惨案回顾：一次未加熔断的分布式事故全记录
2. 核心拆解：Sentinel熔断的三大状态机与阈值算法
3. 手把手配置：基于Spring Cloud Alibaba的熔断规则详解
4. 避坑指南：常见误区与性能损耗的平衡艺术
5. FAQ速答：关于熔断降级，你必须知道的5个问题

惨案回顾：一次未加熔断的分布式事故全记录

凌晨2:14，某电商平台“秒杀”模块的依赖服务（库存服务）因数据库连接池打满而响应耗时飙升至12秒，由于下游服务未配置任何熔断策略，上游订单服务在30秒内迅速堆积了8万请求线程，这些线程阻塞后，导致订单服务的Tomcat线程池耗尽，紧接着网关、用户服务也开始连环超时——这就是典型的“雪崩效应”。

事后复盘发现：当时库存服务的错误率已达45%，但调用方依然在疯狂重试，最终把整个核心链路打瘫。如果没有Sentinel熔断，这场事故至少会持续40分钟；而配置熔断后，10秒内即可“拦腰截断”故障流量，保护系统恢复。

核心拆解：Sentinel熔断的三大状态机与阈值算法

Sentinel的熔断器基于 “Closed → Open → Half-Open” 状态机：

• Closed（关闭）：正常调用，当满足熔断触发条件（如错误率>50%、慢调用比例>60%、或异常数>100），进入Open。
• Open（打开）：所有请求直接拒绝，快速失败，经过指定的“休眠时间”（如5秒）后，进入Half-Open。
• Half-Open（半开）：允许少量探测请求通过，若探测成功，则重置为Closed；若失败，则重新回到Open。

三个关键阈值算法（你需要记住）

问：熔断和降级是一回事吗？ 答：不完全等同，熔断是主动断开故障依赖（侧重保护系统）；降级是提供fallback兜底结果（侧重用户体验），Sentinel通常将二者结合：熔断后自动走degrade方法返回默认值。

手把手配置：基于Spring Cloud Alibaba的Sentinel熔断规则详解

# application.yml
spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080
      datasource:
        ds1:
          nacos:
            server-addr: ${NACOS_ADDR:localhost:8848}
            dataId: sentinel-degrade-rules
            groupId: SENTINEL_GROUP
            rule-type: degrade

在Nacos中发布规则（JSON格式）：

[
  {
    "resource": "GET:/api/order/create",
    "grade": 1,
    "count": 1000,
    "timeWindow": 10,
    "minRequestAmount": 5,
    "statIntervalMs": 1000,
    "slowRatioThreshold": 0.3,
    "maxAllowedRtMs": 1500
  }
]

代码侧实现（Java）：

@SentinelResource(value = "getOrder", 
    fallback = "getOrderFallback", 
    fallbackClass = OrderFallbackHandler.class)
public Order getOrder(Long id) {
    // 调用远程库存服务
    return restTemplate.getForObject("http://stock-service/stock", Order.class);
}
public static Order getOrderFallback(Long id, Throwable ex) {
    // 兜底逻辑：返回缓存或提示“库存繁忙”
    return Order.builder().status("BUSY").msg("系统繁忙，请稍后重试").build();
}

关键点：@SentinelResource 必须配置fallback或blockHandler，否则不会执行降级逻辑；resource名称要与Nacos规则中的资源名一致。

避坑指南：常见误区与性能损耗的平衡艺术

• 误区1：熔断阈值设太大，如异常数设1000，但系统每秒请求才50，故障初期根本达不到阈值，雪崩已经发生了，建议结合压测结果，minRequestAmount（最小请求数）设为5-10，防止偶发抖动触发。
• 误区2：熔断时间过短。timeWindow若设3秒，故障恢复前可能反复进入Open→Half-Open→Open，造成“熔断抖动”，建议设5-15秒，且配合statIntervalMs（统计窗口）至少为1秒。
• 误区3：不区分资源粒度，对整个接口熔断，而不是对依赖服务维度，务必以@SentinelResource注解细粒度定义，如/api/order/create与/api/order/get分开配置。
• 性能损耗：Sentinel默认按秒统计，内存开销极小（每个窗口约1KB），但若开启流量控制+熔断+热点规则多处叠加，每次调用会增加约0.5ms的耗时，建议在网关层只启用粗粒度熔断，业务层细粒度。

FAQ速答：关于熔断降级，你必须知道的5个问题

Q1：熔断后请求会立刻返回失败吗？ 不一定，若配置了fallback，会执行降级逻辑（如返回默认数据、缓存数据或空对象）；若无fallback，则抛出DegradeException。

Q2：如何让熔断规则支持动态刷新？ 使用Nacos或Apollo作为数据源，修改配置后推送，Sentinel会在10秒内自动更新规则，无需重启应用。

Q3：Sentinel与Hystrix相比，熔断有什么优势？ Sentinel支持基于QPS的流量整形、热点参数限流、系统自适应保护，且无需重写所有业务代码（Hystrix需要继承Command）。

Q4：熔断和线程池隔离一定要用吗？ Sentinel默认不开启线程池隔离（因为线程切换有开销），而是采用信号量隔离，若依赖响应极慢且并发极高，可考虑信号量隔离（maxConcurrentRequests限制为100）。

Q5：如何监控熔断是否生效？ 访问DashBoard（默认8080端口），在“熔断降级”页签查看每个资源的“通过QPS”、“拒绝QPS”和“熔断次数”，当熔断次数持续增长，说明规则生效且故障未恢复。

Q6：熔断恢复后，如何验证服务健康？ 半开状态会放行部分探测请求，建议在fallback中记录日志，并配合健康检查端点（如/actuator/health），确保依赖服务恢复后才全量流量进入。

最后送你一句话：熔断不是“防病疫苗”，而是“止血绷带”——它不解决根本故障，但能让你在风暴中活下来，等到数据库重启、连接池恢复、代码修复那一刻。配置好你的Sentinel熔断规则，然后睡个好觉吧。