一、Sentinel 是什么？

1.1 核心定位

Sentinel（哨兵）是阿里巴巴开源的分布式系统流量治理组件，被誉为"分布式系统的流量防卫兵"。它以流量为切入点，从多个维度保障微服务架构的稳定性：

• 流量控制：防止系统被突发流量击垮
• 熔断降级：快速失败，避免级联故障
• 系统保护：全局兜底，防止雪崩
• 热点限流：精准控制热点参数

1.2 为什么需要 Sentinel？

想象这样一个场景：

双11秒杀活动开始，5万 QPS 的流量瞬间涌入，而平时系统的承载能力只有 500 QPS。5分钟后，超过 300 万笔交易失败，整个电商平台瘫痪。

这背后发生的就是著名的雪崩效应：一个服务被压垮后，故障沿着调用链路传播，最终导致整个系统崩溃。

传统解决方案的痛点：

方案	缺点
加机器扩容	反应慢，成本高
用缓存	需要提前预热
消息队列削峰	复杂度高，实时性差

Sentinel 的优势：

• 轻量级：核心包 < 200KB，性能损耗可忽略
• 实战验证：承载阿里巴巴近 10 年双十一大促流量
• 开箱即用：无缝集成 Spring Cloud、Dubbo 等主流框架
• 动态配置：支持控制台实时调整规则，无需重启服务

---

二、核心概念速览

2.1 资源（Resource）

资源是 Sentinel 保护的基本单元，可以是：

• 一个 API 接口
• 一个方法
• 一段代码

定义资源的方式：

// 方式1：注解方式（推荐）
@SentinelResource(value = "createOrder", blockHandler = "handleBlock")
public Result createOrder(OrderRequest request) {
    // 业务逻辑
}

// 方式2：代码方式（侵入性强）
public void someMethod() {
    try (Entry entry = SphU.entry("someResource")) {
        // 业务逻辑
    } catch (BlockException e) {
        // 限流降级处理
    }
}

2.2 规则（Rule）

规则是对资源的控制策略，包括：

• 流量控制规则：限制 QPS 或并发线程数
• 熔断降级规则：异常比例、异常数、慢调用比例
• 系统保护规则：CPU、RT、线程数等系统级指标
• 热点参数规则：对热点参数的精准限流

2.3 工作原理

Sentinel 采用责任链模式处理请求：

请求 → NodeSelectorSlot → ClusterBuilderSlot → StatisticSlot → FlowSlot → DegradeSlot → SystemSlot → 执行业务逻辑

每个 Slot 负责特定功能：

• 统计指标：实时统计 QPS、RT、异常数
• 规则检查：检查是否触发限流/熔断规则
• 结果处理：通过或执行降级逻辑

---

三、流量控制实战

3.1 阈值类型选择

Sentinel 支持两种阈值类型：

类型	适用场景	选择建议
QPS（每秒查询率）	接口调用频繁、响应较快的场景	推荐，适合大多数 API
并发线程数	接口处理耗时较长、依赖慢操作	用于耗资源的操作

如何选择：

// 场景1：快速响应的查询接口 → 选择 QPS
@GetMapping("/api/user/query")
@SentinelResource(value = "queryUser", blockHandler = "queryBlock")
public Result queryUser(@RequestParam Long userId) {
    // 响应快，用 QPS 限流
}

// 场景2：耗时较长的文件处理 → 选择并发线程数
@PostMapping("/api/file/process")
@SentinelResource(value = "processFile", blockHandler = "fileBlock")
public Result processFile(@RequestBody FileRequest request) {
    // 响应慢，限制并发线程数，避免线程池耗尽
}

3.2 流控模式配置

Sentinel 提供三种流控模式：

1. 直接模式（最常用）

直接对当前资源进行限流。

应用场景：保护单个接口本身

资源：/api/order/create
阈值类型：QPS
阈值：100
流控模式：直接
流控效果：快速失败

2. 关联模式

当关联的资源达到阈值时，对当前资源进行限流。

应用场景：保护核心业务

资源：/api/order/query（当前资源）
关联资源：/api/order/create（核心资源）
阈值：500

效果：当订单创建接口达到 500 QPS 时，自动限制订单查询接口，保护核心的创建流程。

3. 链路模式

只记录指定链路上的流量，对其他链路不做统计。

应用场景：微服务调用链路中的精细化限流

资源：userService
入口资源：orderService
阈值：100

效果：只限制从订单服务调用用户服务的流量，其他来源不受影响。

3.3 流控效果配置

Sentinel 提供四种流控效果：

1. 快速失败（默认）

超出阈值的请求直接被拒绝。

适用场景：核心接口、实时性要求高的接口

流控效果：快速失败

2. Warm Up（预热）

流量缓慢增加，在预热时间内逐渐增加到阈值上限。

适用场景：秒杀、促销等流量突增场景

阈值：1000
流控效果：Warm Up
预热时长：10秒

效果：前 10 秒，流量限制从 200 逐步增加到 1000，避免冷启动被击垮。

3. 匀速排队

严格控制请求通过的时间间隔，使流量更加平滑。

适用场景：非实时场景，如数据统计

阈值：2（每秒 2 个请求）
流控效果：匀速排队
最大等待时间：500ms

效果：每 500ms 允许通过一个请求，超出等待时间的请求被拒绝。

4. Warm Up + 匀速排队

结合预热和匀速排队的优点。

适用场景：需要预热且要求流量平滑的场景

3.4 实战配置示例

集成依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<!-- 动态规则数据源 -->
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

配置文件

spring:
  application:
    name: sentinel-demo
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080  # 控制台地址
        port: 8719                 # 与控制台通信端口
      eager: true                  # 立即初始化
      datasource:
        ds1:
          nacos:
            server-addr: localhost:8848
            dataId: sentinel-rule
            groupId: DEFAULT_GROUP
            rule-type: flow

Nacos 规则配置

[
  {
    "resource": "/api/order/create",
    "limitApp": "default",
    "grade": 1,
    "count": 100,
    "strategy": 0,
    "controlBehavior": 0,
    "clusterMode": false
  }
]

---

四、熔断降级实战

4.1 熔断策略选择

Sentinel 支持三种熔断策略：

1. 慢调用比例

当响应时间超过阈值的请求比例超过设定值时触发熔断。

适用场景：依赖服务响应变慢

熔断策略：慢调用比例
最大 RT：300ms（超过 300ms 视为慢调用）
比例阈值：0.6（60%）
最小请求数：20
熔断时长：5秒

效果：如果最近 1 秒内请求数 ≥ 20，且慢调用比例 ≥ 60%，触发熔断。

2. 异常比例

当异常请求占比超过设定值时触发熔断。

适用场景：依赖服务异常率高

熔断策略：异常比例
比例阈值：0.5（50%）
最小请求数：10
熔断时长：10秒

3. 异常数

当异常数量超过设定值时触发熔断。

适用场景：对异常数量敏感的场景

熔断策略：异常数
异常数阈值：5
最小请求数：10
熔断时长：10秒

4.2 熔断状态机

Sentinel 的熔断器有三个状态：

关闭 → 开启 → 半开 → 关闭

• 关闭：正常状态，请求正常通过
• 开启：熔断状态，拒绝所有请求
• 半开：探测状态，尝试放行一个请求，根据结果决定恢复或继续熔断

4.3 实战配置示例

@SentinelResource(
    value = "getUserInfo",
    fallback = "getUserInfoFallback",    // 业务异常降级
    blockHandler = "getUserInfoBlock"    // 限流熔断降级
)
public Result getUserInfo(Long userId) {
    // 调用远程服务
    return remoteService.getUser(userId);
}

// 业务异常降级（如网络超时、服务异常）
public Result getUserInfoFallback(Long userId, Throwable ex) {
    return Result.error("服务暂时不可用，请稍后重试");
}

// 限流/熔断降级（触发规则时）
public Result getUserInfoBlock(Long userId, BlockException ex) {
    return Result.error("系统繁忙，请稍后重试");
}

---

五、热点参数限流实战

5.1 核心概念

热点参数限流是 Sentinel 的独门绝技，能够精准识别并限流"热点参数"。

应用场景：

• 某个商品 ID 被高频访问
• 某个用户 ID 频繁查询
• 某个搜索词被大量使用

与传统限流的区别：

全局限流	热点限流
限制整个接口的总 QPS	限制某个参数值的 QPS
无法区分不同参数	可以对不同参数设置不同阈值

5.2 实战案例：秒杀热点商品限流

场景：双11秒杀活动，某款热门商品（goodsId=1001）被疯狂抢购，占用大量资源。

需求：

• 普通商品：每个商品 ID 最多 100 QPS
• 热门商品 goodsId=1001：限制为 50 QPS

定义资源

@SentinelResource(value = "seckill_goods", blockHandler = "seckillBlock")
@GetMapping("/api/seckill/{goodsId}")
public Result seckill(@PathVariable Long goodsId) {
    // 秒杀逻辑
    return orderService.createSeckillOrder(goodsId);
}

public Result seckillBlock(Long goodsId, BlockException ex) {
    return Result.error("该商品抢购火爆，请稍后重试");
}

配置热点规则

基础配置：

• 资源名：seckill_goods
• 参数索引：0（第一个参数 goodsId）
• 单机阈值：100
• 参数例外项：
  • 参数值：1001，阈值：50

Nacos 配置：

[
  {
    "resource": "seckill_goods",
    "paramFlowItemList": [
      {
        "object": "1001",
        "classType": "long",
        "count": 50
      }
    ],
    "count": 100,
    "grade": 1,
    "paramIdx": 0,
    "durationInSec": 1
  }
]

效果验证

• 访问 /api/seckill/1001：超过 50 QPS 时被限流
• 访问 /api/seckill/1002：超过 100 QPS 时被限流

5.3 高级用法：参数例外

场景：根据用户等级差异化限流

@SentinelResource(value = "api_call", blockHandler = "apiBlock")
@PostMapping("/api/query")
public Result queryData(@RequestParam Long userId) {
    // 业务逻辑
    return dataService.query(userId);
}

配置：

• 资源名：api_call
• 参数索引：0（userId）
• 单机阈值：100（普通用户）
• 参数例外项：
  • userId=10001（金牌用户）：500 QPS
  • userId=20001（钻石用户）：Integer.MAX_VALUE（不限流）

---

六、系统保护规则实战

6.1 核心概念

系统保护规则是全局兜底保护机制，从系统整体维度监控应用状态，当系统负载过高时自动触发限流。

保护维度：

• CPU 使用率
• 平均响应时间（RT）
• 并发线程数
• 入口 QPS

工作原理：当任一指标超过阈值时，自动拒绝部分入口流量，让系统有时间恢复。

6.2 实战案例：防止系统过载

场景：促销活动期间，流量激增导致系统 CPU 使用率飙升到 95%，整个应用崩溃。

配置系统保护规则：

# 规则1：CPU 使用率保护
阈值类型：CPU 使用率
阈值：0.8（80%）
降级策略：拒绝请求

# 规则2：平均 RT 保护
阈值类型：平均响应时间
阈值：1000（1秒）
降级策略：拒绝请求

# 规则3：并发线程数保护
阈值类型：并发线程数
阈值：1000（线程池大小的 80%）
降级策略：拒绝请求

# 规则4：入口 QPS 保护
阈值类型：入口 QPS
阈值：5000
降级策略：拒绝请求

Nacos 配置：

[
  {
    "highestSystemLoad": -1,
    "highestCpuUsage": 0.8,
    "avgRt": 1000,
    "maxThread": 1000,
    "qps": 5000
  }
]

6.3 与流量控制的区别

维度	流量控制	系统保护
作用范围	单个资源（接口/方法）	整个应用
触发条件	资源 QPS/线程数超过阈值	系统整体指标超标
应用场景	常规限流	全局兜底，最后一道防线

最佳实践：系统保护规则必须与流量控制规则配合使用，形成多道防线。

---

七、参数设置实战指南

7.1 阈值设置公式

QPS 阈值 = 压测最大QPS × (1 - 安全系数)
安全系数推荐：0.2-0.3（预留 20-30% 缓冲）

示例：

• 压测测得系统最大承载 QPS：5000
• 建议设置阈值：5000 × 0.8 = 4000

7.2 各场景参数建议

场景1：秒杀活动（高并发突发流量）

流量控制：
- QPS 阈值：压测最大值的 70-80%
- 流控效果：Warm Up
- 预热时长：5-15秒

热点参数：
- 单机阈值：接口限流的 1/2-2/3
- 热点参数阈值：大幅降低（如普通值的 50%）

系统保护：
- CPU 阈值：75-80%

场景2：核心支付接口（高可靠性要求）

流量控制：
- QPS 阈值：数据库连接池的 70-80%
- 流控效果：快速失败

熔断降级：
- 慢调用阈值：P95 响应时间的 1.5 倍
- 异常比例阈值：50-70%
- 最小请求数：正常流量的 10-20%
- 熔断时长：5-10秒

系统保护：
- 并发线程数：线程池核心数的 80%

场景3：数据统计接口（非实时、可排队）

流量控制：
- 流控效果：匀速排队
- 超时等待时间：500-2000ms
- QPS 阈值：目标处理能力

7.3 熔断规则黄金法则

最小请求数 = 正常QPS × 统计时长 × 0.1-0.2

示例：

• 正常 QPS：100
• 统计时长：1 秒
• 最小请求数：10-20

7.4 避坑指南

坑点	现象	解决方案
资源名称不一致	规则不生效	统一使用接口路径作为资源名
阈值设置过高	限流失效	必须基于压测数据设置
最小请求数过小	误触发熔断	设置为正常流量的 10% 以上
未持久化规则	重启后规则丢失	必须集成 Nacos/Apollo
兜底方法参数错误	限流时 500 错误	方法签名必须与原方法一致
忽略系统保护	核心服务被压垮	必须配置系统级保护规则

---

八、生产环境最佳实践

8.1 分级防护策略

第一道防线：热点参数限流（精准打击热点）
第二道防线：流量控制（接口级保护）
第三道防线：熔断降级（依赖服务保护）
第四道防线：系统保护（全局兜底）

8.2 落地步骤

1. 收集基线数据：正常流量下的 QPS、CPU、RT、线程数
2. 配置初步规则：基于基线数据的 70-80% 设置阈值
3. 监控规则效果：观察限流/熔断/系统保护触发情况
4. 动态调整阈值：根据实际情况微调，避免误杀或失效
5. 压测验证：模拟极端场景，验证规则有效性
6. 渐进式上线：先在非核心接口验证，再推广到核心业务

8.3 监控与告警

关键监控指标：

指标	说明	告警阈值
限流拒绝率	限流是否生效	> 20% 时告警
熔断触发次数	依赖服务是否异常	每分钟 > 10 次
系统 CPU 使用率	系统负载	> 70% 预警，> 80% 告警
系统 RT	整体响应时间	超过 P95 正常值的 2 倍
系统保护触发次数	保护机制是否生效	每分钟 > 10 次

8.4 必做事项清单

• 所有对外暴露的接口都标记为 Sentinel 资源
• 规则必须持久化到 Nacos/Apollo
• 核心接口配置流控 + 熔断 + 系统保护
• 核心依赖服务配置熔断降级
• 热点参数配置热点限流规则
• 开启监控告警
• 定期进行限流/熔断演练

---

九、总结

9.1 核心要点回顾

1. Sentinel 是流量卫士：从流量控制、熔断降级、系统保护、热点限流四个维度保障微服务稳定性

2. 规则设置基于数据：不要拍脑袋，必须基于压测数据和监控指标

3. 分级防护是关键：热点限流 → 流控 → 熔断 → 系统保护，形成多道防线

4. 持久化必不可少：集成 Nacos/Apollo，避免规则丢失

5. 监控告警不能少：及时发现异常，快速响应

9.2 常见问题 Q&A

Q1：Sentinel 和 Hystrix 有什么区别？

维度	Sentinel	Hystrix
功能	流控、熔断、系统保护、热点限流	主要是熔断和线程隔离
性能	轻量级，性能损耗低	基于线程池，性能损耗较高
规则配置	动态配置，控制台实时调整	主要通过代码配置
社区	活跃，中文文档完善	停止维护

Q2：规则阈值应该如何设置？

必须基于压测数据，推荐公式：

阈值 = 压测最大值 × 0.7-0.8

Q3：为什么规则不生效？

常见原因：

• 资源名称不匹配（检查大小写、特殊字符）
• 阈值设置过高（基于实际流量调整）
• 未调用接口（Sentinel 使用懒加载）

Q4：系统保护和流量控制有什么区别？

• 流量控制：针对单个资源，常规限流
• 系统保护：针对整个应用，全局兜底

Q5：生产环境必须配置哪些规则？

• 核心接口：流控规则 + 熔断规则
• 核心依赖：熔断规则
• 所有服务：系统保护规则（全局兜底）

---

十、资源链接

官方文档

• Sentinel 官方文档（中文）
• GitHub 仓库
• Spring Cloud Alibaba Sentinel 文档

---

结语

Sentinel 作为微服务架构中的重要组件，能够在复杂场景下保障系统的稳定性。但工具只是手段，真正的价值在于：

1. 理解业务场景：不同场景需要不同的防护策略
2. 基于数据决策：所有规则设置都要有数据支撑
3. 持续优化迭代：规则不是一成不变的，需要根据实际情况持续调优