Sentinel 深度解析：限流与熔断降级的微服务稳定性保障实践
在微服务架构中，“流量不可控” 与 “依赖故障扩散” 是导致系统雪崩的两大核心原因 —— 比如秒杀活动的瞬时高并发可能压垮订单服务，而支付服务的超时故障可能导致订单服务线程池耗尽。Sentinel（哨兵）作为 Alibaba 开源的流量控制与熔断降级组件，通过 “流量控制、熔断降级、系统负载保护” 三大核心能力，为微服务打造了一道 “稳定性防线”。本文将从原理到实战，带你全面掌握 Sentinel 的限流与熔断降级逻辑，构建高可用的微服务系统。
一、微服务稳定性痛点：为什么需要 Sentinel？
在深入 Sentinel 技术细节前，先明确其解决的核心问题，理解 “限流” 与 “熔断降级” 的必要性。
1.1、 微服务面临的两大核心风险
1.1.1、 流量风险：瞬时高并发导致服务过载
- 场景：秒杀、促销活动时，请求量突增 10 倍甚至 100 倍，超出服务处理能力；
- 后果：线程池满、数据库连接耗尽、响应时间飙升，最终服务不可用（如 “页面打不开”“下单失败”）；
- 传统方案局限：仅靠 “扩容” 无法应对瞬时流量（扩容有延迟），且成本过高。
1.1.2、 依赖风险：故障扩散导致系统雪崩
- 场景：订单服务依赖支付服务，若支付服务因故障超时（如响应时间从 100ms 变为 5s），订单服务的请求会阻塞等待；
- 后果：订单服务线程池被阻塞请求占满，无法处理新请求，进而影响依赖订单服务的用户服务，形成 “故障链”，最终整个系统雪崩；
- 传统方案局限：手动编写 “超时重试” 逻辑无法解决线程池耗尽问题，且缺乏故障隔离机制。
1.2、 Sentinel 的核心价值：为微服务 “保驾护航”
Sentinel 通过以下能力解决上述问题，核心定位是 “流量的哨兵” 与 “故障的隔离墙”：
- 流量控制：限制进入服务的请求量，避免过载（如 “每秒最多处理 1000 个下单请求”）；
- 熔断降级：当依赖服务故障时，快速 “断开” 调用，返回默认结果（如 “支付服务超时，暂时返回‘支付中’提示”），避免故障扩散；
- 系统保护：监控服务 CPU、内存、负载等指标，当系统负载过高时，主动拒绝部分请求，保障核心功能可用；
- 易用性：支持注解配置、控制台可视化操作，无需大量编写代码，且无缝集成 Spring Cloud、Dubbo 等主流框架。
二、Sentinel 基础：核心概念与架构
掌握 Sentinel 的核心组件与关键术语，是理解限流与熔断降级的前提。
2.1、 Sentinel 核心架构：两大组件
Sentinel 的架构分为 “控制台（Dashboard）” 与 “核心库（Client）”，两者协同工作：
| 组件 | 作用 | 部署方式 |
| Sentinel Dashboard | 可视化控制台：配置规则（限流、降级）、监控指标（QPS、响应时间）、查看集群状态 | 独立部署的 Web 应用 |
| Sentinel Client | 核心库：嵌入微服务应用中，执行流量控制、熔断降级逻辑，采集监控数据 | 作为依赖包引入微服务（如 Jar 包） |
2.2、 关键术语：理解 Sentinel 的 “语言体系”
- 资源（Resource）：Sentinel 保护的对象，可是 “接口方法”“服务名”“URL” 等，如 “订单服务的 createOrder 方法”“/api/pay 接口”；
- 规则（Rule）：Sentinel 的执行策略，分为 “流量控制规则”“熔断降级规则”“系统保护规则” 等，如 “为 createOrder 方法配置 QPS 限流阈值 1000”；
- Slot 链（Slot Chain）：Sentinel 的核心执行链，按顺序执行 “节点选择→限流检查→熔断检查→统计” 等逻辑，类似 “过滤器链”；
- 簇点（Cluster Node）：对资源的统计节点，记录资源的 QPS、响应时间、异常数等指标，是规则判断的依据；
- 断路器（Circuit Breaker）：实现熔断降级的核心组件，有 “闭合、开路、半开路” 三种状态，控制是否允许请求调用依赖服务。
三、Sentinel 限流：流量控制的核心实现
限流是 Sentinel 最基础的能力，核心目标是 “让服务只处理能力范围内的请求”，避免过载。
3.1、 限流核心原理：如何判断 “是否拒绝请求”
Sentinel 限流基于 “指标统计 + 规则判断”，核心流程分为 3 步：
- 指标统计：通过 “滑动窗口” 统计资源的实时指标（如 QPS、并发线程数）；
- 滑动窗口：将时间划分为多个 “小窗口”（如 1 秒划分为 10 个 100ms 窗口），实时滚动计算指标，避免 “瞬时峰值” 误判（比传统 “固定窗口” 更精准）。
- 规则匹配：检查当前请求是否命中资源的限流规则（如 QPS 是否超过阈值）；
- 流量控制：若命中规则，执行预设的控制策略（如直接拒绝、排队等待），否则放行请求。
3.2、 限流规则：4 个核心配置维度
Sentinel 限流规则通过 “阈值类型、流控模式、流控效果、来源” 四个维度定义，可通过控制台或代码配置。
3.2.1、 维度 1：阈值类型（限制 “什么指标”）
| 阈值类型 | 含义 | 适用场景 |
| QPS（每秒请求数） | 限制资源每秒最多处理的请求次数 | 读多写少场景（如商品详情查询） |
| 并发线程数 | 限制资源同时处理的线程数 | 写操作或耗时操作（如订单创建、支付） |
示例：QPS 阈值设为 1000，表示该资源每秒最多处理 1000 个请求；并发线程数阈值设为 100，表示该资源同时最多有 100 个线程在处理请求。
3.2.2、 维度 2：流控模式（限制 “哪些请求”）
| 流控模式 | 含义 | 适用场景 |
| 直接 | 直接限制当前资源的请求 | 保护当前资源自身（如订单接口限流） |
| 关联 | 当关联资源（如 B）达到阈值时，限制当前资源（如 A） | 避免资源竞争（如 “下单” 与 “支付” 关联，支付过载时限制下单） |
| 链路 | 仅限制指定调用链路的请求（如 “用户服务→订单服务” 这条链路） | 精细化控制（如只限制从用户服务过来的订单请求） |
3.2.3、 维度 3：流控效果（“如何拒绝” 请求）
| 流控效果 | 含义 | 适用场景 |
| 直接拒绝（Default） | 超过阈值时直接返回失败（如 HTTP 429） | 非核心接口（如商品评论查询） |
| Warm Up（预热） | 阈值从低到高逐渐提升，避免冷启动过载 | 秒杀、促销等流量逐步增长的场景 |
| 排队等待（Rate Limiter） | 超过阈值时请求排队，按固定速率放行 | 核心接口（如下单），需保证请求不丢失 |
Warm Up 示例：QPS 阈值 1000，预热时间 30 秒，前 30 秒阈值从 200（1000×0.2）逐渐提升到 1000，避免瞬时流量冲击服务。
3.2.4、 维度 4：流控来源（限制 “哪个来源的请求”）
指定需要限流的 “调用来源”（如 “仅限制从 APP 端过来的请求”），未指定则对所有来源生效，实现 “按来源精细化限流”。
3.3、 限流实战：Spring Cloud 集成 Sentinel
以 “Spring Cloud Alibaba + Sentinel” 为例，实现订单服务的接口限流。
3.3.1、 步骤 1：环境准备（部署 Sentinel Dashboard）
- 下载控制台：从Sentinel 官网下载最新版 Jar 包（如 sentinel-dashboard-1.8.6.jar）；
- 启动控制台：执行命令java -jar sentinel-dashboard-1.8.6.jar --server.port=8080，默认端口 8080，账号密码均为sentinel；
- 访问控制台：浏览器打开http://localhost:8080，进入 Sentinel 可视化界面。
3.3.2、 步骤 2：微服务集成 Sentinel Client
引入依赖（pom.xml）：
<!-- Spring Cloud Alibaba Sentinel依赖 -->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId><version>2021.0.5.0</version>
</dependency>
<!-- 可选：Sentinel注解支持（@SentinelResource） -->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-annotation-aspectj</artifactId><version>1.8.6</version>
</dependency>配置 Sentinel（application.yml）：
spring:application:name: order-service # 服务名，将在Sentinel控制台显示cloud:sentinel:transport:dashboard: localhost:8080 # 连接Sentinel Dashboard地址port: 8719 # Sentinel Client与Dashboard通信的端口（默认8719，自动递增）
server:port: 8081 # 订单服务端口3.3.3、 步骤 3：定义受保护的资源（两种方式）
Sentinel 支持 “注解式” 与 “埋点式” 定义资源，推荐注解式（低侵入）。
方式 1：@SentinelResource 注解（推荐）
import com.alibaba.csp.sentinel.annotation.SentinelResource;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;@RestController
@RequestMapping("/api/order")
public class OrderController {/*** 下单接口：用@SentinelResource标记为受保护资源* value：资源名（唯一标识）* blockHandler：限流/降级时的处理方法（需与当前方法参数一致，最后加BlockException）*/@SentinelResource(value = "createOrder", blockHandler = "createOrderBlockHandler")@GetMapping("/create")public String createOrder(@RequestParam("userId") Long userId, @RequestParam("goodsId") Long goodsId) {// 业务逻辑：创建订单return "订单创建成功！userId=" + userId + ", goodsId=" + goodsId;}/*** 限流/降级处理方法：当createOrder触发限流时执行*/public String createOrderBlockHandler(Long userId, Long goodsId, BlockException e) {// 返回友好提示（如“当前下单人数过多，请稍后再试”）return "系统繁忙，请稍后重试（限流保护）";}
}方式 2：URL 自动识别（无需注解）
Sentinel 默认会将 “Spring MVC 的 URL 接口” 自动识别为资源（资源名为 URL 路径，如/api/order/create），无需额外注解，适合快速集成。
3.3.4、 步骤 4：配置限流规则（控制台操作）
- 访问 Sentinel 控制台：进入http://localhost:8080，找到 “order-service” 服务；
- 添加限流规则：
- 进入 “流量控制规则”→“新增”，配置参数：
- 资源名：createOrder（与 @SentinelResource 的 value 一致）；
- 阈值类型：QPS；
- 单机阈值：10（每秒最多 10 个请求）；
- 流控模式：直接；
- 流控效果：直接拒绝；
- 测试限流：用 Postman 或 JMeter 每秒发送 15 个请求到http://localhost:8081/api/order/create?userId=1&goodsId=100，会有 5 个请求返回 “系统繁忙，请稍后重试（限流保护）”，符合 QPS=10 的阈值。
3.4、 限流高级特性：热点参数限流
针对 “某一参数值的请求过于集中” 的场景（如 “秒杀同一商品的请求过多”），Sentinel 支持 “热点参数限流”，即对资源的特定参数值单独限流。
3.4.1、 配置热点规则（控制台操作）
进入 “热点规则”→“新增”，配置参数：
- 资源名：createOrder；
- 参数索引：1（表示限流的参数是第 2 个参数 goodsId，索引从 0 开始）；
- 单机阈值：5（同一 goodsId 每秒最多 5 个请求）；
- 例外项（可选）：若 goodsId=100（热门商品），阈值设为 2（更严格）；
测试：
- 访问/api/order/create?userId=1&goodsId=100：每秒发送 3 个请求，会有 1 个被限流；
- 访问/api/order/create?userId=1&goodsId=200：每秒发送 6 个请求，会有 1 个被限流（符合阈值 5）。
四、Sentinel 熔断降级：故障隔离的核心实现
熔断降级的核心目标是 “当依赖服务故障时，快速断开调用，避免故障扩散”，类似 “电路保险丝”—— 电流过大时熔断，保护电路不被烧毁。
4.1、 熔断降级核心原理：断路器状态机
Sentinel 的熔断降级基于 “断路器模式”，包含三种状态，状态切换由 “依赖服务的健康指标”（RT、异常比例、异常数）触发：
| 状态 | 含义 | 行为逻辑 |
| 闭合（CLOSED） | 断路器关闭，请求正常调用依赖服务 | 实时统计依赖服务的健康指标（如 RT），若触发阈值则切换到 “开路” 状态 |
| 开路（OPEN） | 断路器打开，拒绝调用依赖服务 | 直接返回降级结果（如默认值），避免请求阻塞；经过 “熔断时长” 后切换到 “半开路” 状态 |
| 半开路（HALF_OPEN） | 断路器半打开，允许少量请求试探调用 | 若试探请求成功（依赖服务恢复），切换到 “闭合” 状态；若失败，切换回 “开路” 状态 |
4.2、 熔断降级规则：3 种降级策略
Sentinel 支持三种降级策略，通过监控依赖服务的指标触发熔断：
4.2.1 策略 1：平均响应时间（RT）
- 触发条件：当依赖服务的平均响应时间超过阈值（如 500ms），且 1 秒内请求数超过最小请求数（如 5），则触发熔断；
- 适用场景：依赖服务超时（如支付服务响应时间从 100ms 变为 3s）；
- 配置示例：RT 阈值 = 500ms，最小请求数 = 5，熔断时长 = 10s（开路状态持续 10 秒后进入半开路）。
4.2.2、 策略 2：异常比例
- 触发条件：当依赖服务的异常比例（异常请求数 / 总请求数）超过阈值（如 50%），且 1 秒内请求数超过最小请求数（如 5），则触发熔断；
- 适用场景：依赖服务抛出异常（如支付服务数据库错误，大量请求返回 500）；
- 配置示例：异常比例阈值 = 0.5（50%），最小请求数 = 5，熔断时长 = 10s。
4.2.3、 策略 3：异常数
- 触发条件：当依赖服务的异常数在 1 分钟内超过阈值（如 10），则触发熔断；
- 适用场景：依赖服务偶尔异常，但累计异常数过多（如支付服务 1 分钟内出现 20 次异常）；
- 配置示例：异常数阈值 = 10，统计时长 = 60s，熔断时长 = 10s。
4.3、 熔断降级实战：保护依赖服务调用
以 “订单服务调用支付服务” 为例，配置熔断降级，避免支付服务故障影响订单服务。
4.3.1、 步骤 1：定义依赖服务调用（Feign 调用支付服务）
引入 Feign 依赖（pom.xml）：
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>定义 Feign 客户端（调用支付服务）：
import com.alibaba.csp.sentinel.annotation.SentinelResource;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;// 调用支付服务，fallback指定降级处理类
@FeignClient(name = "pay-service", fallback = PayFeignFallback.class)
public interface PayFeignClient {/*** 调用支付服务的支付接口，用@SentinelResource标记为资源*/@SentinelResource(value = "callPayService")@GetMapping("/api/pay/doPay")String doPay(@RequestParam("orderId") Long orderId, @RequestParam("amount") Double amount);
}定义降级处理类（支付服务故障时返回默认结果）：
import org.springframework.stereotype.Component;// Feign客户端的降级处理类，需实现PayFeignClient接口
@Component
public class PayFeignFallback implements PayFeignClient {/*** 支付服务故障时的降级逻辑*/@Overridepublic String doPay(Long orderId, Double amount) {// 返回默认结果（如“支付服务暂时不可用，已为您保留订单，请稍后重试”）return "支付服务繁忙，订单" + orderId + "已保留，稍后可重试支付";}
}4.3.2、 步骤 2：配置熔断降级规则（控制台操作）
1、进入 Sentinel 控制台 “order-service”→“熔断降级规则”→“新增”，配置参数：
- 资源名：callPayService（与 @SentinelResource 的 value 一致）；
- 降级策略：平均响应时间；
- RT 阈值：500ms；
- 最小请求数：5；
- 熔断时长：10s；
2、模拟支付服务故障：将支付服务的doPay接口添加延迟（如Thread.sleep(1000)，响应时间 1000ms，超过阈值 500ms）；
3、测试熔断：
- 快速发送 6 个请求到订单服务的/api/order/create（会调用支付服务）；
- 前 5 个请求：支付服务响应超时，Sentinel 统计 RT 超过阈值；
- 第 6 个请求：断路器从 “闭合” 切换到 “开路”，直接触发降级，返回 “支付服务繁忙，订单已保留...”。
4.4、 熔断降级注意事项
- 降级逻辑必须轻量：降级处理方法（如PayFeignFallback.doPay）不能有复杂逻辑或依赖其他服务，避免降级逻辑自身故障；
- 熔断时长合理设置：熔断时长过短（如 1s）会导致断路器频繁切换状态，过长（如 60s）会影响用户体验，建议设为 10~30s；
- 半开路状态试探：半开路状态下，Sentinel 仅允许 “1 个请求” 试探调用，避免大量请求再次压垮依赖服务。
五、Sentinel 进阶：生产环境关键优化
基础集成满足功能需求，生产环境需从 “规则持久化、监控告警、集群容错” 三方面优化，确保 Sentinel 稳定运行。
5.1、 规则持久化：避免规则丢失
Sentinel 默认将规则存储在内存中，微服务重启后规则会丢失，生产环境需将规则持久化到配置中心（如 Nacos、Apollo）。
5.1.1、 集成 Nacos 实现规则持久化
引入依赖（pom.xml）：
<!-- Sentinel Nacos规则持久化依赖 -->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId><version>1.8.6</version>
</dependency>配置 Nacos 数据源（application.yml）：
spring:cloud:sentinel:datasource:# 限流规则持久化到Nacosflow-rule:nacos:server-addr: localhost:8848 # Nacos地址data-id: order-service-sentinel-flow-rules # Nacos中的Data IDgroup-id: SENTINEL_GROUP # 分组rule-type: flow # 规则类型（flow：限流，degrade：降级）# 熔断降级规则持久化到Nacosdegrade-rule:nacos:server-addr: localhost:8848data-id: order-service-sentinel-degrade-rulesgroup-id: SENTINEL_GROUPrule-type: degrade在 Nacos 创建规则配置：
在 Nacos 控制台创建 Data ID 为order-service-sentinel-flow-rules的配置，格式为 JSON，内容示例（限流规则）：
[{"resource": "createOrder","limitApp": "default","grade": 1, // 1：QPS，0：并发线程数"count": 10, // 阈值"strategy": 0, // 0：直接，1：关联，2：链路"controlBehavior": 0, // 0：直接拒绝，1：Warm Up，2：排队等待"clusterMode": false // 是否集群限流}
]5.2、 监控告警：及时发现异常
Sentinel 支持将监控指标（QPS、RT、熔断次数）推送到 Prometheus、Grafana，或通过钉钉、邮件发送告警，确保及时发现问题。
5.2.1、 集成 Prometheus+Grafana 监控
引入依赖（pom.xml）：
<!-- Sentinel Prometheus导出依赖 -->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-metric-exporter</artifactId><version>1.8.6</version>
</dependency>配置 Prometheus：在prometheus.yml中添加 Sentinel 监控目标：
scrape_configs:- job_name: 'sentinel'static_configs:- targets: ['localhost:8081'] # 订单服务地址（Sentinel默认暴露/actuator/prometheus端点）Grafana 配置仪表盘：导入 Sentinel 官方仪表盘模板（ID：12721），即可可视化查看 QPS、RT、熔断次数等指标。
5.2.2、 配置钉钉告警
1、在 Sentinel 控制台 “集群点链路”→“新增告警规则”，配置参数：
- 资源名：callPayService；
- 告警阈值：异常比例超过 50%；
- 告警接收人：添加钉钉机器人 Webhook 地址；
2、当支付服务异常比例超过 50% 时，Sentinel 会自动发送钉钉消息告警。
5.3、 集群限流：应对分布式部署
当微服务集群部署（如多个订单服务实例）时，单机限流无法控制 “集群总流量”（如每个实例限流 100QPS，3 个实例总流量 300QPS，可能超过数据库承受能力），需配置 “集群限流”。
5.3.1、 集群限流核心原理
- Token Server：集群中选择一个实例作为 “Token Server”，负责统一分配令牌；
- Token Client：其他实例作为 “Token Client”，每次请求前向 Token Server 申请令牌，申请到则放行，否则限流；
- 优势：确保集群总流量不超过阈值（如集群总 QPS=200，无论多少实例，总请求数控制在 200）。
5.3.2、 配置集群限流（控制台操作）
- 进入 “流量控制规则”→“新增”，勾选 “集群模式”；
- 配置 “Token Server 地址”（如localhost:8081，指定某一实例为 Token Server）；
- 集群阈值设为 200，即可实现 “集群总 QPS 不超过 200”。
六、常见问题与解决方案
Sentinel 集成与使用中，易遇到规则不生效、降级逻辑未执行、监控数据丢失等问题，以下是高频问题的解决方案。
6.1、 问题 1：Sentinel 控制台看不到服务实例
原因：
- 微服务未引入spring-cloud-starter-alibaba-sentinel依赖；
- 微服务与 Sentinel Dashboard 网络不通（如端口被防火墙拦截）；
- 微服务未发送请求（Sentinel 客户端需有请求触发后才会注册到控制台）；
解决方案：
- 检查依赖是否完整；
- 验证spring.cloud.sentinel.transport.dashboard配置是否正确，测试端口连通性（telnet localhost 8080）；
- 手动发送一个请求到微服务接口（如/api/order/create），触发客户端注册。
6.2、 问题 2：熔断降级规则不生效
原因：
- 资源名配置错误（与@SentinelResource的 value 不一致）；
- 未满足 “最小请求数” 条件（如 RT 阈值 500ms，但 1 秒内请求数仅 3 个，未达到最小请求数 5）；
- 降级策略与实际故障类型不匹配（如配置 “异常比例” 降级，但依赖服务是超时故障，应配置 “RT” 降级）；
解决方案：
- 核对资源名，确保与代码中一致；
- 增加请求量，确保满足最小请求数；
- 根据依赖服务故障类型选择正确的降级策略（超时→RT，异常→异常比例 / 异常数）。
6.3、 问题 3：规则持久化后，控制台修改规则不生效
- 原因：Sentinel 规则持久化采用 “Nacos 优先”，控制台修改规则后不会同步到 Nacos，微服务重启后会从 Nacos 加载旧规则；
- 解决方案：
- 所有规则修改通过 Nacos 控制台进行，避免直接在 Sentinel 控制台修改；
- 若需在 Sentinel 控制台修改，需开发 “规则同步插件”，实现 Sentinel 控制台到 Nacos 的规则同步。
6.4、 问题 4：降级处理类（Feign Fallback）未执行
- 原因：
- 未在@FeignClient中指定fallback属性，或降级处理类未被 Spring 管理（未加@Component）；
- 故障类型不是 “熔断降级”（如请求被限流，会触发blockHandler，而非fallback）；
- 解决方案：
- 确保@FeignClient(fallback = PayFeignFallback.class)，且PayFeignFallback加@Component；
- 区分 “限流” 与 “降级”：限流触发blockHandler，熔断降级触发fallback。
七、结语：Sentinel 在微服务稳定性中的价值与未来
Sentinel 通过 “限流” 抵御流量风险，通过 “熔断降级” 隔离依赖故障，为微服务构建了 “事前预防、事中控制、事后恢复” 的完整稳定性保障体系。其核心优势在于 “轻量级、易集成、可扩展”—— 无需复杂的基础设施，嵌入微服务即可生效，且支持自定义规则、降级逻辑、监控告警，适配不同业务场景。
未来，Sentinel 将进一步向 “云原生” 方向演进：
- K8s 集成：支持基于 K8s Pod 指标（如 CPU、内存）的动态限流；
- Service Mesh 适配：与 Istio 等服务网格结合，将流量控制逻辑下沉到 Sidecar，进一步解耦业务与稳定性逻辑；
- AI 驱动的流量预测：通过机器学习预测流量峰值，提前调整限流阈值，实现 “智能限流”。
掌握 Sentinel 的限流与熔断降级，不仅能解决当前微服务的稳定性痛点，更能帮助开发者建立 “系统稳定性思维”—— 在设计微服务时，提前考虑流量风险与依赖故障，而非等到故障发生后再补救。在高并发、高可用的微服务时代，Sentinel 已成为不可或缺的 “稳定性利器”。