Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。
替代Hystrix,针对问题:服务雪崩、服务降级、服务熔断、服务限流
Hystrix:
服务消费者(⾃动投递微服务)—>调⽤服务提供者(简历微服务)
在调⽤⽅引⼊Hystrix—> 单独搞了⼀个Dashboard项⽬—>Turbine
⾃⼰搭建监控平台 dashboard
没有提供UI界⾯进⾏服务熔断、服务降级等配置(⽽是写代码,⼊侵了我们源程序环境)
Sentinel:
独⽴可部署Dashboard/控制台组件
减少代码开发,通过UI界⾯配置即可完成细粒度控制(⾃动投递微服务)
Sentinel 分为两个部分:
核⼼库:(Java 客户端)不依赖任何框架/库,能够运⾏于所有 Java 运⾏时环境,同时对 Dubbo / Spring Cloud 等框架也有较好的⽀持。
控制台:(Dashboard)基于 Spring Boot 开发,打包后可以直接运⾏,不需要额外的 Tomcat 等应⽤容器。
Sentinel 具有以下特征:
丰富的应⽤场景: Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。
完备的实时监控: Sentinel 同时提供实时的监控功能。您可以在控制台中看到接⼊应⽤的单台机器秒级数据,甚⾄ 500 台以下规模的集群的汇总运⾏情况。
⼴泛的开源⽣态: Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。
完善的 SPI 扩展点: Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝。您可以通过实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等
下载地址:https://github.com/alibaba/Sentinel/releases 使用v1.8.1
启动:
java -jar sentinel-dashboard-1.7.1.jar
访问: http://localhost:8080/#/login
⽤户名/密码:sentinel/sentinel
在我们已有的业务场景中,“autodeliver微服务”调⽤了“resume微服务”,我们在⾃动投递微服务进⾏的熔断降级等控制,那么接下来我们改造⾃动投递微服务,引⼊Sentinel核⼼包。
为了不污染之前的代码,复制⼀个微服务 cloud-service-autodeliver-8094-sentinel
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency>
server: port: 8094 spring: application: name: cloud-service-autodeliver cloud: nacos: discovery: server-addr: 192.168.137.144:8848, 192.168.137.144:8849, 192.168.137.144:8850 sentinel: transport: dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址 port: 8719 # sentinel会在该端口启动http server,那么这样的话,控制台定义的一些限流等规则才能发送传递过来, #如果8719端口被占用,那么会依次+1 management: endpoints: web: exposure: include: "*" endpoint: health: show-details: always #针对的被调⽤⽅微服务名称,不加就是全局⽣效 cloud-service-resume: ribbon: #请求连接超时时间 ConnectTimeout: 2000 #请求处理超时时间 ReadTimeout: 15000 #对所有操作都进⾏重试 OkToRetryOnAllOperations: true ####根据如上配置,当访问到故障请求的时候,它会再尝试访问⼀次当前实例(次数由MaxAutoRetries配置), ####如果不⾏,就换⼀个实例进⾏访问,如果还不⾏,再换⼀次实例访问(更换次数由MaxAutoRetriesNextServer配置), ####如果依然不⾏,返回失败信息。 MaxAutoRetries: 0 #对当前选中实例重试次数,不包括第⼀次调⽤ MaxAutoRetriesNextServer: 0 #切换实例的重试次数 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
概念名称 | 概念描述 |
---|---|
资源 | 它可以是 Java 应⽤程序中的任何内容,例如,由应⽤程序提供的服务,或由应⽤程序调⽤的其它应⽤提供的服务,甚⾄可以是⼀段代码。我们请求的API接口就是资源 |
规则 | 围绕资源的实时状态设定的规则,可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。 |
系统并发能⼒有限,⽐如系统A的QPS⽀持1个,如果太多请求过来,那么A就应该进⾏流量控制了,⽐如其他请求直接拒绝
资源名:默认请求路径
针对来源: Sentinel可以针对调⽤者进⾏限流,填写微服务名称,默认default(不区分来源)
阈值类型/单机阈值
QPS:(每秒钟请求数量)当调⽤该资源的QPS达到阈值时进⾏限流
线程数: 当调⽤该资源的线程数达到阈值的时候进⾏限流(线程处理请求的时候,如果说业务逻辑执⾏时间很⻓,流量洪峰来临时,会耗费很多线程资源,这些线程资源会堆积,最终可能造成服务不可⽤,进⼀步上游服务不可⽤,最终可能服务雪崩)
是否集群: 是否集群限流
流控模式:
直接:资源调⽤达到限流条件时,直接限流
关联:关联的资源调⽤达到阈值时候限流⾃⼰
链路:只记录指定链路上的流量
流控效果:
快速失败:直接失败,抛出异常
Warm Up:根据冷加载因⼦(默认3)的值,从阈值/冷加载因⼦,经过预热时⻓,才达到设置的QPS阈值
排队等待:匀速排队,让请求匀速通过,阈值类型必须设置为QPS,否则⽆效
关联的资源调⽤达到阈值时候限流⾃⼰,⽐如⽤户注册接⼝,需要调⽤身份证校验接⼝(往往身份证校验接⼝),如果身份证校验接⼝请求达到阈值,使⽤关联,可以对⽤户注册接⼝进⾏限流。
@RestController @RequestMapping("/user") public class UserController { /** * 用户注册接口 * @return */ @GetMapping("/register") public String register() { SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy/mm/dd HH:MM:ss"); System.out.println(simpleDateFormat.format(new Date()) + " Register success!"); return "Register success!"; } /** * 验证注册身份证接口(需要调用公安户籍资源) * @return */ @GetMapping("/validateID") public String findResumeOpenState() { System.out.println("validateID"); return "ValidateID success!"; } }
链路指的是请求链路(调⽤链)
链路模式下会控制该资源所在的调⽤链路⼊⼝的流量。需要在规则中配置⼊⼝资源,即该调⽤链路⼊⼝的上下⽂名称。
⼀棵典型的调⽤树如下图所示:(阿⾥云提供)
上图中来⾃⼊⼝ Entrance1
和 Entrance2
的请求都调⽤到了资源 NodeA
,Sentinel 允许只根据某个调⽤⼊⼝的统计信息对资源限流。⽐如链路模式下设置⼊⼝资源为 Entrance1
来表示只有从⼊⼝ Entrance1
的调⽤才会记录到 NodeA
的限流统计当中,⽽不关⼼经 Entrance2
到来的调⽤。
当系统⻓期处于空闲的情况下,当流量突然增加时,直接把系统拉升到⾼⽔位可能瞬间把系统压垮,⽐如电商⽹站的秒杀模块。
通过 Warm Up 模式(预热模式),让通过的流量缓慢增加,经过设置的预热时间以后,到达系统处理请求速率的设定值。
Warm Up 模式默认会从设置的 QPS 阈值的 1/3 开始慢慢往上增加⾄ QPS 设置值。
排队等待模式下会严格控制请求通过的间隔时间,即请求会匀速通过,允许部分请求排队等待,通常⽤于消息队列削峰填⾕等场景。需设置具体的超时时间,当计算的等待时间超过超时时间时请求就会被拒绝。
很多流量过来了,并不是直接拒绝请求,⽽是请求进⾏排队,⼀个⼀个匀速通过(处理),请求能等就等着被处理,不能等(等待时间>超时时间)就会被拒绝
例如QPS 配置为 5,则代表请求每 200 ms 才能通过⼀个,多出的请求将排队等待通过。超时时间代表最⼤排队时间,超出最⼤排队时间的请求将会直接被拒绝。排队等待模式下,QPS 设置值不要超过 1000(请求间隔 1 ms)。
日志打印能看到请求一秒会执行一次
流控是对外部来的⼤流量进⾏控制,熔断降级的视⻆是对内部问题进⾏处理。
Sentinel 降级会在调⽤链路中某个资源出现不稳定状态时(例如调⽤超时或异常⽐例升⾼),对这个资源的调⽤进⾏限制,让请求快速失败,避免影响到其它的资源⽽导致级联错误。当资源被降级后,在接下来的降级时间窗⼝之内,对该资源的调⽤都⾃动熔断。
=======>>>> 这⾥的降级其实是Hystrix中的熔断
Hystrix的⼯作流程
在配置最小请求数的时候,配置完成后刷新还是显示为5,通过jmeter测试结果,配置为1时也没有生效
Sentinel不会像Hystrix那样放过⼀个请求尝试⾃我修复,就是明明确确按照时间窗⼝来,熔断触发后,时间窗⼝内拒绝请求,时间窗⼝后就恢复。
当 1s 内持续进⼊ >=5 个请求,平均响应时间超过阈值(以 ms 为单位),那么在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地熔断(抛出 DegradeException)。注意 Sentinel 默认统计的 RT 上限是 4900 ms,超出此阈值的都会算作 4900 ms,若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
验证
controller中添加sleep重启服务
使用jmeter,并发访问
在访问接口时会返回失败
5秒后恢复
当资源的每秒请求量 >= 5,并且每秒异常总数占通过量的⽐值超过阈值之后,资源进⼊降级状态,即在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地返回。异常⽐率的阈值范围是 [0.0, 1.0] ,代表 0% - 100%。
制造异常
按照上面的配置,当一秒钟内请求数超过5并且异常比例大于20%的时候会出现熔断降级,所以当jmeter测试到第6次请求的时候,服务开始熔断
当资源近 1 分钟的异常数⽬超过阈值之后会进⾏熔断。注意由于统计时间窗⼝是分钟级别的,若 timeWindow ⼩于 60s,则结束熔断状态后仍可能再进⼊熔断状态。
时间窗⼝ >= 60s
前3次请求没有被sentinel拦截,第4次开始会触发异常数熔断
官方文档
何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如:
商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
用户 ID 为参数,针对一段时间内频繁访问的用户 ID 进行限制
热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源调用生效。
兜底方法 @SentinelResource注解
测试方法
@GetMapping("/testHotKey") @SentinelResource(value = "testHotKey", blockHandler = "deal_testHotKey") public String testHotKey(@RequestParam(value = "p1", required = false) String p1, @RequestParam(value = "p2", required = false) String p2){ return "------testHotkey"; } public String deal_testHotKey (String p1, String p2, BlockException exception) { return "------deal_testHotKey,o(╥﹏╥)o"; //sentinel系统默认的提示:Blocked by Sentinel (flow limiting) }
配置sentinel热点限流规则
测试
当刷新评率大于一秒一次的时候进入blockHandle方法
如果不配置blockHandler方法, @SentinelResource(value = “testHotKey”) 则默认会跳转到错误页面
参数配置特别说明
参数p1=5的时候,疯狂点击也能正常访问
手动添加异常
官网地址
在开始之前,先回顾一下 Sentinel 做系统自适应保护的目的:
保证系统不被拖垮
在系统稳定的前提下,保持系统的吞吐量
长期以来,系统自适应保护的思路是根据硬指标,即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值,就禁止或者减少流量的进入;当 load 开始好转,则恢复流量的进入。这个思路给我们带来了不可避免的两个问题:
load 是一个“果”,如果根据 load 的情况来调节流量的通过率,那么就始终有延迟性。也就意味着通过率的任何调整,都会过一段时间才能看到效果。当前通过率是使 load 恶化的一个动作,那么也至少要过 1 秒之后才能观测到;同理,如果当前通过率调整是让 load 好转的一个动作,也需要 1 秒之后才能继续调整,这样就浪费了系统的处理能力。所以我们看到的曲线,总是会有抖动。
恢复慢。想象一下这样的一个场景(真实),出现了这样一个问题,下游应用不可靠,导致应用 RT 很高,从而 load 到了一个很高的点。过了一段时间之后下游应用恢复了,应用 RT 也相应减少。这个时候,其实应该大幅度增大流量的通过率;但是由于这个时候 load 仍然很高,通过率的恢复仍然不高。
TCP BBR 的思想给了我们一个很大的启发。我们应该根据系统能够处理的请求,和允许进来的请求,来做平衡,而不是根据一个间接的指标(系统 load)来做限流。最终我们追求的目标是 在系统不被拖垮的情况下,提高系统的吞吐率,而不是 load 一定要到低于某个阈值。如果我们还是按照固有的思维,超过特定的 load 就禁止流量进入,系统 load 恢复就放开流量,这样做的结果是无论我们怎么调参数,调比例,都是按照果来调节因,都无法取得良好的效果。
Sentinel 在系统自适应保护的做法是,用 load1 作为启动控制流量的值,而允许通过的流量由处理请求的能力,即请求的响应时间以及当前系统正在处理的请求速率来决定。系统规则
系统保护规则是从应用级别的入口流量进行控制,从单台机器的总体 Load、RT、入口 QPS 和线程数四个维度监控应用数据,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效。入口流量指的是进入应用的流量(EntryType.IN),比如 Web 服务或 Dubbo 服务端接收的请求,都属于入口流量。
系统规则支持以下的阈值类型:
Load(仅对 Linux/Unix-like 机器生效):当系统 load1 超过阈值,且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。
CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0)。
RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。
线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护
@SentinelResource注解类似于Hystrix中的@HystrixCommand注解
@SentinelResource注解中有两个属性需要我们进⾏区分,blockHandler属性⽤来指定不满⾜Sentinel规则的降级兜底⽅法,fallback属性⽤于指定Java运⾏时异常兜底⽅法
在API接⼝资源处配置
import com.alibaba.csp.sentinel.annotation.SentinelResource; import com.elvis.service.ResumeServiceFeignClient; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cloud.client.ServiceInstance; import org.springframework.cloud.client.discovery.DiscoveryClient; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.client.RestTemplate; import java.util.List; /** * @program: cloud-parent * @Description * @author Elvis * @date 2021-06-19 23:00 */ @RestController @RequestMapping("/autodeliver") public class AutoDeliverController { @Autowired private ResumeServiceFeignClient resumeServiceFeignClient; /** * @SentinelResource value:定义资源名 * blockHandlerClass:指定Sentinel规则异常兜底逻辑所在class类 * blockHandler:指定Sentinel规则异常兜底逻辑具体哪个⽅法 * fallbackClass:指定Java运⾏时异常兜底逻辑所在class类 * fallback:指定Java运⾏时异常兜底逻辑具体哪个⽅法 */ @RequestMapping("/checkState/{userId}") @SentinelResource(value = "findResumeStateById", blockHandlerClass = SentinelHandlersClass.class, blockHandler = "handleException",fallbackClass = SentinelHandlersClass.class,fallback = "handleError") public Integer findResumeStateById(@PathVariable Long userId) { return resumeServiceFeignClient.findResumeStateById(userId); } }
⾃定义兜底逻辑类
注意:兜底类中的⽅法为static静态⽅法
package com.elvis.controller; import com.alibaba.csp.sentinel.slots.block.BlockException; public class SentinelHandlersClass { // 整体要求和当时Hystrix一样,这里还需要在形参中添加BlockException参数,用于接收异常 // 注意:方法是静态的 public static Integer handleException(Long userId, BlockException blockException) { return -100; } public static Integer handleError(Long userId) { return -500; } }
在dashboard配置流控规则
注意:这里要配置@SentinelResource中 value属性作为资源名
测试限流效果
测试异常兜底效果
手动添加异常
⽬前,Sentinel Dashboard中添加的规则数据存储在内存,微服务停掉规则数据就消失,在⽣产环境下不合适。我们可以将Sentinel规则数据持久化到Nacos配置中⼼,让微服务从Nacos获取规则数据。
<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency>
server: port: 8094 spring: application: name: cloud-service-autodeliver cloud: nacos: discovery: server-addr: 192.168.137.144:8848, 192.168.137.144:8849, 192.168.137.144:8850 sentinel: transport: dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址 port: 8719 # sentinel会在该端口启动http server,那么这样的话,控制台定义的一些限流等规则才能发送传递过来, #如果8719端口被占用,那么会依次+1 datasource: flow: nacos: data-id: ${spring.application.name}-flow-rules server-addr: ${spring.cloud.nacos.discovery.server-addr} groudId: DEFAULT_GROUP data-type: json rule-type: flow degrade: nacos: data-id: ${spring.application.name}-degrade-rules server-addr: ${spring.cloud.nacos.discovery.server-addr} groudId: DEFAULT_GROUP data-type: json rule-type: degrade management: endpoints: web: exposure: include: "*" endpoint: health: show-details: always #针对的被调⽤⽅微服务名称,不加就是全局⽣效 cloud-service-resume: ribbon: #请求连接超时时间 ConnectTimeout: 2000 #请求处理超时时间 ReadTimeout: 15000 #对所有操作都进⾏重试 OkToRetryOnAllOperations: true ####根据如上配置,当访问到故障请求的时候,它会再尝试访问⼀次当前实例(次数由MaxAutoRetries配置), ####如果不⾏,就换⼀个实例进⾏访问,如果还不⾏,再换⼀次实例访问(更换次数由MaxAutoRetriesNextServer配置), ####如果依然不⾏,返回失败信息。 MaxAutoRetries: 0 #对当前选中实例重试次数,不包括第⼀次调⽤ MaxAutoRetriesNextServer: 0 #切换实例的重试次数 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
cloud-service-autodeliver-flow-rules
[ { "resource":"findResumeStateById", "limitApp":"default", "grade":1, "count":1, "strategy":0, "controlBehavior":0, "clusterMode":false } ]
resource:资源名称
limitApp:来源应⽤
grade:阈值类型 0 线程数 1 QPS
count:单机阈值
strategy:流控模式,0 直接 1 关联 2 链路
controlBehavior:流控效果,0 快速失败 1 Warm Up 2 排队等待
clusterMode:true/false 是否集群
cloud-service-autodeliver-degrade-rules
[ { "resource":"findResumeStateById", "grade":2, "count":1, "timeWindow":5 } ]
Rule 源码体系结构
⼀个资源可以同时有多个限流规则和降级规则,所以配置集中是⼀个json数组
Sentinel控制台中修改规则,仅是内存中⽣效,不会修改Nacos中的配置值,重启后恢复原来的值; Nacos控制台中修改规则,不仅内存中⽣效,Nacos中持久化规则也⽣效,重启后规则依然保持
改造“autodeliver微服务”和“resume微服务”,删除OpenFeign 和 Ribbon,使⽤DubboRPC 和 Dubbo LB
⾸先,需要删除或者注释掉⽗⼯程中的热部署依赖
<!--<!–热部署–>--> <!--<dependency>--> <!-- <groupId>org.springframework.boot</groupId>--> <!-- <artifactId>spring-boot-devtools</artifactId>--> <!-- <optional>true</optional>--> <!--</dependency>-->
public interface ResumeService { Integer findDefaultResumeById(Long id); }
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-dubbo</artifactId> </dependency> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-apache-dubbo-adapter</artifactId> </dependency> <dependency> <groupId>com.elvis</groupId> <artifactId>cloud-service-dubbo-api</artifactId> <version>1.0-SNAPSHOT</version> </dependency>
import com.elvis.dao.ResumeDao; import com.elvis.pojo.Resume; import com.elvis.service.ResumeService; import org.apache.dubbo.config.annotation.Service; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.domain.Example; /** * @program: cloud-parent * @Description * @author Elvis * @date 2021-06-19 22:19 */ @Service public class ResumeServiceImpl implements ResumeService { @Autowired private ResumeDao resumeDao; @Override public Integer findDefaultResumeById(Long id) { Resume resume = new Resume(); resume.setId(id); resume.setIsDefault(1); Example<Resume> example = Example.of(resume); return resumeDao.findOne(example).get().getIsOpenResume(); } }
dubbo: registry: # 挂载到 Spring Cloud 注册中心 address: spring-cloud://localhost scan: base-packages: com.elvis.service.impl protocol: name: dubbo port: -1
另外增加⼀项配置springboot 2.1.x 后需要加入
5. 运⾏发布之后,会发现Nacos控制台已经有了服务注册信息,从元数据中可以看出,是dubbo注册上来的
接下来改造服务消费者⼯程—>⾃动投递微服务
pom.xml中删除OpenFeign相关内容
application.yml配置⽂件中删除和Feign、Ribbon相关的内容;代码中删除
Feign客户端内容;
pom.xml添加内容和服务提供者⼀样
application.yml配置⽂件中添加dubbo相关内容
dubbo: registry: # 挂载到 Spring Cloud 注册中心 address: spring-cloud://localhost cloud: # 订阅服务提供方的应用列表,订阅多个服务提供者使用 "," 连接 subscribed-services: cloud-service-resume
同样,也配置下spring.main.allow-bean-definition-overriding=true
import com.alibaba.csp.sentinel.annotation.SentinelResource; import com.elvis.service.ResumeService; import org.apache.dubbo.config.annotation.Reference; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cloud.client.ServiceInstance; import org.springframework.cloud.client.discovery.DiscoveryClient; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.client.RestTemplate; import java.util.List; /** * @program: cloud-parent * @Description * @author Elvis * @date 2021-06-19 23:00 */ @RestController @RequestMapping("/autodeliver") public class AutoDeliverController { @Reference private ResumeService resumeService; /** * @SentinelResource value:定义资源名 * blockHandlerClass:指定Sentinel规则异常兜底逻辑所在class类 * blockHandler:指定Sentinel规则异常兜底逻辑具体哪个⽅法 * fallbackClass:指定Java运⾏时异常兜底逻辑所在class类 * fallback:指定Java运⾏时异常兜底逻辑具体哪个⽅法 */ @RequestMapping("/checkState/{userId}") @SentinelResource(value = "findResumeStateById", blockHandlerClass = SentinelHandlersClass.class, blockHandler = "handleException",fallbackClass = SentinelHandlersClass.class,fallback = "handleError") public Integer findResumeStateById(@PathVariable Long userId) { return resumeService.findDefaultResumeById(userId); } }