在高并发场景下，一个没有防护的接口就像一扇不设防的大门，流量一旦冲垮下游服务，故障会沿着调用链快速蔓延。Sentinel 是阿里巴巴开源的流量治理组件，它把限流、熔断、系统保护这些能力统一抽象成资源加规则的模式，配合可视化控制台可以做到规则动态生效、无需重启应用。这篇文章演示如何在 Spring Boot 项目中整合 Sentinel，并覆盖限流、熔断降级和规则持久化三个核心环节。
一、限流与熔断到底解决什么问题
限流和熔断经常被放在一起说，但它们针对的是两类不同的故障。限流保护的是自己，控制单位时间内进入系统的请求量，超出阈值的请求直接拒绝，防止应用被瞬时流量压垮。熔断保护的是下游，当依赖的服务出现大面积超时或异常时，暂时切断调用，快速失败并执行降级逻辑，避免线程被大量阻塞拖垮整个应用。
以一个订单接口为例，它依赖库存服务和用户服务。大促期间订单接口本身的 QPS 可能达到几千，这需要限流来控制入口流量；而库存服务一旦响应变慢，每个请求占用一个 Tomcat 线程等待 3 秒，线程池很快耗尽，这时就需要熔断机制在检测到慢调用比例过高时直接切断请求，走本地的降级逻辑，比如返回“系统繁忙，请稍后重试”。
理解这一点很重要，因为 Sentinel 中限流规则和熔断规则是分开配置的，参数含义也不同。限流看的是 QPS 或并发线程数，熔断看的是慢调用比例、异常比例或异常数，两者配合使用才能构建完整的防护体系。
二、Spring Boot 整合 Sentinel 的完整步骤
1. 引入依赖
Spring Boot 2.x 项目直接引入 spring-cloud-starter-alibaba-sentinel 即可，它会自动完成 Sentinel 核心库的引入和接口级别的资源适配：
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
<version>2021.0.5.0</version>
</dependency>如果版本对不上，也可以只引入 sentinel-spring-webmvc-adapter，但一般建议走 Spring Cloud Alibaba 的 BOM 管理版本，避免适配器与应用版本不兼容的问题。
2. 下载并启动控制台
控制台是一个独立的 Spring Boot 应用，从 Sentinel 的 GitHub Releases 页面下载 sentinel-dashboard jar 包后启动：
java -Dserver.port=8080 \
-Dsentinel.dashboard.auth.username=sentinel \
-Dsentinel.dashboard.auth.password=sentinel123 \
-jar sentinel-dashboard-1.8.6.jar然后在应用的配置文件中指定控制台地址：
spring:
application:
name: order-service
cloud:
sentinel:
transport:
dashboard: localhost:8080
port: 8719
eager: true这里的 8719 是应用与控制台通信的端口，默认从 8719 开始探测，被占用会自动递增。设置 eager: true 可以取消懒加载，应用一启动就向控制台注册，否则要等第一次请求进来才会出现在控制台的机器列表里，很多人以为整合失败其实只是没有触发请求。
3. 定义资源并编写降级逻辑
引入 web 适配器后，所有 HTTP 接口自动成为 Sentinel 资源，资源名就是接口的 URL。对于业务代码中的关键方法，可以用 @SentinelResource 注解显式声明：
@RestController
public class OrderController {
@GetMapping("/order/create")
@SentinelResource(value = "createOrder",
blockHandler = "createOrderBlockHandler",
fallback = "createOrderFallback")
public Result createOrder(Long userId) {
// 核心下单逻辑
return Result.ok();
}
// 处理限流、熔断被拒绝的请求
public Result createOrderBlockHandler(Long userId, BlockException e) {
return Result.fail("当前请求过多，请稍后重试");
}
// 处理业务运行时异常
public Result createOrderFallback(Long userId, Throwable t) {
return Result.fail("系统繁忙，已执行降级逻辑");
}
}这里要特别区分两个回调：blockHandler 处理的是 Sentinel 规则校验不通过抛出的 BlockException，比如限流被拒绝、熔断器打开；fallback 处理的是业务代码本身的异常。如果同时配置了两者，BlockException 会优先走 blockHandler，业务异常走 fallback。
还有一个容易踩的坑：blockHandler 方法的返回值和参数必须与原方法一致，并且要在末尾追加一个 BlockException 参数，否则启动后规则触发时会直接报错找不到处理方法。如果不想在每个方法旁边写回调，也可以抽取一个全局异常处理类，通过 blockHandlerClass 指定，方法需要是 static 的。
三、控制台配置限流与熔断规则
1. 流控规则
在控制台的簇点链路页面找到对应资源，点击“流控”按钮即可添加规则。阈值类型有两种：QPS 表示每秒请求数，比如设置为 100 表示单机每秒最多放行 100 个请求；并发线程数则限制同时处理该资源的线程数，适合保护那些执行较慢且依赖下游的接口。
流控效果也有三种选择：快速失败直接抛出 FlowException 走 blockHandler；Warm Up 冷启动模式，阈值从设定值的约三分之一经过预热时长逐步爬升，适合秒杀开抢瞬间防止缓存击穿；排队等待基于漏桶算法，让请求匀速通过，适合削峰填谷的消息类请求。对于大多数在线接口，快速失败是最稳妥的选择。
2. 熔断降级规则
熔断策略在 Sentinel 1.8 之后有三种。慢调用比例策略统计请求耗时超过最大 RT 的比例，超过阈值且请求数达到最小请求数时触发熔断，熔断时长结束后进入半开状态放一个请求试探。异常比例和异常数策略则分别按异常请求占比和异常次数判断。示例如下：
// 也可以用代码方式配置，效果与控制台一致
DegradeRule rule = new DegradeRule("createOrder")
.setGrade(RuleConstant.DEGRADE_GRADE_RT) // 慢调用比例
.setCount(0.5) // 慢调用比例阈值 50%
.setSlowRatioThreshold(0.5)
.setTimeWindow(10) // 熔断时长 10 秒
.setMinRequestAmount(5) // 最小请求数
.setStatIntervalMs(1000);
DegradeRuleManager.loadRules(Collections.singletonList(rule));配置熔断规则时最小请求数不要设得太小，否则偶尔几个慢请求就会把熔断器打开，造成误杀。同时熔断时长建议从 10 秒起步，太短的话下游还没恢复就再次放流量进去，熔断器会反复开关震荡。
四、规则持久化到 Nacos
Sentinel 控制台默认把规则保存在内存里，应用一重启规则就全部丢失，控制台自身重启同样如此，这种模式显然没法用在生产环境。官方推荐的方案是把规则推送到 Nacos 等配置中心，应用监听配置变化动态更新规则，控制台只负责展示和编辑。
应用侧需要引入 sentinel-datasource-nacos 依赖：
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
<version>1.8.6</version>
</dependency>
spring:
cloud:
sentinel:
datasource:
flow-rules:
nacos:
server-addr: localhost:8848
namespace: sentinel
groupId: SENTINEL_GROUP
dataId: order-service-flow-rules
rule-type: flow
degrade-rules:
nacos:
server-addr: localhost:8848
namespace: sentinel
groupId: SENTINEL_GROUP
dataId: order-service-degrade-rules
rule-type: degrade在 Nacos 中创建对应 dataId 的配置，内容是规则数组的 JSON。修改配置后 Sentinel 客户端会通过监听器实时感知并重新加载规则，实现了真正意义上的动态配置。需要注意的是默认的规则实体与控制台页面使用的实体字段略有差异，如果要实现控制台与 Nacos 双向同步，需要对控制台源码做少量改造，把推送逻辑从写内存改为写 Nacos，这部分在官方的 sentinel-dashboard 仓库中有说明。
五、上线前的几个注意事项
第一，规则要灰度验证。限流阈值不能拍脑袋定，先通过压测得到单机的安全容量，再设置在其百分之七十左右，上线后观察拒绝日志逐步调整。第二，降级逻辑要有业务含义，返回“系统繁忙”只是兜底，能走静态数据、默认值或异步补偿的降级方案远比直接报错好。第三，注意链路限流问题，Sentinel 默认不加链路信息标记，不同入口调用同一资源时如果需要按来源限流，要开启 web-context-unify: false 并在规则中配置来源。第四，监控数据只保留最近几分钟，长期趋势分析还是要对接 Prometheus 加 Grafana 的方案，把 Sentinel 的埋点指标导出。
把限流当作架构的保险丝而不是万能药，合理的容量规划、缓存策略和服务隔离依然是根本。Sentinel 的价值在于当意外发生时，你能通过几条动态规则在几秒内控制住局面，而不是连夜改代码发版。
Spring BootSentinel限流熔断修改时间：2026-09-16 18:04:51