[toc]
| 单词 | 词性 | 音标 | 含义 |
|---|---|---|---|
| flow control | n. | /fləʊ kənˈtrəʊl/ | 流量控制（限流：控制单位时间内的请求量） |
| circuit breaking | n. | /ˈsɜːkɪt ˈbreɪkɪŋ/ | 熔断（连续失败达到阈值，直接快速失败一段时间，保护下游） |
| degrade | v. | /dɪˈɡreɪd/ | 降级（服务异常时返回兜底结果，不拖垮调用方） |
| hotspot | n. | /ˈhɒtspɒt/ | 热点（某个 key/参数被高频访问，需单独保护） |
| rule | n. | /ruːl/ | 规则（限流/熔断/降级的具体阈值配置） |
Lecture09-SpringCloud-Sentinel流量防护（概念）
目标：定性理解 Sentinel 能解决什么问题——限流、熔断、降级、热点防护，以及每种规则"什么时候用、大概怎么配"。
1、为什么要"流量防护"
没有防护的微服务，可能被这些问题打垮：
| 场景 | 后果 |
|---|---|
| 突发流量（秒杀、热点新闻） | 瞬间请求量超系统上限，服务直接崩溃 |
| 下游服务变慢/挂掉 | 调用方一直等待，线程被耗尽，故障连锁扩散 |
| 某个 key 被恶意高频访问 | 单点压力过大，拖累全局 |
Sentinel 是阿里巴巴开源的流量防护组件，职责就是"在请求还没打垮系统之前，拦下来"。
一句话：Sentinel = 微服务的"防洪闸 + 保险丝"。
2、三大核心能力
1、流量控制（限流）Flow Rule
控制"单位时间内最多放行多少个请求"，超过就拒绝。
触发限流 → 拒绝超出部分（返回 限流 提示）
| 维度 | 说明 |
|---|---|
| 按 QPS | 每秒请求数达到阈值即限流（最常见） |
| 按并发线程数 | 同时处理的线程数达到阈值即限流（保护线程不被耗尽） |
| 限流方式 | 直接拒绝 / 预热（Warm Up，缓慢放量）/ 排队等待（匀速通过） |
QPS：Query Per Second每秒请求数量
2、熔断 Circuit Breaking
某个服务连续失败达到阈值，Sentinel 直接"熔断"——短时间内不再调用它，直接快速失败，给下游喘息时间。
正常 → 连续失败超阈值 → 熔断（拒绝调用） → 熔断时间到 → 尝试恢复
| 熔断策略 | 触发条件 |
|---|---|
| 慢调用比例 | 慢调用（如 >1000ms）占比超阈值 |
| 异常比例 | 异常占比超阈值 |
| 异常数 | 异常次数超阈值 |
3、降级 Degrade
下游不可用时，返回兜底结果（fallback），而不是让调用方一直等或报错。
// 伪代码示意：降级 = 返回一个默认/兜底结果
Result r = tryCall(orderService);
if (r.failed) {
return Result.bypass("服务繁忙，请稍后再试"); // 兜底
}
熔断 + 降级常配合使用：熔断是"要不要停"，降级是"停了之后返回什么"。
3、热点参数防护 Hotspot
针对某个高频参数/Key做单独限流（区别于全局 QPS 限流）：
例：秒杀活动，商品1001 被疯狂访问
→ 对参数 productId=1001 单独限流，其它商品不受影响
| 场景 | 做法 |
|---|---|
| 热点商品 | 对商品 id 参数单独限流 |
| 热点用户 | 对 userId 参数单独限流 |
| 防刷 | 对某个 IP 维度限流 |
4、规则怎么配(了解)
Sentinel 规则可配置在控制台（可视化）或代码注解上。业务开发最常用的是注解方式：
// 伪代码示意：给方法加限流/降级规则
@SentinelResource(
value = "createOrder", // 资源名
blockHandler = "createOrderBlock", // 被限流/熔断时执行的方法
fallback = "createOrderFallback") // 业务异常时执行的方法
public Order createOrder(Long userId) {
// 正常业务逻辑
}
// 伪代码：兜底方法签名需与资源方法对应
public Order createOrderBlock(Long userId, BlockException e) {
return Order.empty("系统繁忙，已被限流");
}
public Order createOrderFallback(Long userId) {
return Order.empty("业务异常，已降级");
}
关键点（理解即可）：@SentinelResource 把"一个业务方法"变成"一个受保护资源"，并指定"被拦时"和"出错时"分别执行什么兜底逻辑。规则阈值（QPS、失败比例）在控制台配置，生产上可以把限流、熔断规则持久化到 Nacos。
补充：Sentinel 也适配了 OpenFeign。 项目里引入 spring-cloud-starter-alibaba-sentinel 并打开 feign.sentinel.enabled=true，Sentinel 就能接管 L05 讲的服务降级——@FeignClient(fallback = ...) 的写法一个字都不用改，变的只是"谁来触发降级"：从 Resilience4j 的配置文件规则，换成 Sentinel 控制台的动态规则。
两种降级区分：
- @SentinelResource 是针对『提供端』返回兜底值【锦上添花】
- @FeignClient(fallback = ...) 是针对『消费端』返回兜底值【生存命脉】
由于『提供端降级预案』对于某些情况无法涵盖（例如：网络完全在物理层面断开），所以『消费端』必须提前写好自己的兜底方案，所以消费端的兜底方案不能省略——从消费端的立场来看：我们不能把自我保护的责任寄希望在别人身上
5、常见问题
| 问题 | 理解 |
|---|---|
| 限流和熔断有什么区别？ | 限流看"来多少"，熔断看"下游还行不行"。 |
| 熔断和降级有什么关系？ | 熔断决定"停不停"，降级决定"停了返回什么"，常配套。 |
| 热点限流和普通限流？ | 普通限流对整个接口限流，热点针对某个参数值限流。 |
| 在哪配置规则？ | 控制台可视化配置，或注解 + 控制台；生产可持久化到 Nacos。 |
| Resilience4j 和 Sentinel 用哪个？ | 纯 Spring Cloud 用 Resilience4j；SCA 体系生产用 Sentinel（规则可动态下发、改阈值不用重启）。两者对 Feign 的 fallback 写法一致，切换只换依赖和开关。 |
6、课堂练习（概念问答）
- 用一句话分别说出：限流、熔断、降级各自解决什么问题。
- 秒杀场景，为什么"对某个商品 id 限流"优于"对整个接口限流"？
- 判断：某接口 QPS 上限 1000，这属于哪种能力？（限流）
- 思考：Sentinel 和我们在 L06 学的 LoadBalancer 是同一件事吗？（不是，前者管流量防护，后者管选实例）
7、本讲小结
- Sentinel 提供 限流、熔断、降级、热点防护 四种能力，守护系统不被突发流量和故障拖垮。
- 限流看"来多少"，熔断看"下游还行不行"，降级决定"不行时返回什么"。
- 业务接入思路：用
@SentinelResource把方法变成受保护资源，配好兜底方法，阈值在控制台/规则中设置。 - 本课程只做概念介绍；生产实操可参考官方文档接入。
8、本节验证
- 理解为什么要流量防护（突发流量、下游故障、热点）✅
- 区分限流 / 熔断 / 降级三大核心能力 ✅
- 理解热点参数防护与按 QPS / 并发线程数限流 ✅
- 了解规则配置维度（本讲只概念，不实操）✅
- 知道 Sentinel 也能接管 Feign 降级，与 L05 的 fallback 写法完全一致 ✅