Sentinel 入门详解：一篇搞懂限流、熔断、降级与系统保护
前言
在开发一个普通后台系统时，我们通常只需要考虑：
请求进来
↓
Controller
↓
Service
↓
Mapper
↓
Database
只要代码逻辑正确，功能基本就能正常运行。
但当系统流量越来越大以后，问题就开始出现了。
例如：
平时：
100 QPS
↓
系统正常
突然有一天：
10000 QPS
↓
接口响应变慢
↓
Tomcat 线程堆积
↓
数据库连接池耗尽
↓
MySQL CPU 飙升
↓
整个系统不可用
又或者，在微服务系统中：
Order Service
↓
Payment Service
Payment Service 突然变慢。
Order Service 每次调用都要等待：
3 秒
5 秒
10 秒
大量请求全部卡在 Order Service。
最终：
Payment 挂了
↓
Order 被拖死
↓
Gateway 被拖死
↓
整个系统雪崩
这时候我们就需要一种技术来保护系统：
流量太大时限制请求，下游服务异常时快速失败，非核心功能必要时降级，从而避免局部问题演变成整个系统故障。
这就是 Sentinel 主要解决的问题。
一、什么是 Sentinel？
Sentinel 是阿里巴巴开源的一套：
面向分布式系统的流量治理和容错组件。
它主要提供：
限流
熔断
降级
热点参数限流
系统保护
实时监控
可以简单理解成：
Sentinel 是系统中的“限流阀 + 保险丝”。
流量太大：
限流
下游服务大量超时：
熔断
某些非核心功能需要暂时关闭：
降级
系统 CPU、线程等资源已经非常危险：
系统保护
所以 Sentinel 的核心目标并不是：
让系统跑得更快。
而是：
在异常流量和故障场景下，让系统不要轻易被拖垮。
二、Sentinel 只能用于微服务吗？
答案是：
不是。
Sentinel 可以用于：
Spring Boot 单体项目
Spring Cloud 微服务
Dubbo
Spring Cloud Gateway
普通 Java 方法
因为 Sentinel 真正保护的对象不是：
微服务
而是：
Resource
资源
这个资源可以是：
一个接口
一个方法
一次远程调用
一个 Gateway 路由
一个业务功能
例如一个普通单体项目：
Spring Boot
↓
/api/order/create
↓
OrderService
↓
MySQL
如果 /api/order/create 突然来了大量请求：
10000 QPS
完全可以使用 Sentinel：
最大允许：
500 QPS
于是：
10000 请求
↓
Sentinel
↓
500 放行
9500 拒绝
所以 Sentinel 并不是微服务专属组件。
三、为什么需要限流？
先看一个现实问题。
假设订单接口：
POST /api/order
系统正常承载能力：
500 QPS
结果秒杀活动开始：
50000 QPS
如果全部放进去：
50000 请求
↓
Tomcat
↓
Service
↓
MySQL
可能发生：
线程池耗尽
↓
数据库连接池耗尽
↓
SQL 大量排队
↓
CPU 100%
↓
GC 增加
↓
接口超时
↓
整个系统挂掉
所以现实系统不能遵循：
来多少请求就处理多少请求。
因为计算机资源永远是有限的。
正确思想是：
系统能处理多少，就只放多少进来。
例如：
最大 500 QPS
那么：
请求 1~500
↓
正常执行
超过部分
↓
限流
返回：
系统繁忙，请稍后重试。
这就是：
Flow Control
流量控制，也就是限流。
四、限流的核心思想
假设水管最多只能承受：
每秒 100 升
结果突然灌入：
每秒 10000 升
如果没有阀门：
水管爆掉
Sentinel 就像：
流量阀门
只允许：
100
进入。
剩余：
拒绝
排队
或者使用其他策略处理
因此：
宁愿拒绝一部分请求，也不能让所有请求一起失败。
这是限流最核心的思想。
五、什么是 QPS？
学习 Sentinel 会经常看到：
QPS
全称：
Queries Per Second
简单理解：
每秒请求数量。
例如：
1 秒钟收到 100 个请求
那么：
QPS = 100
如果给接口配置：
QPS = 50
大致可以理解为：
每秒允许约 50 个请求通过
超过部分触发流控规则。
六、Sentinel 中什么叫 Resource？
这是理解 Sentinel 非常重要的概念。
Sentinel 并不是简单针对：
整个应用
进行保护。
它主要围绕：
Resource
进行统计和保护。
比如：
createOrder
可以是一个资源。
queryUser
也是一个资源。
/api/order/list
也可以成为资源。
例如：
@SentinelResource("createOrder")
public Long createOrder(CreateOrderRequest request) {
return orderService.createOrder(request);
}
这里：
createOrder
就是一个 Sentinel Resource。
Sentinel 可以统计：
QPS
平均响应时间
异常数量
当前线程数量
通过请求数量
被限流请求数量
然后根据规则决定：
Allow
或者：
Block
七、Sentinel 的基本工作原理
可以简单理解为：
请求
↓
Sentinel Resource
↓
统计当前流量
↓
检查规则
↓
┌─────────────┐
│ 是否允许？ │
└──────┬──────┘
│
┌───┴───┐
↓ ↓
允许 不允许
↓ ↓
业务代码 Block
所以 Sentinel 实际做的事情可以概括为：
统计
+
规则判断
+
流量控制
八、Sentinel 的第二个核心能力：熔断
限流解决的是：
请求太多。
熔断解决的是：
下游已经不正常了。
例如：
Order Service
↓
Payment Service
正常情况下：
Payment
响应时间：
50ms
突然 Payment Service 出问题：
5000ms
甚至：
Timeout
如果 Order Service 继续疯狂请求：
请求1
↓
等待5秒
请求2
↓
等待5秒
请求3
↓
等待5秒
大量线程全部等待 Payment。
最终：
Payment Service
挂掉
↓
Order Service
线程耗尽
↓
Order Service
也挂掉
然后调用 Order 的系统也可能受到影响。
这就是：
服务雪崩
九、什么是熔断？
熔断的思想非常像家里的：
保险丝。
如果电流异常：
保险丝断开
避免整个电路烧坏。
Sentinel 发现某个资源：
异常比例非常高
或者：
慢调用比例非常高
就可以暂时：
Circuit Open
也就是：
打开熔断器。
后续请求不再真正调用故障服务。
例如：
Order
↓
Sentinel
↓
发现 Payment 已经被熔断
↓
直接快速失败
而不是：
Order
↓
Payment
↓
等待5秒
↓
Timeout
这就是：
Fail Fast，快速失败。
十、熔断器的三个经典状态
熔断器通常可以理解为三个状态：
Closed
Open
Half-Open
1. Closed
正常状态。
Order
↓
Payment
正常调用。
2. Open
Sentinel 发现：
大量异常
或者：
大量慢调用
于是：
Circuit Breaker Open
后续请求：
Order
↓
Sentinel
↓
快速失败
不继续冲击 Payment。
3. Half-Open
熔断一段时间以后，Sentinel 需要判断：
下游是不是已经恢复了？
于是：
放少量请求过去测试
如果恢复：
Half-Open
↓
Closed
如果依然异常：
Half-Open
↓
Open
整个过程：
Closed
↓
异常达到阈值
↓
Open
↓
等待恢复时间
↓
Half-Open
↓
成功 → Closed
失败 → Open
十一、什么叫降级？
熔断和降级经常一起出现。
假设一个电商首页需要：
用户信息
商品
库存
推荐
广告
积分
优惠券
其中：
商品
订单
支付
库存
属于核心业务。
而：
猜你喜欢
推荐商品
广告
积分展示
相对没有那么核心。
双十一系统压力特别大的时候，我们可能决定：
推荐系统暂时关闭
用户访问首页：
推荐商品
不再执行复杂算法。
直接：
{
"recommendations": []
}
这样可以把资源优先留给：
订单
支付
库存
这就是：
服务降级
简单理解：
系统资源不足时，优先保核心功能，暂时牺牲非核心功能。
十二、熔断和降级有什么区别？
很多初学者会混淆。
可以这样理解。
熔断
关注：
下游不健康
例如：
支付服务大量超时
于是：
先不调用它
降级
关注：
当前功能可以暂时降低服务质量
例如：
推荐服务不可用
那么：
返回空推荐
所以可以记：
熔断负责“断掉有问题的调用”。
降级负责“断掉以后给用户什么结果”。
两者在实际项目中经常配合使用。
十三、什么是 blockHandler？
Sentinel 中经常会看到：
blockHandler
它主要负责：
处理 Sentinel 规则触发以后产生的 BlockException。
例如：
@SentinelResource(
value = "queryOrder",
blockHandler = "queryOrderBlock"
)
public OrderVO queryOrder(Long id) {
return orderService.queryOrder(id);
}
如果触发：
限流
熔断规则
热点参数规则
可能进入：
public OrderVO queryOrderBlock(
Long id,
BlockException ex) {
OrderVO vo = new OrderVO();
vo.setMessage("系统繁忙，请稍后重试");
return vo;
}
流程：
queryOrder
↓
Sentinel Rule
↓
触发 Block
↓
queryOrderBlock
所以：
blockHandler
可以简单记成：
Sentinel 自己把请求挡下来以后，执行什么逻辑。
十四、什么是 fallback？
另外还有一个：
fallback
它更多用于：
业务代码执行过程中产生异常时提供兜底逻辑。
例如：
@SentinelResource(
value = "queryUser",
fallback = "queryUserFallback"
)
public UserVO queryUser(Long userId) {
return remoteUserService.queryUser(userId);
}
如果远程调用发生异常：
public UserVO queryUserFallback(
Long userId,
Throwable throwable) {
UserVO user = new UserVO();
user.setId(userId);
user.setName("默认用户");
return user;
}
可以粗略理解：
Sentinel 规则阻断
↓
blockHandler
业务方法自身异常
↓
fallback
这是两个很重要的概念。
十五、热点参数限流是什么？
这是 Sentinel 一个非常实用的功能。
假设有接口：
GET /api/product?id=100
正常情况下，每个商品请求比较平均：
id=1
100 QPS
id=2
80 QPS
id=3
50 QPS
突然某个商品变成爆款：
id=8888
变成：
50000 QPS
如果直接限制整个：
/api/product
会导致其他商品也无法访问。
Sentinel 可以根据：
参数
进行流控。
比如：
id=8888
最大：
500 QPS
但是：
id=9999
仍然可以正常访问。
这就是：
Hotspot Parameter Flow Control
热点参数限流。
十六、热点参数限流适合什么业务？
例如：
秒杀商品 ID
热门商品 ID
明星用户 ID
热门文章 ID
热门视频 ID
热门商户 ID
有时候真正把系统打爆的不是：
整个接口
而是：
某一个特别热门的参数值
热点参数限流就是专门解决这类问题的。
十七、什么是系统保护？
前面限流一般保护：
某一个 Resource
但是 Sentinel 还可以从：
整个应用
的角度保护系统。
例如系统已经出现：
CPU 很高
Load 很高
线程很多
入口 QPS 很高
这时候继续接受大量请求可能会：
拖垮整个 JVM
于是 Sentinel 可以根据系统整体运行状态采取保护措施。
可以理解成：
单个接口限流
↓
保护一个接口
系统保护
↓
保护整个应用
十八、Sentinel Dashboard 是什么？
Sentinel 提供：
Sentinel Dashboard
也就是：
Sentinel 控制台。
通过 Dashboard 可以查看：
实时 QPS
通过数量
拒绝数量
资源信息
流量规则
熔断规则
热点规则
系统规则
例如：
order-service
/api/order/create
QPS = 200
/api/order/list
QPS = 500
/api/order/detail
QPS = 100
然后配置：
/api/order/create
最大 QPS：
100
超过以后：
Block
这对于学习 Sentinel 非常直观。
十九、Sentinel 和 Nacos 为什么经常一起使用？
在很多 Spring Cloud Alibaba 项目里会看到：
Sentinel
+
Nacos
这是因为：
Sentinel
主要负责：
执行流控规则。
而：
Nacos
可以负责：
存储和下发配置。
例如：
order-service
需要一条规则：
/api/order/create
QPS = 100
这个规则可以存储在：
Nacos
然后 Sentinel Client 获取配置。
结构：
Nacos
|
Sentinel Rules
/ \
↓ ↓
Order Service User Service
所以：
Nacos
→ 保存规则
Sentinel
→ 执行规则
二十、为什么需要规则持久化？
如果规则只存在：
应用内存
那么：
应用重启
可能导致规则丢失。
生产环境显然不能：
每次服务重启
↓
手动重新配置所有规则
所以通常需要：
配置中心
持久化 Sentinel Rule。
例如：
Nacos
就是很常见的解决方案。
二十一、Sentinel 和 Eureka / Nacos 注册中心有什么区别？
这几个东西非常容易混。
可以直接记：
Eureka / Nacos 注册中心
↓
解决“服务在哪里”
Sentinel：
解决“服务现在还能不能安全调用”
例如：
Order Service
↓
Nacos / Eureka
↓
找到 Payment Service
然后：
Order Service
↓
Sentinel
↓
判断：
Payment 是否已经熔断？
请求是否超限？
然后才决定：
是否调用
所以：
注册中心
解决：
找谁？
Sentinel：
能不能继续调？
二十二、Sentinel 和 Gateway 有什么关系？
Gateway：
负责请求入口
路由
认证
鉴权
过滤
Sentinel：
负责流量保护
所以二者可以配合：
Internet
↓
Gateway
↓
Sentinel
↓
Microservices
例如：
/api/order/**
最大：
1000 QPS
超过的请求直接在 Gateway 层处理。
这样可以减少后端：
Order Service
的压力。
二十三、Sentinel 和 WAF 有什么区别？
WAF 主要解决：
恶意攻击
例如：
SQL Injection
XSS
恶意扫描
异常 Bot
Sentinel 主要解决：
系统稳定性
例如：
正常用户突然太多
接口 QPS 太高
下游变慢
服务大量异常
比如：
SQL Injection
应该：
WAF 拦截
而：
双十一 100 万正常用户抢购
应该：
Sentinel 限流
可以记：
WAF
→ Security
Sentinel
→ Stability
二十四、Sentinel 和 Hystrix 有什么关系？
学习早期 Spring Cloud 的人，经常会看到：
Hystrix
它也有：
熔断
降级
隔离
等能力。
Sentinel 和它解决的问题存在一定重叠。
但是 Sentinel 不仅关注：
熔断
还非常强调：
流量控制
热点参数
系统保护
实时监控
因此在 Spring Cloud Alibaba 技术体系中，经常会看到：
Sentinel
负责服务流量治理。
二十五、单体项目如何使用 Sentinel？
假设一个普通 Spring Boot：
Spring Boot
|
├── UserController
├── OrderController
└── ReportController
其中报表接口：
/api/report/export
一次执行：
查询几十万数据
+
Excel 生成
+
大量 CPU
+
大量内存
如果同时：
100 个用户
点击导出。
可能：
100 个重任务
↓
CPU 打满
↓
Memory 增加
↓
GC
↓
整个后台卡死
可以使用 Sentinel：
最大并发：
3
那么：
前 3 个
↓
执行
第 4 个以后
↓
系统繁忙，请稍后再试
这也是 Sentinel 非常合理的使用场景。
二十六、单体中熔断有什么意义？
假设单体应用调用：
短信平台
支付宝
微信支付
物流平台
地图 API
OCR 服务
比如：
Spring Boot
↓
SMS Provider
短信供应商突然：
响应时间 10 秒
如果有：
500 个请求
同时发送短信：
500 个线程
↓
全部等第三方
↓
线程池耗尽
↓
整个 Spring Boot 卡死
Sentinel 可以在：
短信服务持续异常
以后触发熔断。
后续请求：
快速失败
避免大量线程继续等待。
所以：
即使不是微服务，只要存在第三方依赖，也有熔断价值。
二十七、什么时候应该使用 Sentinel？
Sentinel 特别适合下面这些场景：
| 场景 | 是否推荐 |
|---|---|
| 秒杀 | 非常推荐 |
| 抢优惠券 | 非常推荐 |
| 高并发下单 | 推荐 |
| 短信验证码 | 推荐 |
| 第三方 API | 推荐 |
| 支付接口 | 推荐 |
| 报表导出 | 推荐 |
| 热门内容 | 推荐 |
| 微服务远程调用 | 推荐 |
| 普通低并发 CRUD | 不一定需要 |
| 几个人使用的后台 | 通常没必要 |
所以不是：
用了微服务
↓
必须 Sentinel
也不是：
单体
↓
不能 Sentinel
真正应该判断：
有没有流量风险？
有没有慢调用？
有没有第三方依赖？
有没有热点？
有没有系统雪崩风险？
二十八、Sentinel 不能解决所有问题
Sentinel 很强，但不要把它理解成万能组件。
例如：
SQL 本身很慢
应该：
优化 SQL
而不是：
全部靠 Sentinel
数据库没有索引：
加索引 / 改查询
内存泄漏：
修代码
接口设计错误：
重新设计
Sentinel 做的是：
在异常情况下保护系统。
而不是：
掩盖系统本身存在的问题。
二十九、一个完整的微服务架构中 Sentinel 在哪里？
把常见组件串起来：
Internet
|
↓
WAF
|
↓
Gateway
|
Sentinel
|
┌────────────┼────────────┐
↓ ↓ ↓
User Order Payment
Service Service Service
↑ ↑ ↑
└────────────┼────────────┘
|
Nacos
这些组件分别负责：
WAF
→ Web 安全
Gateway
→ 请求入口、路由、鉴权
Sentinel
→ 限流、熔断、降级、系统保护
Nacos
→ 服务注册发现、配置管理
微服务
→ 真正业务
这样整个微服务体系就非常清楚了。
三十、一个真实下单流程
用户：
创建订单
请求首先：
Internet
↓
WAF
WAF 判断：
是不是攻击？
正常：
↓
Gateway
Gateway：
认证
鉴权
路由
然后：
↓
Sentinel
Sentinel 判断：
当前 QPS 是否过高？
如果：
当前 500 QPS
最大允许 1000 QPS
那么：
Allow
进入：
Order Service
Order Service 需要：
Inventory Service
通过：
Nacos
获得库存服务地址。
然后调用库存。
如果库存服务最近：
大量超时
Sentinel：
触发熔断
于是：
不再疯狂调用库存
↓
快速失败
↓
返回业务兜底结果
这样：
库存服务故障
就不会轻易演变成：
订单服务故障
↓
Gateway 故障
↓
整个网站故障
这就是 Sentinel 真正的意义。
三十一、Sentinel 真正防的是什么？
Sentinel 最终防止的是：
雪崩效应
例如：
Database 变慢
↓
Product Service 变慢
↓
Order Service 等待
↓
Gateway 等待
↓
线程大量堆积
↓
整个系统崩
有 Sentinel：
Database / 下游变慢
↓
Product Service 异常
↓
Sentinel 检测异常
↓
熔断
↓
快速失败
↓
控制故障范围
所以 Sentinel 最重要的思想就是：
控制故障传播。
三十二、学习 Sentinel 最重要的几个关键词
刚开始不需要背几十个配置。
先记：
Resource
Flow Control
Circuit Breaker
Degrade
Hotspot
System Protection
BlockHandler
Fallback
对应：
Resource
→ 被保护的资源
Flow Control
→ 限流
Circuit Breaker
→ 熔断
Degrade
→ 降级
Hotspot
→ 热点参数保护
System Protection
→ 系统级保护
BlockHandler
→ Sentinel 规则触发后的处理
Fallback
→ 业务异常的兜底逻辑
把这些理解清楚，Sentinel 就已经真正入门了。
三十三、Sentinel 的核心思想总结
最终可以把 Sentinel 压缩成：
正常情况下：
Request
↓
Sentinel
↓
Business
流量过大：
Request
↓
Sentinel
↓
Limit
下游异常：
Request
↓
Sentinel
↓
Circuit Breaker
非核心业务：
Request
↓
Degrade
↓
Fallback
系统快撑不住：
CPU / Load / Threads
↓
Sentinel
↓
System Protect
三十四、面试怎么回答 Sentinel？
如果面试官问：
Sentinel 是什么？
可以回答：
Sentinel 是阿里巴巴开源的流量治理和容错组件，主要用于限流、熔断降级、热点参数流控和系统自适应保护。Sentinel 会围绕 Resource 统计 QPS、异常、响应时间和线程等指标，并根据配置的规则决定请求是否允许通过。当系统流量过高或者下游服务大量超时、异常时，可以通过限流或者熔断快速失败，避免局部故障扩散形成系统雪崩。
如果只用一句大白话：
Sentinel 就是系统里的限流阀和保险丝：流量太大就限制，服务坏了就熔断，非核心功能必要时降级，核心目标就是不要让整个系统被拖死。
三十五、最后总结
Sentinel 主要解决：
流量过大
服务变慢
下游故障
热点流量
系统资源不足
故障传播
核心能力：
Sentinel
│
├── 限流
│
├── 熔断
│
├── 降级
│
├── 热点参数
│
└── 系统保护
学习 Sentinel 时最重要的不是记 API。
而是理解下面这一条逻辑：
系统资源有限
↓
流量不可能无限进入
↓
所以需要限流
下游服务可能故障
↓
不能无限等待
↓
所以需要熔断
非核心功能可以牺牲
↓
保护核心业务
↓
所以需要降级
局部故障不能无限传播
↓
所以需要 Sentinel
Sentinel 最终解决的其实就是一句话：
当系统面对异常流量和局部故障时，通过限制、隔离和快速失败，将问题控制在一个可接受范围内，让整个系统继续活着。
对于真正的工程系统来说：
系统稳定不是“永远不会出现故障”，而是“出现故障以后，不会轻易全盘崩掉”。
而这，正是 Sentinel 存在的价值。