【微服务】服务熔断降级 Sentinel
目录
高并发带来的问题
结论:
服务器雪崩效应
常见容错方案
隔离机制:
超时机制
限流机制
熔断机制:
降级机制
常见的容错组件
Sentinel入门
什么是Sentinel
订单微服务集成Sentinel
安装Sentinel控制台
实现⼀个接口的限流
Sentinel容错的维度
Sentinel规则种类
编辑
Sentinel规则-流控
流控规则
QPS流控
线程数流控
流控模式
直接流控模式
关联流控模式
链路流控模式
流控效果
Sentinel规则-降级
慢调用比例案例
异常比例案例
异常数案例
Sentinel规则-热点
Sentinel规则-授权
Sentinel规则-系统规则
Sentinel ⾃定义异常返回
@SentinelResource的使用
Feign整合Sentinel
高并发带来的问题
在微服务架构中，我们将业务拆分成⼀个个的服务，服务与服务之间可以相互调⽤，但是由于⽹络原因或者⾃身的原因，服务并不能保证服务的 100% 可⽤，如果单个服务出现问题，调⽤这个服务就会 出现⽹络延迟，此时若有⼤量的⽹络涌⼊，会形成任务堆积，最终导致服务瘫痪。
接下来，我们来模拟一个高并发的场景
1. 在订单服务中新建 SentinelController.java
/**
* Created by mxin5
* 验证高并发
*/
@RestController
public class SentinelController {
@RequestMapping("/sentinel1")
public String sentinel1(){
//模拟一次网络延时
try {
//进行休眠
TimeUnit.SECONDS.sleep(3);
System.out.println("sentinel1开始执行");
} catch (InterruptedException e) {
e.printStackTrace();
}
return "sentinel1";
}
@RequestMapping("/sentinel2")
public String sentinel2(){
System.out.println("sentinel2开始执行");
return "测试高并发下的问题";
}
@RequestMapping("/sentinel3")
public String sentinel3(){
return "sentinel3";
}
}
2. 修改配置⽂件中 tomcat 的并发数
server:
port: 8091 #商品订单的端口号
tomcat:
threads:
max: 10 #tomcat的最大并发值10，正常是200多个，测试高并发,就需要sentinel进行限流 3. 接下来使⽤压测⼯具 , 对请求进⾏压⼒测试
下载地址 https://jmeter.apache.org/
第⼀步：修改配置，并启动软件 进⼊bin ⽬录 , 修改 jmeter.properties ⽂件中的语⾔⽀持为 language=zh_CN
然后点击jmeter.bat,启动软件。
第⼆步：添加线程组
第三步：配置线程并发数
第四步：添加Http请求
第五步：配置取样，并启动测试
第六步：访问 http://localhost:8091/sentinel2 观察结果,会出现转圈等待的效果。
结论:
此时会发现 , 由于 sentinel1 能够承受的并发数为10个，而jmeter压测的时候50个线程同事访问sentinel1导致囤积了⼤量请求 , 从而在访问sentinel2的时候，没有线程进行处理 sentinel2 的访问，这就 是服务雪崩的雏形。
服务器雪崩效应
在分布式系统中 , 由于⽹络原因或⾃身的原因 , 服务⼀般⽆法保证 100% 可⽤。如果⼀个服务出现
了问题，调⽤这个服务就会出现线程阻塞的情况，此时若有⼤量的请求涌⼊，就会出现多条线程阻塞 等 待，进⽽导致服务瘫痪。
由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就
是服务故障的 “ 雪崩效应 ” 。
情景 1: 微服务之间相互调⽤ , 关系复杂 , 正常情况如下图所示 :
情景2：某个时刻，服务A挂了，服务B和服务C依然在调⽤服务A
情景3:由于服务A挂了,导致服务C和服务B⽆法得到服务A的响应,这时候服务C和服务B由于⼤量线程积压,最终导致服务C和服务B挂掉.
情景4: 相同道理,由于服务之间有关联，所以会导致整个调⽤链上的所有服务都挂掉.
服务器的雪崩效应其实就是由于某个微⼩的服务挂了,导致整⼀⼤⽚的服务都不可⽤.类似⽣活中的雪崩效应,由于落下的最后⼀⽚雪花引发了雪崩的情况. 雪崩发⽣的原因多种多样，有不合理的容量设计，或者是⾼并发下某⼀个⽅法响应变慢，亦或某 台机器的资源耗尽。我们⽆法完全杜绝雪崩源头的发⽣，只有做好⾜够的容错，保证在⼀个服务发⽣问题，不会影响到其它服务的正常运⾏。
常见容错方案
要防⽌雪崩的扩散，我们就要做好服务的容错，容错说⽩了就是保护⾃⼰不被猪队友拖垮的⼀些措
施 , 下⾯介绍常⻅的服务容错思路和组件。
常见的容错思路
常⻅的容错思路有隔离、超时、限流、熔断、降级这⼏种，下⾯分别介绍⼀下。
隔离机制:
⽐如服务 A 内总共有 100 个线程 , 现在服务 A 可能会调⽤服务 B, 服务 C, 服务 D. 我们在服务 A
进⾏远程调⽤的时候 , 给不同的服务分配固定的线程 , 不会把所有线程都分配给某个微服务 . ⽐如调⽤
服务 B 分配 30 个线程 , 调⽤服务 C 分配 30 个线程，调⽤服务 D 分配 40 个线程 . 这样进⾏资源的隔离，保证即使下游某个服务挂了，也不⾄于把服务 A 的线程消耗完。⽐如服务 B 挂了，这时候最多只会占⽤ 服务 A 的 30 个线程 , 服务 A 还有 70 个线程可以调⽤服务 C 和服务 D
超时机制
在上游服务调⽤下游服务的时候，设置⼀个最⼤响应时间，如果超过这个时间，下游未
作出反应，就断开请求，释放掉线程。
限流机制
限流就是限制系统的输⼊和输出流量已达到保护系统的⽬的。为了保证系统的稳固运⾏ ,
⼀旦达到的需要限制的阈值 , 就需要限制流量并采取少量措施以完成限制流量的⽬的。
熔断机制:
在互联⽹系统中，当下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护系
统整体的可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施就叫做熔断。
服务熔断⼀般有三种状态：
熔断关闭状态（ Closed ）
服务没有故障时，熔断器所处的状态，对调⽤⽅的调⽤不做任何限制
熔断开启状态（ Open ）
后续对该服务接⼝的调⽤不再经过⽹络，直接执⾏本地的 fallback ⽅法
半熔断状态（ Half-Open ）
尝试恢复服务调⽤，允许有限的流量调⽤该服务，并监控调⽤成功率。如果成功率达到预
期，则说明服务已恢复，进⼊熔断关闭状态；如果成功率仍旧很低，则重新进⼊熔断关闭状态。
降级机制
降级其实就是为服务提供⼀个兜底⽅案，⼀旦服务⽆法正常调⽤，就使⽤兜底⽅案。
常见的容错组件
HystrixHystrix 是由 Netflflix 开源的⼀个延迟和容错库，⽤于隔离访问远程系统、服务或者第三⽅库，防⽌级联失败，从⽽提升系统的可⽤性与容错性。Resilience4JResilicence4J ⼀款⾮常轻量、简单，并且⽂档⾮常清晰、丰富的熔断⼯具，这也是 Hystrix 官⽅推荐的替代产品。不仅如此， Resilicence4j 还原⽣⽀持 Spring Boot 1.x/2.x ，⽽且监控也⽀持和prometheus 等多款主流产品进⾏整合。SentinelSentinel 是阿⾥巴巴开源的⼀款断路器实现，本身在阿⾥内部已经被⼤规模采⽤，⾮常稳定。
Sentinel入门
什么是Sentinel
Sentinel ( 分布式系统的流量防卫兵 ) 是阿⾥开源的⼀套⽤于 服务容错 的综合性解决⽅案。它以流量
为切⼊点 , 从 流量控制、熔断降级、系统负载保护 等多个维度来保护服务的稳定性
Sentinel 具有以下特征 :
丰富的应⽤场景 ： Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景 , 例如秒杀（即
突发流量控制在系统容量可以承受的范围）、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤
应⽤等。
完备的实时监控 ： Sentinel 提供了实时的监控功能。通过控制台可以看到接⼊应⽤的单台机器秒
级数据 , 甚⾄ 500 台以下规模的集群的汇总运⾏情况。
⼴泛的开源⽣态 ： Sentinel 提供开箱即⽤的与其它开源框架 / 库的整合模块 , 例如与 SpringCloud 、 Dubbo 、 gRPC 的整合。只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊Sentinel 。
Sentinel 分为两个部分 :
核⼼库（ Java 客户端）不依赖任何框架 / 库 , 能够运⾏于所有 Java 运⾏时环境，同时对 Dubbo /
Spring Cloud 等框架也有较好的⽀持。
控制台（ Dashboard ）基于 Spring Boot 开发，打包后可以直接运⾏，不需要额外的 Tomcat 等
应⽤容器。
订单微服务集成Sentinel
为微服务集成 Sentinel ⾮常简单 , 只需要加⼊ Sentinel 的依赖即可
在 shop-order-server 项⽬的 pom ⽂件中添加如下依赖
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
安装Sentinel控制台
Sentinel 提供⼀个轻量级的控制台 , 它提供机器发现、单机资源实时监控以及规则管理等功能。
1. 下载 jar 包 https://github.com/alibaba/Sentinel/releases
2. 启动控制台
# 直接使⽤ jar 命令启动项⽬ ( 控制台本身是⼀个 SpringBoot 项⽬ )java -Dserver .port = 8080 -Dcsp .sentinel.dashboard .server = localhost:8080 -Dproject .name = sentinel-dashboard -jar sentinel-dashboard-1.8.0.jar
或者直接创建一个快捷打开方式sentinelStart.bat文件
3. 修改shop-order-server项⽬中的配置⽂件application.yml,新增如下配置:
spring:
cloud:
sentinel:
transport:
port: 9999 #跟控制台交流的端口,随意指定一个未使用的端口即可
dashboard: localhost:1111 # 指定控制台服务的地址
4. 通过浏览器访问 localhost:8080 进⼊控制台 ( 默认⽤户名密码是 sentinel/sentinel )
注意 : 默认是没显示 order-service 的，需要访问几次接⼝，然后再刷新 sentinel 管控台才可以看到 .
实现⼀个接口的限流
第⼀步: 簇点链路--->流控
第⼆步: 在单机阈值填写⼀个数值，表示每秒上限的请求数
第三步:通过控制台快速频繁访问, 观察效果
Sentinel容错的维度
流量控制 ：流量控制在⽹络传输中是⼀个常⽤的概念，它⽤于调整⽹络包的数据。任意时间到来的请求
往往是
随机不可控的，⽽系统的处理能⼒是有限的。我们需要根据系统的处理能⼒对流量进⾏控制。
熔断降级 ：当检测到调⽤链路中某个资源出现不稳定的表现，例如请求响应时间⻓或异常⽐例升⾼的时
候，则
对这个资源的调⽤进⾏限制，让请求快速失败，避免影响到其它的资源⽽导致级联故障。
系统负载保护 ： Sentinel 同时提供系统维度的⾃适应保护能⼒。当系统负载较⾼的时候，如果还持续让
请求进⼊可能会导致系统崩溃，⽆法响应。在集群环境下，会把本应这台机器承载的流量转发到其
它的机器上去。如果这个时候其它的机器也处在⼀个边缘状态的时候， Sentinel 提供了对应的保
护机制，让系统的⼊⼝流量和系统的负载达到⼀个平衡，保证系统在能⼒范围之内处理最多的请
求。
Sentinel规则种类
Sentinel主要提供了这五种的流量控制
Sentinel规则-流控
流控规则
流量控制，其原理是监控应⽤流量的 QPS( 每秒查询率 ) 或并发线程数等指标，当达到指定的阈值时
对流量进⾏控制，以避免被瞬时的流量⾼峰冲垮，从⽽保障应⽤的⾼可⽤性。
资源名 ：唯⼀名称，默认是请求路径，可⾃定义
针对来源 ：指定对哪个微服务进⾏限流，默认指 default ，意思是不区分来源，全部限制
阈值类型 / 单机阈值 ：
QPS （每秒请求数量） : 当调⽤该接⼝的 QPS 达到阈值的时候，进⾏限流
线程数：当调⽤该接⼝的线程数达到阈值的时候，进⾏限流
是否集群 ：暂不需要集群
QPS流控
前⾯Sentinel 案例就是演示的 QPS 流控
线程数流控
1. 删除掉之前的 QPS 流控，新增线程数流控
2. 在Jmeter中新增线程
3. 访问 http://localhost:8091/sentinel2 会发现已经被限流
流控模式
点击上⾯设置流控规则的编辑按钮，然后在编辑⻚⾯点击⾼级选项，会看到有流控模式⼀栏。
sentinel 共有三种流控模式，分别是：直接（默认）：接⼝达到限流条件时，开启限流关联：当关联的资源达到限流条件时，开启限流 [ 适合做应⽤让步 ]链路：当从某个接⼝过来的资源达到限流条件时，开启限流
直接流控模式
前⾯演示的案例就是这种 .
关联流控模式
关联流控模式指的是，当指定接⼝关联的接⼝达到限流条件时，开启对指定接⼝开启限流。
场景 : 当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。⽐如对数据库同⼀
个字段的读操作和写操作存在争抢，读的速度过⾼会影响写得速度，写的速度过⾼会影响读的速度。如
果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使⽤关联限流来避免具有关
联关系的资源之间过度的争抢 .
1. 在 SentinelController.java 中增加⼀个⽅法，重启订单服务
@RequestMapping("/sentinel3")
public String sentinel3(){
return "sentinel3";
} 2. 配置限流规则 , 将流控模式设置为关联，关联资源设置为的 /sentinel2
3. 通过postman软件向/sentinel2连续发送请求，注意QPS⼀定要⼤于3
4. 访问/sentinel3,会发现已经被限流
链路流控模式
链路流控模式指的是，当从某个接⼝过来的资源达到限流条件时，开启限流。
1. 在 shop-order-server 项⽬的 application.yml ⽂件中新增如下配置 :
spring :cloud :sentinel :web-context-unify : false
2. 在 shop-order-server 项⽬中新增 TraceServiceImpl.java
@Service
@Slf4j
public class TraceServiceImpl {
@SentinelResource(value = "tranceService")
public void tranceService(){
log.info("调⽤tranceService⽅法");
}
} 3. 在 shop-order-server 项⽬中新增 TraceController.java
@RestController
public class TraceController {
@Autowired
private TraceServiceImpl traceService;
@RequestMapping("/trace1")
public String trace1(){
traceService.tranceService();
return "trace1";
}
@RequestMapping("/trace2")
public String trace2(){
traceService.tranceService();
return "trace2";
}
} 4. 重新启动订单服务并添加链路流控规则
5. 分别通过 /trace1 和 /trace2 访问, 发现/trace1没问题, /trace2的被限流了
流控效果
快速失败（默认） : 直接失败，抛出异常，不做任何额外的处理，是最简单的效果
Warm Up ：它从开始阈值到最⼤ QPS 阈值会有⼀个缓冲阶段，⼀开始的阈值是最⼤ QPS 阈值的
1/3 ，然后慢慢增⻓，直到最⼤阈值，适⽤于将突然增⼤的流量转换为缓步增⻓的场景。
排队等待 ：让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待； 它还会让设
置⼀个超时时间，当请求超过超时间时间还未处理，则会被丢弃。
Sentinel规则-降级
降级规则就是设置当满⾜什么条件的时候，对服务进⾏降级。 Sentinel 提供了三个衡量条件：
慢调⽤⽐例 : 选择以慢调⽤⽐例作为阈值，需要设置允许的慢调⽤ RT （即最⼤的响应时间），请求的响应时间⼤于该值则统计为慢调⽤。当单位统计时⻓内请求数⽬⼤于设置的最⼩请求数⽬，并且 慢调⽤的⽐例⼤于阈值，则接下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊ 探测恢复状态（ HALF-OPEN 状态），若接下来的⼀个请求响应时间⼩于设置的慢调⽤ RT 则结束熔断，若⼤于设置的慢调⽤ RT 则会再次被熔断。
异常⽐例 : 当单位统计时⻓内请求数⽬⼤于设置的最⼩请求数⽬，并且异常的⽐例⼤于阈值，则接
下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（ HALF-OPEN
状态），若接下来的⼀个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常⽐率的
阈值范围是 [0.0, 1.0] ，代表 0% - 100% 。
异常数 ：当单位统计时⻓内的异常数⽬超过阈值之后会⾃动进⾏熔断。经过熔断时⻓后熔断器会进
⼊探测恢复状态（ HALF-OPEN 状态），若接下来的⼀个请求成功完成（没有错误）则结束熔断，
否则会再次被熔断。
慢调用比例案例
1. 在 shop-order-server 项⽬中新增 FallBackController.java 类 , 代码如下 :
@RestController
@Slf4j
public class FallBackController {
@RequestMapping("/fallBack1")
public String fallBack1(){
try {
log.info("fallBack1执行业务逻辑");
//模拟业务耗时
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "fallBack1";
}
} 2. 新增降级规则 :
上⾯配置表示，如果在 1S 之内 , 有【超过 1 个的请求】且这些请求中【响应时间 > 最⼤ RT 】的【请求
数量⽐例 >10% 】，就会触发熔断，在接下来的 10s 之内都不会调⽤真实⽅法，直接⾛降级⽅法。
⽐如: 最⼤RT=900,⽐例阈值=0.1,熔断时⻓=10,最⼩请求数=10
情况 1: 1 秒内的有 20 个请求，只有 10 个请求响应时间 >900ms, 那慢调⽤⽐例 =0.5 ，这种情况就会触发熔断情况 2: 1 秒内的有 20 个请求，只有 1 个请求响应时间 >900ms, 那慢调⽤⽐例 =0.05 ，这种情况不会触发熔断情况 3: 1 秒内的有 8 个请求，只有 6 个请求响应时间 >900ms, 那慢调⽤⽐例 =0.75 ，这种情况不会触发熔断，因为最⼩请求数这个条件没有满⾜ .
注意 : 我们做实验的时候把最⼩请求数设置为 1 ，因为在 1 秒内，⼿动操作很难在 1s 内发两个请求过
去，所以要做出效果 , 最好把最⼩请求数设置为 1 。
异常比例案例
1. 在 shop-order-server 项⽬的 FallBackController.java 类新增 fallBack2 ⽅法 :
int i=0;
@RequestMapping("/fallBack2")
public String fallBack2(){
log.info("fallBack2执行业务逻辑");
//模拟出现异常，异常比例为33%
if(++i%3==0){
throw new RuntimeException();
}
return "fallBack2";
} 2. 新增降级规则 :
上⾯配置表示，在 1s 之内， , 有【超过 3 个的请求】，异常⽐例 30% 的情况下，触发熔断，熔断时⻓
为 10s.
异常数案例
1. 在 shop-order-server 项⽬的 FallBackController.java 类新增 fallBack3 ⽅法 :
@RequestMapping("/fallBack3")
public String fallBack3(String name){
log.info("fallBack3执行业务逻辑");
//模拟出现异常，异常比例为33%
if("wolfcode".equals(name)){
throw new RuntimeException();
}
return "fallBack3";
} 2. 新增降级规则
上⾯配置表示，在 1s 之内， , 有【超过 3 个的请求】，请求中超过 2 个请求出现异常就会触发熔断，
熔断时⻓为 10s
Sentinel规则-热点
何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最⾼的 Top K 数
据，并对其访问进⾏限制。⽐如：
商品 ID 为参数，统计⼀段时间内最常购买的商品 ID 并进⾏限制
⽤户 ID 为参数，针对⼀段时间内频繁访问的⽤户 ID 进⾏限制
热点参数限流会统计传⼊参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调
⽤进⾏限流。热点参数限流可以看做是⼀种特殊的流量控制，仅对包含热点参数的资源调⽤⽣效。
1. 在 shop-order-server 项⽬中新增 HotSpotController.java, 代码如下 :
@RestController
@Slf4j
public class HotSpotController {
@RequestMapping("/hotSpot1")
@SentinelResource(value = "hotSpot1")
public String hotSpot1(Long productId){
log.info("访问编号为:{}的商品",productId);
return "hotSpot1";
}
} 注意 : ⼀定需要在请求⽅法上贴 @SentinelResource 直接，否则热点规则⽆效
2. 新增热点规则 :
3. 在热点规则中编辑规则,在编辑之前⼀定要先访问⼀下/hotSpot1,不然参数规则⽆法新增.
4. 新增参数规则:
5. 点击保存，可以看到已经新增了参数规则
6. 访问 http://localhost:8091/hotSpot?productId=1 访问会降级
访问 http://localhost:8091/hotSpot?productId=2 访问不会降级
Sentinel规则-授权
很多时候，我们需要根据调⽤来源来判断该次请求是否允许放⾏，这时候可以使⽤ Sentinel 的来源访问控制（⿊⽩名单控制）的功能。来源访问控制根据资源的请求来源（ origin ）限制资源是否通过，若配置⽩名单则只有请求来源位于⽩名单内时才可通过；若配置⿊名单则请求来源位于⿊名单时不通过，其余的请求通过。
1. 在 shop-order-server 中新建 RequestOriginParserDefinition.java, 定义请求来源如何获取
@Component
public class RequestOriginParserDefinition implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest request) {
/**
* 定义从请求的什么地方获取来源信息
* 比如我们可以要求所有的客户端需要在请求头中携带来源信息
*/
String serviceName = request.getParameter("serviceName");
return serviceName;
}
} 2. 在 shop-order-server 中新建 AuthController.java, 代码如下 :
@RestController
@Slf4j
public class AuthController {
@RequestMapping("/auth1")
public String auth1(String serviceName){
log.info("应用:{},访问接口",serviceName);
return "auth1";
}
} 3. 新增授权规则
4. 访问测试
访问 http://localhost:8091/auth1?serviceName=pc 不能访问
访问 http://localhost:8091/auth1?serviceName=app 可以访问
Sentinel规则-系统规则
系统保护规则是从应⽤级别的⼊⼝流量进⾏控制，从单台机器的 load 、 CPU 使⽤率、平均 RT 、⼊⼝
QPS 和并发线程数等⼏个维度监控应⽤指标，让系统尽可能跑在最⼤吞吐量的同时保证系统整体的稳定
性。
系统保护规则是应⽤整体维度的，⽽不是资源维度的，并且 仅对⼊⼝流量⽣效 。⼊⼝流量指的是进⼊应
⽤的流量（ EntryType.IN ），⽐如 Web 服务或 Dubbo 服务端接收的请求，都属于⼊⼝流量。
系统规则⽀持以下的模式：
Load ⾃适应 （仅对 Linux/Unix-like 机器⽣效）：系统的 load1 作为启发指标，进⾏⾃适应系统保
护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系
统保护（ BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值⼀般是 CPU
cores * 2.5 。
CPU usage （ 1.5.0+ 版本）：当系统 CPU 使⽤率超过阈值即触发系统保护（取值范围 0.0-1.0 ），
⽐较灵敏。
平均 RT ：当单台机器上所有⼊⼝流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
并发线程数 ：当单台机器上所有⼊⼝流量的并发线程数达到阈值即触发系统保护。
⼊⼝ QPS ：当单台机器上所有⼊⼝流量的 QPS 达到阈值即触发系统保护。
Sentinel 自定义异常返回
当前⾯设定的规则没有满⾜是，我们可以⾃定义异常返回 .
- FlowException 限流异常
- DegradeException 降级异常
- ParamFlowException 参数限流异常
- AuthorityException 授权异常
- SystemBlockException 系统负载异常
在 shop-order-server 项⽬中定义异常返回处理类
@Component
public class ExceptionHandlerPage implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
response.setContentType("application/json;charset=utf-8");
ResultData data = null;
if (e instanceof FlowException) {
data = new ResultData(-1, "接口被限流了");
} else if (e instanceof DegradeException) {
data = new ResultData(-2, "接口被降级了");
}else if (e instanceof ParamFlowException) {
data = new ResultData(-3, "参数限流异常");
}else if (e instanceof AuthorityException) {
data = new ResultData(-4, "授权异常");
}else if (e instanceof SystemBlockException) {
data = new ResultData(-5, "接口被降级了...");
}
response.getWriter().write(JSON.toJSONString(data));
}
}
@Data
@AllArgsConstructor//全参构造
@NoArgsConstructor//无参构造
class ResultData {
private int code;
private String message;
}@SentinelResource的使用
在定义了资源点之后，我们可以通过 Dashboard 来设置限流和降级策略来对资源点进⾏保护。同时还能
通过 @SentinelResource 来指定出现异常时的处理策略。
@SentinelResource ⽤于定义资源，并提供可选的异常处理和 fallback 配置项。
其主要参数如下 :
定义限流和降级后的处理方法
直接将限流和降级⽅法定义在⽅法中
@RestController
@Slf4j
public class AnnoController {
@RequestMapping("/anno1")
@SentinelResource(value = "anno1",
blockHandler="anno1BlockHandler",
blockHandlerClass = AnnoControllerBlockHandlerClass.class,
fallback = "anno1Fallback"
)
public String anno1(String name){
if("wolfcode".equals(name)){
throw new RuntimeException();
}
return "anno1";
}
public String anno1BlockHandler(String name,BlockException ex) throws BlockException {
log.error("{}", ex);
return "接口被限流或者降级了";
}
//Throwable时进入的方法
public String anno1Fallback(String name,Throwable throwable) {
log.error("{}", throwable);
return "接口发生异常了";
}
}Feign整合Sentinel
1. 在shop-order-server项⽬的配置⽂件中开启feign对Sentinel的⽀持
feign:
sentinel:
enabled: true 2. 创建容错类
@Component
public class ProductFeignFallBack implements ProductFeignApi {
@Override
public Product findByPid(Long pid) {
Product product = new Product();
product.setPid(-1L);
product.setPname("服务调用失败返回的兜底数据");
product.setPprice(0.0);
return product;
}
} 3. 在 feign 接⼝中定义容错类
@FeignClient(name = "product-service", fallback = ProductFeignFallBack.class)
public interface ProductFeignApi {
//跟product-sever中的controller的接口一致
@RequestMapping("/product/{pid}")
public Product findByPid(@PathVariable("pid") Long pid);
} 4. 停⽌所有 商品服务 , 重启 shop-order 服务 , 访问请求 , 观察容错效果
可能上⾯的案例并不是特别恰当，我们只是通过案例来演示 Feign 集成 Sentinel 实现降级的效果 . 接下来我们具体更贴切的案例来讲解 Feign 降级的作⽤ .
⽐如我们在购物的时候，查看商品详情⻚⾯的时候，⾥⾯包含库存信息 , 商品详情信息 , 评论信息，这个需求包含的微服务如下 :
假设现在评论服务宕机了 , 那是不是意味⽤户发出查看商品请求也⽆法正常显示了，商品都看不到了，那⽤户也⽆法进⾏下单的操作了 . 但是对于⽤户来说，评论看不到并不影响他购物，所以这时候我们应该对 评论服务进⾏及时的熔断 降级处理，返回⼀个兜底数据 ( 空数据 ) ，这样⽤户的查看商品请求能正常显示，只是评 论数据看不到⽽已，这样的话，⽤户的下单请求也不会受到影响 .