/**
 * 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 ）

尝试恢复服务调⽤，允许有限的流量调⽤该服务，并监控调⽤成功率。如果成功率达到预

期，则说明服务已恢复，进⼊熔断关闭状态；如果成功率仍旧很低，则重新进⼊熔断关闭状态。

降级机制

降级其实就是为服务提供⼀个兜底⽅案，⼀旦服务⽆法正常调⽤，就使⽤兜底⽅案。

常见的容错组件

Hystrix

Hystrix 是由 Netflflix 开源的⼀个延迟和容错库，⽤于隔离访问远程系统、服务或者第三⽅库，防⽌

级联失败，从⽽提升系统的可⽤性与容错性。

Resilience4J

Resilicence4J ⼀款⾮常轻量、简单，并且⽂档⾮常清晰、丰富的熔断⼯具，这也是 Hystrix 官⽅推

荐的替代产品。不仅如此， Resilicence4j 还原⽣⽀持 Spring Boot 1.x/2.x ，⽽且监控也⽀持和

prometheus 等多款主流产品进⾏整合。

Sentinel

Sentinel 是阿⾥巴巴开源的⼀款断路器实现，本身在阿⾥内部已经被⼤规模采⽤，⾮常稳定。

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 ⽂件中添加如下依赖

<!--sentinel组件-->
<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

安装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 降级的作⽤ .

⽐如我们在购物的时候，查看商品详情⻚⾯的时候，⾥⾯包含库存信息 , 商品详情信息 , 评论信息，这个需求包含的微服务如下 :

假设现在评论服务宕机了 , 那是不是意味⽤户发出查看商品请求也⽆法正常显示了，商品都看不到了，那⽤户也⽆法进⾏下单的操作了 . 但是对于⽤户来说，评论看不到并不影响他购物，所以这时候我们应该对评论服务进⾏及时的熔断降级处理，返回⼀个兜底数据 ( 空数据 ) ，这样⽤户的查看商品请求能正常显示，只是评论数据看不到⽽已，这样的话，⽤户的下单请求也不会受到影响 .

【微服务】服务熔断降级 Sentinel

高并发带来的问题

结论: