Sentinel：阿里云高并发流量控制

Sentinel 是阿里开源的分布式流量治理组件，核心目标是通过流量控制、熔断降级等机制，让系统获得 “自适应免疫力”，解决高并发下的服务稳定性问题（如流量击穿、雪崩效应）。适配 Spring Cloud、Dubbo 等主流框架，支持动态规则配置与实时监控。

一 Sentinel的三大核心概念

概念	通俗解释	举例
资源	要保护的 “目标”（接口、方法、代码块）	订单接口/api/order/create、Feign 调用user-service
规则	保护资源的 “策略”（限流、熔断等）	“订单接口 QPS 超 100 就限流”“调用超时超 3 秒就熔断”
簇点链路	资源的 “调用关系图”（展示谁调用了这个资源）	前端→订单服务→库存服务（库存服务是订单服务的下游资源）

核心逻辑：先定义 “资源”，再给资源加 “规则”，通过 “簇点链路” 查看资源调用情况。

二 Sentinel的安装与使用

1、Sentinel控制台的下载
下载地址：https://github.com/alibaba/Sentinel/releases/tag/1.8.3

直接下载jar包

建议放在单独目录（如 D:\sentinel 或 /home/user/sentinel），避免路径含中文 / 空格。

启动(防止8080端口被占用，从而使用18080)：

java -Dserver.port=18080 -Dcsp.sentinel.dashboard.server=localhost:18080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.6.jar

2、访问Sentinel

浏览器输入：localhost:18080
账号密码 默认都是 sentinel

三 集成SpringCloud

1 引入依赖

​<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId><version>${spring-cloud-alibaba.version}</version></dependency>​<!-- sentinel + nacos -->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2 添加配置

spring:application:name: mdx-shop-user # 服务名（注册到Nacos）cloud:nacos:discovery:server-addr: localhost:8848 # Nacos地址namespace: mdx # 环境隔离（如dev/test）group: mdx # 服务分组sentinel:transport:dashboard: localhost:18080 # Sentinel控制台地址datasource: # 规则持久化（存Nacos，避免重启丢失）flow: # 流控规则nacos:server-addr: localhost:8848dataId: ${spring.application.name}-flow-rulesgroupId: SENTINEL_GROUPrule-type: flow # 规则类型（flow=流控，degrade=熔断）degrade: # 熔断规则nacos:server-addr: localhost:8848dataId: ${spring.application.name}-degrade-rulesgroupId: SENTINEL_GROUPrule-type: degrade
feign:sentinel:enabled: true # 开启Feign+Sentinel整合（Feign调用失败触发降级）

3 定义资源

@RestController
@RequestMapping("/api/user")
public class UserController {// 资源名：userGetById，降级方法：getUserFallback@SentinelResource(value = "userGetById", blockHandler = "getUserFallback")@GetMapping("/{id}")public String getUserById(@PathVariable String id) {// 业务逻辑：查询用户信息return "用户ID：" + id + "，姓名：张三";}// 降级方法：参数、返回值必须和原方法一致，最后加BlockExceptionpublic String getUserFallback(String id, BlockException e) {// 限流/熔断时返回的提示return "当前访问人数过多，请稍后重试（用户查询服务）";}
}

4 Nacos中配置Sentinel

打开 Nacos 控制台（localhost:8848/nacos），新建配置：​

• 数据 ID：mdx-shop-user-flow-rules（对应 yml 中的 dataId）；​

• 分组：SENTINEL_GROUP；​

• 配置格式：JSON；​

• 配置内容（流控规则示例）：​

  [{"resource": "userGetById", // 资源名"grade": 1, // 阈值类型：1=QPS，0=并发线程数"count": 10, // 阈值：每秒10次请求"controlBehavior": 0, // 流控效果：0=快速失败，1=Warm Up，2=排队等待"strategy": 0, // 流控模式：0=直接，1=关联，2=链路"clusterMode": false // 是否集群：默认false}
  ]

  同理，新建熔断规则配置（数据 ID：mdx-shop-user-degrade-rules）：​

[{"resource": "mdx-shop-order#/api/order/{userId}(String)", // Feign自动生成的资源名"grade": 0, // 熔断策略：0=慢调用比例，1=异常比例，2=异常数"count": 3000, // 最大RT：3000ms"slowRatioThreshold": 0.5, // 慢调用比例阈值：50%"statIntervalMs": 10000, // 统计时长：10秒"timeWindow": 5 // 熔断时长：5秒}
]

四 核心规则精讲（一）：流控规则（控制 “流量”，避免服务被冲垮）​

流控 =“流量控制”，核心是：当资源的请求量超过设定阈值时，如何 “拦截” 多余请求。​

需重点掌握 3 个配置维度，每个维度都对应实际业务场景：​

1. 第一步：选 “阈值类型”（按什么维度限流？）​

决定 “用 QPS 还是并发线程数” 作为限流标准，二选一：​

​

阈值类型​	定义​	适用场景​
QPS（每秒请求数）​	每秒访问资源的请求次数​	接口抗并发能力有限（如秒杀接口）​
并发线程数​	同时处理该资源请求的线程数量​	资源调用耗时久（如数据库慢查询）​

​

举例：秒杀接口用 “QPS=100”（每秒最多 100 人抢）；查询订单详情（查数据库）用 “并发线程数 = 20”（同时最多 20 个线程查库，避免数据库连接耗尽）。​

2. 第二步：选 “流控模式”（对谁限流？）​

决定 “限流作用在哪个调用链路”，3 种模式对应不同业务需求：​

​

流控模式​	逻辑​	场景举例​
直接模式（默认）​	资源自身超阈值，直接限流该资源​	订单接口自身 QPS 超 100，直接拦截订单请求​
关联模式​	当 “关联资源” 超阈值，限流当前资源​	支付接口（关联资源）超负载，限流订单创建（当前资源），避免更多支付请求​
链路模式​	只限制 “特定调用链路” 的请求，其他链路不限​	商品详情接口有 2 个调用方：APP 端和管理端，只限流 APP 端的请求（管理端需优先访问）​

​

关键提醒：用 “链路模式” 时，需在配置文件加一行：spring.cloud.sentinel.web-context-unify=false（关闭 Web 上下文统一，才能识别不同调用链路）。​

3. 第三步：选 “流控效果”（限流后怎么处理？）​

决定 “拦截请求后，给用户返回什么 / 怎么处理”，3 种效果各有侧重：​

​

流控效果​	逻辑​	适用场景​
快速失败（默认）​	超阈值直接抛异常（BlockException），返回自定义提示​	非核心接口（如商品推荐），允许快速失败​
Warm Up（预热）​	初始阈值低，逐渐升高到目标阈值（默认 30 秒）​	秒杀 / 活动启动场景（避免瞬间流量冲垮服务）​
排队等待（匀速）​	用 “漏桶算法” 让请求匀速通过，超时丢弃​	核心接口（如支付），需保证请求不丢失，匀速处理​

​

举例：秒杀活动用 Warm Up：初始阈值 30（前 30 秒每秒 30 人），30 秒后升到 100（正常阈值），避免启动瞬间 100QPS 冲垮服务；支付接口用排队等待：QPS=50，超时时间 500ms，超过 50QPS 的请求排队，500ms 内没处理完就丢弃，保证支付请求有序处理。​

流控规则配置实操（控制台版，最直观）​

1. 启动 Sentinel 控制台（java -jar sentinel-dashboard-1.8.6.jar），访问localhost:8080（账号 sentinel）；​

1. 先调用一次资源（如访问/api/order/create），让簇点链路显示该资源；​

1. 点击资源后的 “流控” 按钮，按需求配置：​

• 示例 1（秒杀接口）：阈值类型 = QPS，阈值 = 100，流控模式 = 直接，流控效果 = Warm Up；​

• 示例 2（支付关联限流）：资源选 “订单创建”，阈值类型 = QPS，阈值 = 50，流控模式 = 关联，关联资源选 “支付接口”。​

五 核心规则精讲（二）：熔断规则（“断尾”，避免级联崩溃）​

熔断 =“服务故障时自动断开调用”，核心是：当下游资源（如 A 调用 B，B 是下游）故障时，A 不再调用 B，而是直接返回降级结果，避免 A 被 B 拖垮。​

需先理解熔断的 “3 个状态”，再学 “3 种熔断策略”：​

1. 先懂熔断的 “状态机”（核心逻辑）​

熔断规则的本质是让资源在 3 个状态间切换，确保故障时 “快速断连”，恢复时 “谨慎试探”：​

​

状态​	行为​	切换条件​
关闭（默认）​	正常调用下游资源，统计异常 / 慢调用情况​	满足 “熔断策略”（如慢调用超 50%）→ 切换到 “开启”​
开启（熔断中）​	不调用下游资源，直接返回降级结果​	熔断时长到（如 5 秒）→ 切换到 “半开”​
半开（试探）​	允许少量请求调用下游，验证是否恢复​	若请求正常→ 切换到 “关闭”；若仍异常→ 切回 “开启”​

​

举例：A 服务调用 B 服务，B 挂了→A 的熔断状态从 “关闭”→“开启”（5 秒内 A 不调用 B）→5 秒后到 “半开”（A 发 1 个请求给 B）→若 B 恢复（请求成功）→A 切回 “关闭”（正常调用）；若 B 还没好（请求失败）→A 切回 “开启”（再等 5 秒）。​

2. 3 种熔断策略（触发熔断的 “条件”）​

决定 “什么情况下，触发熔断（从关闭→开启）”，按业务场景选：​

​

熔断策略​	触发条件（需同时满足）​	适用场景​
慢调用比例​	1. 统计周期内，请求 RT（响应时间）> 设定 “最大 RT”；2. 慢调用占比 > 设定 “比例阈值”（如 50%）；3. 统计周期内请求数 ≥ 5（避免少量请求误判）​	下游服务响应慢（如数据库查大表超时）​
异常比例​	1. 统计周期内，业务异常数（如抛 Exception）占比 > 阈值；2. 统计周期内请求数 ≥ 5​	下游服务报错多（如 B 服务抛 500 错误）​
异常数​	1. 统计周期内，业务异常总数 ≥ 设定 “异常数阈值”；2. 统计周期内请求数 ≥ 5​	下游服务突发故障（如 B 服务连不上，瞬间抛 10 个异常）​

​

配置示例（慢调用比例）：​

给 “订单调用库存” 资源配熔断：最大 RT=3000ms（超过 3 秒算慢调用），比例阈值 = 0.5（50% 是慢调用），统计时长 = 10 秒，熔断时长 = 5 秒。​

→ 10 秒内，若 “订单调用库存” 的请求中，50% 以上 RT>3 秒，且请求数≥5→触发熔断，5 秒内不再调用库存服务，直接返回 “库存服务繁忙”。​

熔断规则配置实操（控制台版）​

簇点链路找到目标资源（如 “订单调用库存”），点击 “降级” 按钮；​
选择熔断策略（如 “慢调用比例”），配置参数：​

• 最大 RT：3000（单位 ms）；​
• 比例阈值：0.5（50%）；​

• 统计时长：10（单位秒）；​

• 熔断时长：5（单位秒）；​
  故意让下游服务慢（如库存服务加Thread.sleep(4000)），触发熔断后，查看是否返回降级结果。