SpringCloud系列 - Sentinel 服务保护（四）

2026/10/3 20:40:44 拓冰建站浏览量

一、介绍

1.1 核心概念

（1）资源

（2）规则

1.2 核心功能

（1）流量控制

（2）熔断降级

（3）系统自适应保护

（4）实时监控与可视化

1.3 工作原理

（1）核心流程

（2）责任链模式

二、整合Sentinel

2.1 下载安装控制台

2.2 引入依赖

2.3 配置文件

2.4 查看效果

2.5 定义资源

2.6 测试流控

三、异常处理

3.1 异常体系

3.2 web接口 - 异常处理

3.3 @SentinelResource - 异常处理

3.4 OpenFeign远程调用 - 异常处理

3.5 try-catch 处理异常

四、流控规则

4.1 阈值类型

4.2 流控模式

（1）直接

（2）链路

（3）关联

4.3 流控效果

（1）快速失败

（2）预热模式（Warm Up）

（3）排队等待（匀速排队）

五、熔断规则

5.1 案例说明

5.2 断路器工作原理

5.3 熔断策略 - 慢调用比例

5.4 熔断策略 - 异常比例

5.5 熔断策略 - 异常数

六、热点规则

七、补充说明

7.1 @SentinelResource异常

7.2 持久化Sentinel规则

7.3 修改Sentinel控制台账号密码

7.4 授权规则

一、介绍

Sentinel是阿里巴巴开源的一款面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来保障微服务的稳定性。本文将全面解析Sentinel的核心概念、工作原理、使用方法和最佳实践。

1.1 核心概念

（1）资源

资源是Sentinel的关键概念，可以是Java应用程序中的任何内容：

由应用程序提供的服务
应用程序调用的其他应用提供的服务
一段代码或方法
一个API接口

大部分情况下，可以使用方法签名、URL甚至服务名称作为资源名来标识资源

（2）规则

围绕资源的实时状态设定的规则主要包括：

流量控制规则：限制资源的访问频率，如QPS、并发线程数
熔断降级规则：当资源不稳定时自动熔断
系统保护规则：保护系统整体负载
热点参数规则：针对特定参数值的流量控制
授权规则：黑白名单控制

所有规则都可以动态实时调整，无需重启应用。

1.2 核心功能

（1）流量控制

Sentinel提供两种流量统计方式：

并发线程数控制：当并发线程数超出阈值，新请求会被立即拒绝
QPS控制：当QPS超出阈值，系统可以拒绝或排队等方式应对

流量控制设计理念包括：

资源调用关系控制
运行指标(QPS、线程数、系统负载等)控制
控制效果(直接限流、冷启动、排队等)

（2）熔断降级

Sentinel通过以下指标判断资源稳定性：

慢调用比例
异常比例
异常数

与Hystrix相比，Sentinel的熔断策略更加灵活：

不依赖线程池隔离，减少线程切换开销
支持基于响应时间和异常比例的熔断
提供半开状态自动恢复机制

（3）系统自适应保护

Sentinel提供系统维度的自适应保护能力：

根据系统负载(如CPU使用率、平均RT等)动态调整入口流量
防止系统在高负载时崩溃
保证系统在能力范围内处理最多请求

（4）实时监控与可视化

Sentinel Dashboard提供：

实时监控各资源的QPS、RT、异常比例等指标
规则配置与管理界面
机器发现与健康状态监控
集群流量汇总统计

1.3 工作原理

（1）核心流程

当请求访问一个资源时，Sentinel的工作流程如下：

资源定义：通过API或注解定义需要保护的资源
规则检查：检查该资源的流量控制、熔断等规则
请求处理：根据规则决定是否允许请求通过
统计监控：记录请求处理结果用于后续规则判断

（2）责任链模式

Sentinel内部采用责任链模式处理请求，包含多个ProcessorSlot：

NodeSelectorSlot：收集资源路径，构建调用树
ClusterBuilderSlot：构建ClusterNode用于统计
StatisticSlot：多维度统计(响应时间、线程数等)
AuthoritySlot：黑白名单校验
SystemSlot：系统指标检查(负载、QPS等)
FlowSlot：流量控制
DegradeSlot：熔断降级
LogSlot：日志记录

开发者可以通过SPI机制自定义Slot并插入处理链。

二、整合Sentinel

2.1 下载安装控制台

官网地址：home | Sentinel

控制台下载地址：https://github.com/alibaba/Sentinel/releases

版本推荐：1.8.8

启动jar包

java -jar sentinel-dashboard-1.8.8.jar

登录控制台

http://localhost:8080/#/login

账号密码默认都是：sentinel

2.2 引入依赖

在servie父工程下引入依赖，前面章节其实已经引入过了

        <!-- 熔断限流 --><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId></dependency>

2.3 配置文件

各个服务的配置文件中配置上sentinel的控制台地址

spring.cloud.sentinel.transport.dashboard=localhost:8080

2.4 查看效果

这样就加载进来了，只不过这些菜单都没有数据，这是因为我们还没有配置资源。

2.5 定义资源

所谓资源，前面也介绍了，Java应用程序中的任何内容都可以称为资源。

以接口为例，我们定义某个接口作为sentinel的资源，通过

@SentinelResource(value = "定义资源名称")注解来定义资源，假设如下这个接口定义成一个资源。当然不限于接口，任何方法内容都可以。

    @SentinelResource(value = "getRemoteUser")@GetMapping("/getRemoteFeign")public User getRemoteFeign(){return systemFeignClient.getUser();}

然后我们重新启动，发送这个请求。

再进入sentinel控制台，从簇点链路中刷新可以看到，它将刚才我们定义的这个资源以及上下游涉及到的都定义为了资源。

每个资源通过右边的操作按钮，可以对它们的流量、熔断、热点等进行控制。

2.6 测试流控

我们就以刚才的资源为例，点击流控按钮，配置流控规则。

比如选择按QPS 每秒1次进行控制

然后我们将刚才的接口快速点击看看，发现提示被限流了。

三、异常处理

上一章最后，我们进行流控测试，发现一旦请求超过指定QPS后，就会限流，页面提示Blocked by Sentinel（flow limiting）。

这在sentinel底层其实是进行了异常处理的默认响应。

但是更多的时候，出现异常我们响应给前端的数据通常有固定的json格式，比如：

那么，我们就需要对默认的异常显示进行修改。

3.1 异常体系

Sentinel在进行异常处理的时候，有一套它自己的异常处理体系。如下是结构图：

3.2 web接口 - 异常处理

前面这种调用接口触发流控的，在sentinel内部是通过DefaultBlockExceptionHandler进行处理的。

它属于web接口类型的异常处理方式。想要自定义处理的办法，就行编写一个类实现BlockExceptionHandle接口。

定义统一返回结果类

在model模块定义通用响应对象

@AllArgsConstructor
@Getter
public enum ResultCode {// 响应结果枚举SUCCESS(200, "成功"),FAIL(500, "失败"),FLOW_LIMIT(501, "流量超出限制");private final int code;private final String msg;
}

/*** 统一返回结果类* @since 2025/7/7 9:07* @author Mr.Hongtao*/
@AllArgsConstructor
@Data
public class Result<T> {private int code;private String msg;private T data;public static <T>Result<T> success() {return new Result<T>(ResultCode.SUCCESS.getCode(), ResultCode.SUCCESS.getMsg(), null);}public static <T>Result<T> success(T data) {return new Result<T>(ResultCode.SUCCESS.getCode(), ResultCode.SUCCESS.getMsg(), data);}public static <T>Result<T> fail(int code, String msg) {return new Result<T>(code, msg, null);}public static <T>Result<T> fail(ResultCode resultCode) {return new Result<T>(resultCode.getCode(), resultCode.getMsg(), null);}public static <T>Result<T> fail() {return new Result<T>(ResultCode.FAIL.getCode(), ResultCode.FAIL.getMsg(), null);}
}

自定义Sentinel的web接口异常处理

/*** Sentinel 中 web接口 自定义异常处理* @since 2025/7/7 9:10* @author Mr.Hongtao*/
@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {private final ObjectMapper objectMapper = new ObjectMapper();@Overridepublic void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, String s, BlockException e) throws Exception {Result<Object> fail = Result.fail(ResultCode.FLOW_LIMIT);String json = objectMapper.writeValueAsString(fail);httpServletResponse.setContentType("application/json;charset=utf-8");PrintWriter writer = httpServletResponse.getWriter();writer.write(json);}
}

测试

重启项目，重新测试接口效果就出来了。

💡注意：测试的时候，细心的小伙伴会发现每次重启项目，sentinel客户端定义的流控规则这些都没有了，又需要重新建立。这个点确实麻烦，而且生产环境这样搞也确实不太合适。不过这里我们暂时先不处理，等到后面统一来看一看如何持久化策略。

3.3 @SentinelResource - 异常处理

演示异常

在前面给这个接口使用@SentinelResource注解标记为了一个资源。那么针对这个资源，它的流控规则是什么样的呢

接下来，我们试着给这个getRemoteUser资源添加一个QPS为1的流控规则。

为了更直观的看出效果，建议删除前面定义的这个接口的流控规则，只保留这个资源的：

快速发起多次调用看看

系统报错页面500了。

分析

前面异常体系图可以知道，针对@SentinelResource资源的异常处理，底层是通过SentinelResourceAspect这个切面进行处理的。

解决方法

方式一：blockHandler属性进行兜底处理

方式二：全局异常处理

@RestControllerAdvice
public class GlobalExceptinHandler {@ExceptionHandler(FlowException.class)public Result<Object> handleFlowException(FlowException e) {return Result.fail(ResultCode.FLOW_LIMIT);}
}

总结说明

@SentinelResource一般标注在非controller的方法上，触发资源进行异常处理。（忽略这里的案例）
一般通过@SentinelResource注解的blockHandler属性配置异常规则
- 没限流，则响应真实数据
- 被限流，则按照blockHandler定义的方法兜底执行
如果没有指定blockHandler，则还可以通过全局异常处理进行返回。

3.4 OpenFeign远程调用 - 异常处理

为OpenFeign远程调用添加流控看看会发生什么

发现我们多次刷新触发了远程调用的兜底回调。

这个是在上一节OpenFeign中已经做好的兜底回调，远程调用失败让它默认返回的数据，通过@FeignClient(value = "service-system", fallback = SystemFeignClientFallback.class)进行了处理的。

当然如果没有这个兜底回调，针对远程调用也可以触发全局异常处理。

3.5 try-catch 处理异常

https://github.com/alibaba/Sentinel/wiki/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8#%E6%96%B9%E5%BC%8F%E4%BA%8C%E6%8A%9B%E5%87%BA%E5%BC%82%E5%B8%B8%E7%9A%84%E6%96%B9%E5%BC%8F%E5%AE%9A%E4%B9%89%E8%B5%84%E6%BA%90

// 1.5.0 版本开始可以利用 try-with-resources 特性（使用有限制）
// 资源名可使用任意有业务语义的字符串，比如方法名、接口名或其它可唯一标识的字符串。
try (Entry entry = SphU.entry("resourceName")) {// 被保护的业务逻辑// do something here...
} catch (BlockException ex) {// 资源访问阻止，被限流或被降级// 在此处进行相应的处理操作
}

以上就是sentinel中异常处理的几种方式，当触发了sentinel的各种规则后，就会按照异常处理机制进行处理。接下来，我们就针对流控规则、熔断规则等到这些规则，进行一一讲解。

四、流控规则

4.1 阈值类型

阈值类型分为QPS和并发线程数两种

QPS(常用)：即每秒并发请求数，通过后面的阈值输入框来输入具体QPS量，例如1就是每秒只允许1个请求数，多余的会被丢弃。它底层是通过计数器来控制并发数量的，属于轻量级并发速度快。
并发线程数：效果和QPS一样，例如每秒通过1个。但是它需要配合线程池，统计线程池里面的线程数量。由于引入了线程池，存在线程切换，性能相对较为低下。一般都用QPS这种方式，除非线程池需要控制线程数量。

是否集群如果勾选了，则有两种集群阈值模式：单机均摊和总体阈值。

所谓单机均摊就是集群中每台机器都固定最多允许并发比如5个请求。

所谓总体阈值就是机器中所有机器总共允许比如5个请求，然后每台机器就根据负载均衡策略来决定各自允许的并发数量。

不勾选则固定某个节点实行规则。

4.2 流控模式

（1）直接

打开高级选项，我们会看到流控模式默认打到直接。

所谓直接，就是我们限制请求的时候，直接对该资源进行限制。

其他几种流控模式如图所示：

（2）链路

如上图所示，资源B（创建订单）有多个调用方，比如普通创建和秒杀，那么我们希望只有秒杀才会对资源B（创建订单）进行限流，普通创建不限流。那么这个时候就可以用到链路模式。

使用链路模式要求关闭上下文统计

提问：为什么不直接对秒杀的接口实行限流，而要限流资源B，再使用链路流控模式，这不整复杂了吗？

秒杀业务里面如果还有其他业务逻辑的话，直接限制秒杀接口，会导致其他业务逻辑都无法执行。
相当于接口限制范围太广泛了。

（3）关联

所谓关联就是：当某个关联资源达到流量阈值时，对当前资源进行限流。

这种模式适用于存在竞争或优先级差异的场景，旨在通过限制低优先级资源的访问，保障高优先级资源的稳定性。

典型应用场景

订单系统：支付（写订单状态）和查询订单操作竞争数据库锁。关联模式可确保支付接口优先，当支付流量过高时，自动限制查询请求。

4.3 流控效果

（1）快速失败

当请求超过设定的QPS或线程数阈值时，立即拒绝新请求并抛出异常。这是默认的流控效果，响应速度最快。

场景场景

对实时性要求不高但需要快速保护系统的场景，如秒杀系统的峰值流量控制。
防止突发流量导致系统崩溃，例如API网关的全局限流。

（2）预热模式（Warm Up）

系统冷启动时，阈值从较低值（初始阈值 = 最大阈值 / coldFactor，默认3）逐步增加到设定的最大阈值，避免冷启动时高流量压垮服务。预热时长内，系统逐渐适应流量增长。

适用场景

服务启动或长时间低负载后的流量突增，如微服务实例扩容后的初始化阶段。
需要平滑过渡到高并发的业务，如电商大促前的预热期

（3）排队等待（匀速排队）

超出阈值的请求进入队列，按照固定间隔时间（如QPS=5则间隔200ms）匀速处理。若请求等待时间超过设定的超时时长（如2000ms），则拒绝请求。

匀速排队不支持QPS>1000的情况。

核心机制

基于漏桶算法，实现流量整形，使QPS曲线平滑。
队列长度有限，超时请求会被丢弃。

适用场景

处理间隔性突发流量，如消息队列消费或批量任务提交。
需要“削峰填谷”的场景，例如订单系统的异步处理。

五、熔断规则

熔断降级是Sentinel的核心功能之一，旨在通过主动切断不稳定资源的调用，防止局部故障扩散为系统级雪崩。

5.1 案例说明

商品详情页服务链故障

场景

商品详情服务依赖商品信息、价格、评论三个服务，若评论服务因数据库故障响应超时（如RT>5s），且未做熔断隔离。

雪崩过程

评论服务超时 → 商品详情服务的线程池被同步等待的请求占满。
线程池耗尽 → 商品详情服务无法处理新请求（包括调用商品/价格服务的请求）。
商品和价格服务因调用方（商品详情）不可用，间接成为“受害者”，整个系统瘫痪。

Sentinel熔断作用

当评论服务异常比例超过阈值（如50%），Sentinel会熔断对该服务的调用，直接返回降级结果（如默认评论数据），避免线程池耗尽。

5.2 断路器工作原理

Sentinel中的断路器（Circuit Breaker）是一种基于状态机的熔断降级机制，通过实时监控资源调用的异常比例、慢调用比例或异常数，动态切换状态以保护系统免于雪崩效应。

状态机模型与状态转换

Sentinel断路器采用有限状态机，包含三种核心状态和两种特殊状态：

CLOSED（关闭）：初始状态，所有请求正常通过。此时断路器会统计调用结果（如异常数、慢调用比例），当达到阈值时触发状态转换。

OPEN（打开）：当错误率或慢调用比例超过阈值时，断路器进入此状态，直接拒绝所有请求并抛出BlockException。此时会启动一个熔断时长计时器（如5秒），超时后进入半开状态。

HALF_OPEN（半开）：熔断时长结束后，断路器允许少量请求通过以探测服务是否恢复。若请求成功则转为CLOSED，否则重新进入OPEN状态

以慢调用比例为例，初始状态请求正常通过，当在指定时长范围内达到最小请求数时，此时如果慢调用比例超过阈值（需要设置比如：请求时长超过5s且数量超过70%），则触发开状态。此后就不再调用请求了，达到熔断时长后进入半开状态。然后断路器会放行少量请求，如果请求成功则转为关闭状态，否则重新进入开状态。

5.3 熔断策略 - 慢调用比例

创建策略

修改远程调用接口

测试

慢慢点两次，发现它差不多4s能正常返回

但是如果我快速请求，触发了熔断策略，就默认进行了熔断，触发了全局异常处理。

30s后再点击一次，发现又能正常访问了。

但是继续点击又不行，说明从半开状态又进入了开状态，继续熔断。

5.4 熔断策略 - 异常比例

当统计周期内异常请求比例超过阈值（如30%），触发熔断。仅统计业务异常，不包含Sentinel自身的限流异常。

慢慢点击，发现触发了OpenFeign的兜底回调。

快速点击5次，发现页面直接显示兜底回调数据，但是被调用方控制台不在打印错误日志，就说明没有再发起调用了，直接触发兜底。成功熔断！

所以这里说一下，有熔断和如熔断规则，这样看好像都能进行兜底回调。但是区别是，无熔断每次都要发起请求，只有在超时或者错误后才会兜底。而有熔断，只要达到阈值后，就直接兜底回调，压根儿不去请求了。

所以熔断会让系统更加健壮！

5.5 熔断策略 - 异常数

区别就是异常数超过阈值则触发熔断。这里不再赘述。

六、热点规则

热点规则（ParamFlowRule） 是Sentinel提供的一种细粒度限流策略，针对高频访问的特定参数值进行流量控制。其核心目标是识别并限制热点数据（如热门商品ID、频繁访问的用户IP等），避免局部资源过载。

使用场景示例

@GetMapping("/seckill")
@SentinelResource(value = "seckill-resource", blockHandler = "handleBlock")
public String seckill(@RequestParam("userId") String userId) {return "秒杀成功: " + userId;
}// 限流处理逻辑
public String handleBlock(String userId, BlockException ex) {return "不能重复下单，请稍后再试！";
}

需求1：每个用户秒杀QPS不得超过1（秒杀下单userId级别）

这样相同用户就只能1s一次了

需求2：6号用户是vvip，不限制QPS(例外情况)

高级规则添加参数例外项，这样其他userId都会触发热点限流，而6则不会触发。

说明：如果要针对方法的多个参数添加热点限流规则，那么再新增一个热点规则即可。

七、补充说明

7.1 @SentinelResource异常

关于@SentinelResource注解的异常处理有两种异常处理属性blockHandler和fallback。

    @GetMapping("/seckill")@SentinelResource(value = "seckill-resource", blockHandler = "handleBlock")public String seckill(@RequestParam("userId") String userId) {return "秒杀成功: " + userId;}// 限流处理逻辑public String handleBlock(String userId, BlockException ex) {return "不能重复下单，请稍后再试！";}

    @GetMapping("/seckill")@SentinelResource(value = "seckill-resource", fallback = "handleBlock")public String seckill(@RequestParam("userId") String userId) {int i = 10/ 0;return "秒杀成功: " + userId;}// 限流处理逻辑public String handleBlock(String userId, Throwable ex) {return "不能重复下单，请稍后再试！";}

这两种方式都能进行异常处理，区别是有blockHandler优先blockHandler，没有则走fallback。

fallback的好处是它还能处理业务异常，但是前提是兜底方法的异常必须用Throwable。

blockHandler就只能处理BlockException异常。

7.2 持久化Sentinel规则

前面我们的使用演示，每次重启项目后Sentinel规则需要重新配置。

Sentinel默认将规则保存在内存中（HashMap结构），项目重启后内存数据自然清空。这种设计虽然轻量，但无法持久化，这在生产环境下将是致命的！

生产环境的 Sentinel Dashboard 需要具备下面几个特性:

规则管理及推送，集中管理和推送规则。sentinel-core 提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式；同时，规则最好在控制台中集中管理。
监控，支持可靠、快速的实时监控和历史监控数据查询。sentinel-core 记录秒级的资源运行情况，并且提供 API 来拉取资源运行信息。当机器大于一台以上的时候，可以通过 Dashboard 来拉取，聚合，并且存储这些信息。这个时候，Dashboard 需要有一个存储媒介，来存储历史运行情况。
权限控制，区分用户角色，来进行操作。生产环境下的权限控制是非常重要的，理论上只有管理员等高级用户才有权限去修改应用的规则。

规则管理及推送

一般来说，规则的推送有下面三种模式:

推送模式	说明	优点	缺点
原始模式	API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource）	简单，无任何依赖	不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境
Pull 模式	扩展写数据源（WritableDataSource），客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件等	简单，无任何依赖；规则持久化	不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式	扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。	规则持久化；一致性；快速	引入第三方依赖

Push模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：

Nacos 是阿里中间件团队开源的服务发现和动态配置中心。Sentinel 针对 Nacos 作了适配，底层可以采用 Nacos 作为规则配置数据源。使用时只需添加以下依赖：

<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId><version>x.y.z</version>
</dependency>

然后创建 NacosDataSource 并将其注册至对应的 RuleManager 上即可。比如：

// remoteAddress 代表 Nacos 服务端的地址
// groupId 和 dataId 对应 Nacos 中相应配置
ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = new NacosDataSource<>(remoteAddress, groupId, dataId,source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));
FlowRuleManager.register2Property(flowRuleDataSource.getProperty());

注意：如果希望初始化 Nacos 数据源时携带更多的配置（如鉴权配置），可通过带 Properties 的构造函数进行传入。

详细示例可以参见 sentinel-demo-nacos-datasource。

7.3 修改Sentinel控制台账号密码

生产环境下，肯定不能直接用sentinel作为账号密码。一般的方法是去官网github下载源码，然后修改用户名密码后再自己打成jar包。

当然了，如果是内网访问的话，自己做好防火墙防护也不是不可以。不过个人建议修改用户名密码这些。

7.4 授权规则

通俗说就是设置黑白名单，用来控制哪些服务可以访问或者不能访问。

不过我们一般不用它这个，后面使用网关来解决这个问题。

建站实战干货

SpringCloud系列 - Sentinel 服务保护（四）

一、介绍

1.1 核心概念

（1）资源

（2）规则

1.2 核心功能

（1）流量控制

（2）熔断降级

（3）系统自适应保护

（4）实时监控与可视化

1.3 工作原理

（1）核心流程

（2）责任链模式

二、整合Sentinel

2.1 下载安装控制台

2.2 引入依赖

2.3 配置文件

2.4 查看效果

2.5 定义资源

2.6 测试流控

三、异常处理

3.1 异常体系

3.2 web接口 - 异常处理

3.3 @SentinelResource - 异常处理

3.4 OpenFeign远程调用 - 异常处理

3.5 try-catch 处理异常

四、流控规则

4.1 阈值类型

4.2 流控模式

（1）直接

（2）链路

（3）关联

4.3 流控效果

（1）快速失败

（2）预热模式（Warm Up）

（3）排队等待（匀速排队）

五、熔断规则

5.1 案例说明

5.2 断路器工作原理

5.3 熔断策略 - 慢调用比例

5.4 熔断策略 - 异常比例

5.5 熔断策略 - 异常数

六、热点规则

七、补充说明

7.1 @SentinelResource异常

7.2 持久化Sentinel规则

7.3 修改Sentinel控制台账号密码

7.4 授权规则