Sentinel 熔断降级和限流怎么接进业务

先说结论

• Sentinel 更适合保护关键资源和下游依赖，不适合到处一把梭全加上
• 限流规则要围绕真实 SLA、容量和压测结果来定，不能靠拍脑袋
• 熔断和降级一定要配有明确的降级结果，否则只会把错误藏起来

一、先想清楚要保护谁

在商城项目里，更适合优先保护这些位置：

• 秒杀接口
• 下单接口
• 商品详情热点接口
• 对库存、支付、营销、搜索等下游的调用资源

如果每个 Controller、每个方法都加，最后规则会很快失控。

二、三类规则分别适合什么场景

1. 限流

适合控制高频入口流量，比如秒杀页、下单确认、营销活动接口。

2. 熔断

适合保护慢依赖或错误率突然升高的下游，比如支付服务、搜索服务、库存服务。

3. 系统保护

适合当线程数、RT、系统负载明显异常时，从系统层给应用兜一道保护网。

三、接进业务时更稳的做法

1. 规则按业务资源命名

别只按方法名配规则，更适合按“秒杀下单”“支付确认”“商品详情查询”这类业务资源来配。

2. 降级返回要提前设计

比如：

• 秒杀接口被限流后返回“当前抢购人数过多，请稍后再试”
• 搜索服务熔断后返回基础推荐结果
• 营销服务异常时，先走无优惠兜底

如果没有明确降级结果，业务方最后看到的还是一片 500。

3. 规则和压测一起校准

阈值最好基于：

• 峰值流量
• 单机承载能力
• 下游容量
• 压测结果和历史活动数据

四、最容易踩的坑

1. 把限流阈值设得非常激进

结果系统还没真正到极限，业务先被自己限死了。

2. 熔断后没有 fallback 语义

熔断本来是保护系统，结果用户看到的是更难理解的异常。

3. 规则只上线，从不回顾

大促前一套阈值、日常一套流量、发版后一套链路，如果从不调整，规则会越来越失真。

4. 只在应用层限流，不看网关和前端协同

真正的大流量场景里，更稳的是网关、前端、业务服务多层配合，而不是只靠单点限流。

五、上线后建议看哪些指标

• 资源限流触发次数
• 熔断开启次数和持续时长
• fallback 命中率
• 规则变更记录
• 限流前后 RT、错误率和下游压力变化

总结

Sentinel 接进业务最重要的不是“把注解加上”，而是先确定保护对象、再确定规则边界、最后定义好降级结果。规则围绕业务资源配，阈值围绕真实容量定，才能在高峰和异常时真正兜住系统。