Sentinel各种规则的效果和适用场景

Sentinel 的各种规则是其实现流量控制、服务稳定的核心手段。下面详细解释每种规则的效果、适用场景以及它们之间的协同关系。

核心规则概览

Sentinel 主要提供以下五种规则：

  1. 流量控制规则 (FlowRule)：控制流量速度，防止服务被瞬间流量冲垮。
  2. 熔断降级规则 (DegradeRule)：在调用链路中某个资源不稳定时（如响应慢或异常多），进行熔断，避免级联故障。
  3. 系统保护规则 (SystemRule)：从整体系统维度（如 CPU、负载、并发线程数）控制入口流量，保证系统整体稳定性。
  4. 热点参数规则 (ParamFlowRule)：对频繁访问的“热点”参数进行限流，适用于秒杀等场景。
  5. 授权规则 (AuthorityRule)：根据调用来源（如 IP、服务名）实现黑白名单控制。

1. 流量控制规则 (FlowRule)

目标：控制流量通过的速度和数量，让其匀速、缓慢地通过，避免突发流量导致系统崩溃。

核心效果：

流控效果工作机制可视化比喻适用场景
快速失败直接拒绝超出阈值的请求，立即抛出 BlockException。红绿灯：红灯亮起，所有车必须停下。对实时性要求高，希望立即知道结果的场景，如API网关、核心下单接口。
Warm Up (预热)让流量从冷启动阈值逐渐缓慢增加到设定的QPS阈值。冬季热车：冷启动时不能马上高转速，需要慢慢预热发动机。系统冷启动或长时间低负载后突然迎来大流量，防止系统被“冷启动”压垮。常见于数据库连接池、JVM JIT编译等需要预热的过程。
排队等待让所有请求以恒定速度（间隔 = 1s / QPS阈值）依次通过，超出的请求在队列中等待；若等待时间超过超时时间则被拒绝。摩天轮：每个轿厢以固定速度上下客，游客排队等待，等不及的可以离开。处理突发流量，削峰填谷，让请求平滑通过。适用于消息处理、低频批处理等允许一定延迟的场景。注意：超时时间设置要合理。

配置示例：

  • 资源：/order/create
  • 阈值类型：QPS
  • 单机阈值：100
  • 流控效果：Warm Up（预热时长：10秒）
  • 效果：系统启动后，前10秒内阈值会从 100 / 3 ≈ 33 慢慢升高到100。10秒后稳定在100 QPS。

2. 熔断降级规则 (DegradeRule)

目标：当调用某个资源（通常是下游服务）出现不稳定时（如响应时间变长、异常比例升高），在一段时间内停止调用该资源，避免局部故障导致整个系统雪崩。之后通过半开状态试探是否恢复。

核心策略：

熔断策略触发条件效果
慢调用比例在统计时长内，请求数 > 最小请求数 且 慢调用（RT > 最大RT）的比例 > 阈值。熔断该资源，进入熔断状态（所有请求快速失败）。经过熔断时长后，进入半开状态，放一个试探请求，成功则闭合断路器，失败则继续熔断。
异常比例在统计时长内，请求数 > 最小请求数 且 异常请求的比例 > 阈值。同上
异常数在统计时长内，异常数量 > 阈值。同上

配置示例：

  • 资源：/inventory/deduct (调用库存服务)
  • 熔断策略：慢调用比例
  • 最大RT：200ms (超过200ms算慢调用)
  • 比例阈值：0.5 (50%)
  • 熔断时长：10s
  • 最小请求数：10
  • 效果：在1秒统计窗口内，如果对库存服务的调用超过10次，且其中超过50%的调用响应时间大于200ms，则熔断器打开。接下来10秒内所有调用库存服务的请求会立即失败。10秒后进入半开状态，允许一个试探请求通过，如果成功则关闭熔断器，恢复调用。

3. 系统保护规则 (SystemRule)

目标：从整个应用的维度（而不是单个资源）监控指标，当系统指标（如CPU使用率）达到阈值时，果断限制所有入口流量，保证系统还能“活着”，有基本的能力处理请求。

核心指标：

指标效果
LOAD当系统负载（Unix-like系统）超过阈值，且并发线程数超过系统容量时触发保护。（Linux下不准确，较少用）
RT所有入口请求的平均响应时间达到阈值时触发。
线程数当前全局并发处理线程数达到阈值时触发。
入口 QPS所有入口资源的QPS总和达到阈值时触发。
CPU 使用率最常用、最有效。当系统CPU使用率超过阈值（如80%）时触发保护。

效果：只要触发其中任何一条规则，所有进入本应用的请求都会被限流，直到指标恢复正常。

4. 热点参数规则 (ParamFlowRule)

目标：对包含参数的调用进行限流，且可以针对参数的具体值（热点值）单独设置限流阈值。适用于防护热点数据（如热门商品ID、用户ID）被刷或被打爆。

效果：

  • 为资源（如 getProductInfo(productId)）配置一个通用的QPS阈值。
  • 可以为其某个参数（如第一个参数 productId）的特殊值（如 12345 这个秒杀商品）配置一个远低于通用阈值的QPS限制。
  • 当参数值为 12345 的请求过来时，Sentinel会检查针对这个特定值的QPS是否超限，而不是检查通用阈值。

5. 授权规则 (AuthorityRule)

目标：根据调用方（来源）的身份来决定是否有权限访问资源。

效果：

  • 白名单：只有在名单内的调用方才允许访问。
  • 黑名单：在名单内的调用方会被拒绝访问。

规则协同工作流程

这些规则并不是孤立的，而是一个协同工作的防御体系。一个请求进入系统后的完整防护流程可以理解为：

flowchart TD
A[请求进入] --> B[系统规则检查]
B -- CPU/负载/并发超阈值? --> C[全部拒绝]
B -- 系统正常 --> D[授权规则检查]
D -- 在黑名单? --> C
D -- 通过 --> E[热点参数规则检查]
E -- 是热点参数且超限? --> F[拒绝]
E -- 通过 --> G[流量控制规则检查]
G -- QPS超限? --> F[拒绝]
G -- 通过 --> H[执行业务逻辑]
H -- 调用下游服务] --> I[熔断规则检查]
I -- 下游已熔断? --> J[快速失败<br>（降级处理）]
I -- 下游正常 --> K[正常调用]
K -- 响应慢或异常多? --> L[更新熔断器状态]

这个流程图清晰地展示了Sentinel的多层防护机制：系统规则和授权规则作为最外层的屏障，首先拦截不合法和会对系统造成致命打击的流量。随后热点规则和流控规则对具体请求进行精细化控制。最后，在调用依赖资源时，熔断规则保护本地服务不被不稳定的下游拖垮。