21. Spring Cloud Alibaba Sentinel实现熔断和限流

Spring Cloud Alibaba Sentinel实现熔断和限流

简介

官网

Github：https://github.com/alibaba/Sentinel

Sentinel：分布式系统的流量防卫兵，相当于Hystrix

Hystrix存在的问题

• 需要我们自己手工搭建监控平台
• 没有一套web界面可以给我们进行更加细粒度化的配置，流量控制，速率控制，服务熔断，服务降级。

这个时候Sentinel运营而生

• 单独一个组件，可以独立出来
• 直接界面化的细粒度统一配置

约定 > 配置 >编码，都可以写在代码里，但是尽量使用注解和配置代替编码

是什么

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征：

• 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
• 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
• 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

主要特征

生态圈

下载

Github：https://github.com/alibaba/Sentinel/releases/tag/1.7.0

选择sentinel-dashboard-1.7.0.jar

安装Sentinel控制台

sentinel组件由两部分组成，后台和前台8080

Sentinel分为两部分

• 核心库（Java客户端）不依赖任何框架/库，能够运行在所有Java运行时环境，同时对Dubbo、SpringCloud等框架也有较好的支持。
• 控制台（Dashboard）基于SpringBoot开发，打包后可以直接运行，不需要额外的Tomcat等应用容器

控制台先切换到sentinel的所在目录

然后使用 java -jar sentinel-dashboard-1.7.0.jar 启动，Sentinel默认的端口号是8080，不能被占用

用户名、密码都是sentinel，登录成功。

初始化演示工程

创建cloudalibaba-sentinel-service8401

pom

		
		<dependency>
			<groupId>com.alibaba.cspgroupId>
			<artifactId>sentinel-datasource-nacosartifactId>
		dependency>

		
		<dependency>
			<groupId>com.alibaba.cloudgroupId>
			<artifactId>spring-cloud-starter-alibaba-sentinelartifactId>
		dependency>
		
		
		<dependency>
			<groupId>com.alibaba.cloudgroupId>
			<artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
		dependency>

		

		

		

		

yml

server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
    sentinel:
      transport:
        dashboard: localhost:8080 #配置Sentinel dashboard地址
        port: 8719

# 图形化的监控
management:
  endpoints:
    web:
      exposure:
        include: '*'

main

@EnableDiscoveryClient
@SpringBootApplication
public class MainApp8401 {
    public static void main(String[] args) {
        SpringApplication.run(MainApp8401.class, args);
    }
}

controller

@RestController
@Slf4j
public class FlowLimitController
{
    @GetMapping("/testA")
    public String testA()
    {
        return "------testA";
    }

    @GetMapping("/testB")
    public String testB()
    {
        log.info(Thread.currentThread().getName()+"\t"+"...testB");
        return "------testB";
    }
}

测试

启动8401微服务，查看Sentinel控制台

我们会发现Sentinel里面什么也没有，这是因为Sentinel采用的懒加载机制

执行一下准备好的请求：

http://localhost:8401/testA

http://localhost:8401/testB

再回到Sentinel控制台，刷新一下即可查看到信息

流控规则

基本介绍

字段说明

• 资源名：唯一名称，默认请求路径
• 针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）
• 阈值类型 / 单机阈值
  • QPS：（每秒钟的请求数量）：但调用该API的QPS达到阈值的时候，进行限流
  • 线程数：当调用该API的线程数达到阈值的时候，进行限流
• 是否集群：不需要集群
• 流控模式
  • 直接：api都达到限流条件时，直接限流
  • 关联：当关联的资源达到阈值，就限流自己
  • 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【API级别的针对来源】
• 流控效果
  • 快速失败：直接失败，抛异常
  • Warm UP：根据codeFactory（冷加载因子，默认3），从阈值/CodeFactor，经过预热时长，才达到设置的QPS阈值
  • 排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置QPS，否则无效

流控模式

直接（默认）

我们给testA增加流控

QPS

然后我们请求 http://localhost:8401/testA，就会出现失败，被限流，快速失败

思考：

直接调用的是默认报错信息，能否有我们的后续处理，比如更加友好的提示，类似有hystrix的fallback方法

线程数

这里的阈值表示只有一个线程处理业务请求，当突然遇到多个业务请求时，因为只有一个线程工作，所以最多处理一个请求，后续再请求的会直接报错，除非前面的请求处理完了。

例如，下面的代码中，在方法的内部增加了一个睡眠，如果后面一瞬间进来好几个线程的话，因为第一个线程刚进来还没处理完，那后面进来的请求就会失败，也就是说即使进来了也没用，

    @GetMapping("/testA")
    public String testA(){
        try{
            TimeUnit.MILLISECONDS.sleep(800);
        }catch(InterruptedException e){
            e.printStackTrace();
        }
        return "-----testA";
    }

关联

当关联的资源达到阈值时，就限流自己

当与A关联的资源B达到阈值后，就限流A自己，B惹事，A挂了

场景：支付接口达到阈值后，就限流下订单的接口

设置：

当关联资源 /testB的QPS达到阈值，也就是超过1时，就限流/testA的Rest访问地址，当关联资源达到阈值后，限制配置好的资源名

这个使用我们利用postman模拟并发密集访问testB

首先我们需要使用postman，创建一个请求

测试，并将请求保存到集合中

进入运行界面

点击运行，大批量线程高并发访问B

同时我们点击访问

http://localhost:8401/testA，结果发现，A已经挂了，这就是关联限流

链路

多个请求调用了同一个微服务

流控效果

直接

快速失败，默认的流控处理

• 直接失败，抛出异常：Blocked by Sentinel（Flow limiting）

预热

系统最怕的就是出现，平时访问是0，然后突然一瞬间来了10W的QPS

公式：阈值 除以 clodFactor（默认值为3），经过预热时长后，才会达到阈值

Warm Up方式，即预热/冷启动方式，当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能会瞬间把系统压垮。通过冷启动，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值，给冷系统一个预热的时间，避免冷系统被压垮。通常冷启动的过程系统允许的QPS曲线如下图所示

默认coldFactor为3，即请求QPS从（threshold / 3）开始，经过多少预热时长才逐渐升至设定的QPS阈值。
案例：阀值为10+预热时长设置5秒，系统初始化的阀值为10 / 3约等于3，即阀值刚开始为3；然后过了5秒后阀值才慢慢恢复到10

应用场景：

秒杀系统在开启的瞬间，会有很多流量上来，很可能把系统打死，预热的方式就是为了保护系统，可能慢慢的把流量放进来，慢慢的把阈值增长到设置的阈值。

测试

http://localhost:8401/testB，发现前5秒，经常报错，过了5秒之后，系统恢复正常

排队等待

• 匀速排队，让请求以均匀的速度通过，阈值类型必须设置成QPS，否则无效。

• 匀速排队方式必须严格控制请求通过的间隔时间，也即让请求以匀速的速度通过，对应的是漏桶算法。

这种方式主要用于处理间隔性突发的流量，例如消息队列，想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒处于空闲状态，我们系统系统能够接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

设置含义：/testA 每秒1次请求，超过的话，就排队等待，等待时间超过20000毫秒

测试

    @GetMapping("/testB")
    public String testB(){
        log.info(Thread.currentThread().getName()+"...testB");
        return "-----testB";
    }

降级规则

名词介绍

• RT（平均响应时间，秒级）

  • 平均响应时间，超过阈值 且 时间窗口内通过的请求 >= 5，两个条件同时满足后出发降级
  • 窗口期过后，关闭断路器
  • RT最大4900（更大的需要通过 -Dcsp.sentinel.staticstic.max.rt=XXXXX才能生效）

• 异常比例（秒级）

  • QPA >= 5 且异常比例（秒级）超过阈值时，触发降级；时间窗口结束后，关闭降级

• 异常数（分钟级）

  • 异常数（分钟统计）超过阈值时，触发降级，时间窗口结束后，关闭降级

概念

Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。

当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都进行自动熔断（默认行为是抛出DegradeException）

Sentinel的断路器是没有半开状态

半开的状态，系统自动去检测是否请求有异常，没有异常就关闭断路器恢复使用，有异常则继续打开断路器不可用，具体可以参考hystrix

降级策略实战

RT

平均响应时间 (DEGRADE_GRADE_RT)：当 1s 内持续进入 5 个请求，对应时刻的平均响应时间（秒级）均超过阈值（count，以 ms 为单位），那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

测试

    @GetMapping("/testD")
    public String testD(){
        try{
            TimeUnit.SECONDS.sleep(1);
        }catch(InterruptedException e){
            e.printStackTrace();
        }
        log.info("testD 测试RT");
        return "-----testD";
    }

然后使用Jmeter压力测试工具进行测试

左图，我们希望200毫秒内处理完本次任务，如果200毫秒没有处理完，在未来的1秒的时间窗口内，断路器打开，微服务不可用，

右图，1秒钟开启10个线程，一直循环，大于5个了，调用tesetD，

开始测试

在使用jmeter压测期间，我们去请求testD，根本就请求不到

后续我们停止使用jmeter，没有那么大的访问量了，断路器关闭（保险丝恢复），微服务恢复正常

异常比例

异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒请求量 >= 5，，并且每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

测试

    @GetMapping("/testD")
    public String testD() {
        log.info("testD 异常比例");
        int age = 10 / 0;
        return "-----testD";
    }

当资源的每秒请求量 >= 5，这是先决条件，并且3秒内，请求出错的几率大于50%，这是我们设置的条件，那么就会熔断

单独访问一次，必然来一次报错一次，因为没有达到资源的每秒请求量

用jmeter每秒发送10次请求，与RT测试一样

此时调用 localhost:8401/testD 出现服务降级，因为开启jmeter之后，直接高并发发送请求，达到配置条件了，断路器开启，导致微服务不可用。

异常数

异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态

时间窗口一定要大于等于60秒

异常数是按分钟来统计的

测试

    @GetMapping("/testE")
    public String testE() {
        log.info("testE 异常数");
        int age = 10 / 0;
        return "-----testE";
    }

下面设置是，70秒内出现5次异常，触发熔断

首先我们再次访问 http://localhost:8401/testE，第一次访问绝对报错，因为除数不能为0，我们看到error窗口，

接着继续测试，连续报错5次之后，进入熔断后的降级

热点规则

什么是热点数据

Github文档传送门

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

Sentinel 利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。热点参数限流支持集群模式。

兜底的方法

分为系统默认的和客户自定义的，两种，之前的case中，限流出现问题了，都用sentinel系统默认的提示：Blocked By Sentinel，我们能不能自定义，类似于hystrix，某个方法出现问题了，就找到对应的兜底降级方法。

从 @HystrixCommand 到 @SentinelResource

配置

@SentinelResource的value，就是我们的资源名，也就是对哪个方法配置热点规则，通常格式会写成去掉“/”的方法名

@SentinelResource的blockHandler，则指出现异常之后调用哪个方法

    @GetMapping("/testHotKey")
	// 这是标准的配置方式，当然也可以不带后面的blockHandler，那样的话出现一次异常还会调用回调方法，
	// 但是出现多了之后，异常会直接返回到前台，不会按照我们的设置来，所以要配就配全了。
    @SentinelResource(value = "testHotKey",blockHandler = "deal_testHotKey")
    public String testHotKey(@RequestParam(value = "p1", required = false) String p1,
                             @RequestParam(value = "p2", required = false) String p2) {
        //int age = 10 / 0;
        return "-----testHotKey";
    }

    public String deal_testHotKey(String p1, String p2, BlockException exception){
        return "-----deal_testHotKey";
    }

假设我们对参数0，也就是上面的p1，设置热点key进行限流

配置完成后

http://localhost:8401/testHotKey?p1=a

当我们发送多次请求之后，一旦违反了我们设置的热点限流规则，就会调用我们设置好的异常回调

假设我们的请求中没有参数0，而是携带的参数1，http://localhost:8401/testHotKey?p2=a，我们会发现没有问题

参数例外项

上述案例演示了第一个参数p1，当QPS超过1秒1次点击 ，马上被限流

• 普通：超过一秒1个后，达到阈值1后马上被限流
• 我们期望p1参数当它达到某个特殊值时，它的限流值和平时不一样
• 特例：假设当p1的值等于5时，它的阈值可以达到200
• 一句话说：当key为特殊值的时候，不被限制

测试

平时的时候，参数0的阈值是1，超过的时候被限流，但是有特殊值的话，比如参数0的值是5，那么它的阈值就是200

我们通过 http://localhost:8401/testHotKey?p1=5一直刷新，发现不会触发兜底的方法，这就是参数例外项

热点参数的注意点，参数必须是基本类型或者String

结语

@SentinelResource ：处理的是Sentinel控制台配置的违规情况，有blockHandler方法配置的兜底处理

RuntimeException：如 int a = 10/0 ; 这个是java运行时抛出的异常，@RentinelResource不管

    @GetMapping("/testHotKey")
    @SentinelResource(value = "testHotKey",blockHandler = "deal_testHotKey", fallback = "fallBack")
    public String testHotKey(@RequestParam(value = "p1",required = false) String p1,
                             @RequestParam(value = "p2",required = false) String p2)
    {
        //int age = 10/0;
        return "------testHotKey";
    }

系统规则

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是从应用级别的入口流量进行控制，从单台机器的 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 达到阈值即触发系统保护。

这样相当于设置了全局的QPS过滤，所有的请求都会要遵守这个规则，违反的将触发sentinel默认提示。

@SentinelResource注解

public class RateLimitController {
    @GetMapping("/byResource")
    @SentinelResource(value = "byResource", blockHandler = "handleException")
    public CommonResult byResource() {
        return new CommonResult(200, "按资源名称限流测试OK", new Payment(2020L, "serial1001"));
    }

    public CommonResult handleException(BlockException e) {
        return new CommonResult(200, e.getClass().getCanonicalName() + " 服务不可用");
    }

    
    @GetMapping("/rateLimit/byUrl")
    //添加完限流规则之后，不配置blockHandler，访问的多了直接报sentinel的异常
    @SentinelResource(value = "byUrl")
    public CommonResult byUrl() {
        return new CommonResult(200, "按url限流测试OK", new Payment(2020L, "serial1001"));
    }
}

问题

• 系统默认的，没有体现我们自己的业务要求
• 依照现有条件，我们自定义的处理方法又和业务代码耦合在一块，不直观
• 每个业务方法都添加一个兜底方法，那代码膨胀加剧
• 全局统一的处理方法没有体现
• 关闭8401，发现流控规则已经消失，说明这个是没有持久化

客户自定义限流处理逻辑

CustomerBlockHandler.java自定义限流处理逻辑

package com.indi.springcloud.alibaba.myhandler;

public class CustomerBlockHandler {
    public static CommonResult handlerException(BlockException e) {
        return new CommonResult(4444, "按客户自定义, global handler Exception-----1");
    }

    public static CommonResult handlerException2(BlockException e) {
        return new CommonResult(4444, "按客户自定义, global handler Exception-----2");
    }
}

那么我们在使用的时候，就可以首先指定是哪个类，哪个方法

RateLimitController.java

    @GetMapping("/rateLimit/customerBlockHandler")
    //添加完限流规则之后，不配置blockHandler，访问的多了直接报sentinel的异常
    @SentinelResource(value = "customerBlockHandler",
            blockHandlerClass = CustomerBlockHandler.class,
            blockHandler = "handlerException2")
    public CommonResult customerBlockHandler() {
        return new CommonResult(200, "按客户自定义", new Payment(2020L, "serial1001"));
    }

测试

正常情况下，一秒点一次，不报错

请求达到阈值之后，就会调用我们自定义的处理逻辑

更多注解属性说明

所有的代码都要用try - catch - finally 进行处理

sentinel主要有三个核心API

• Sphu定义资源
• Tracer定义统计
• ContextUtil定义了上下文

服务熔断

Ribbon系列

搭建环境

服务提供者

cloudalibaba-provider-payment9003

cloudalibaba-provider-payment9004

参考9001创建即可

服务消费者

cloudalibaba-consumer-nacos-order84

pom

同8401

yml

server:
  port: 84

spring:
  application:
    name: nacos-order-consumer
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 # 配置Nacos地址
    sentinel:
      transport:
        dashboard: localhost:8080
        # 默认8719端口，假如被占用会自动从8719开始依次+1扫描，直至找到未被占用的接口
        port: 8719

# 消费者将要去访问的微服务名称（注册成功进nacos的微服务提供者）
service-url:
  nacos-user-service: http://nacos-payment-provider

main

同8401

config

/**
 * 实现负载均衡
 */
@Configuration
public class ApplicationContextConfig {
    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(){
        return new RestTemplate();
    }
}

测试

以下测试均在84消费端测试，只修改注解的话，如果项目里面有热更新的功能，最好改完之后手动重启，热更新在注解这方面不是很好用。

CircleBreakerController.java

不设置任何参数

当我们只使用 @SentinelResource注解时，不添加任何参数，如果出错的话，是直接返回一个error页面，对前端用户非常不友好，因此我们需要配置一个出错之后的回调方法

@RestController
@Slf4j
public class CircleBreakerController{
	public static final String SERVICE_URL = "http://nacos-payment-provider";
	
	@Resource
	private RestTemplate restTemplate;
	
	@GetMapping("/consumer/fallback/{id}")
	@SentinelResource(value = "fallback")
	public CommonResult<Payment> fallback(@PathVariable("id") Long id){
		CommonResult result = restTemplate.getForObject(SERVICE_URL + "/paymentSQL/" + id , CommonResult.class, id);
		if(id == 4){
			throw new IllegalArgumentException("IllegalArgumentException：参数错误");
		}else if(result.getData() == null){
			throw new NullPointerException("NullPointerException：查询此id无信息，空指针异常");
		}
		return result;
	}
}

参数1、2、3都很正常

4、5则直接返回Error页面

只配置fallback

	public CommonResult handlerFallback(@PathVariable("id") Long id, Throwable e){
		Payment payment = new Payment(id,"null");
		return new CommonResult(444,"fallback的异常回调："+e.getMessage(),payment);
	}

加入fallback后，当我们程序运行出错时，会调用我们的回调方法handlerFallback()，不会直接返回Error页面

只配置blockHandler

	public CommonResult blockHandler(@PathVariable("id") Long id, BlockException e){
		Payment payment = new Payment(id,"null");
		return new CommonResult(445,"blockHandler异常回调，查无此流水"+e.getMessage() , payment);
	}

请求一次的时候直接走fallback()，返回Error页面

而访问的多了之后，违反了设置好的降级规则，则会调用blockHandler()回调

blockHandler和fallback一起配置

同时配置之后，我们测试参数4，发现1秒1秒的测，会调用我们设置好的handlerFallback()回调

一旦请求的多了之后，违反了流控规则，则会触发blockHandler()回调

异常忽略

添加了这个选项之后，一旦遇到该异常，则不再调用我们写好的handlerFallback()回调，而是直接返回Error页面，sentinel规则不受影响。

Feign系列

修改cloudalibaba-consumer-nacos-order84

pom

引入Feign

		
		<dependency>
			<groupId>org.springframework.cloudgroupId>
			<artifactId>spring-cloud-starter-openfeignartifactId>
		dependency>

yml

main

service

PaymentService.java

@FeignClient(value = "nacos-payment-provider" , fallback = PaymentFallbackService.class)
public interface PaymentService{
	@GetMapping("/paymentSQL/{id}")
	CommonResult<Payment> paymentSQL(@PathVariable("id") Long id);
}

PaymentFallbackService.java

@Component
public class PaymentFallbackService implements PaymentService{
	@Override
	public CommonResult<Payment> paymentSQL(Long id){
		return new CommonResult<>(44444, "服务降级返回-----PaymentFallbackService", new Payment(id,"errorInfo"));
	}
}

controller

CircleBreakerController.java

	@Resource
	private PaymentService paymentService;
	
	@GetMapping("/consumer/paymentSQL/{id}")
	public CommonResult<Payment> paymentSQL(@PathVariable("id") Long id){
		return paymentService.paymentSQL(id);
	}

测试

启动9003、84

请求接口：http://localhost:84/consumer/paymentSQL/1

正常请求没问题

故意关闭9003微服务提供者，84消费者则会触发PaymentFallbackService.java的回调

熔断框架对比

Sentinel规则持久化

简介

一旦我们重启应用，sentinel规则将会消失，生产环境需要将规则进行持久化

原理

将限流配置规则持久化进Nacos保存，只要刷新8401某个rest地址，sentinel控制台的流控规则就能看到，只要Nacos里面的配置不删除，针对8401上的流控规则一直有效

解决方法

使用nacos持久化保存

修改cloudalibaba-sentinel-service8401

pom

    
    <dependency>
        <groupId>com.alibaba.cspgroupId>
        <artifactId>sentinel-datasource-nacosartifactId>
    dependency>

yml

server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
    sentinel:
      transport:
        dashboard: localhost:8080 #配置Sentinel dashboard地址
        port: 8719
      datasource:
        ds1:
          nacos:
            server-addr: localhost:8848
            dataId: cloudalibaba-sentinel-service
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow

management:
  endpoints:
    web:
      exposure:
        include: '*'

feign:
  sentinel:
    enabled: true # 激活Sentinel对Feign的支持

添加nacos配置

[
    {
         "resource": "/rateLimit/byUrl",
         "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，2表示排队等待
clusterMode	是否集群

测试

启动8401，先请求一次

访问sentinel控制台，发现流控规则已经添加进来了，成功！

快速访问测试接口，触发流控规则，成功！

停止8401再看sentinel，发现流控规则已经没有了

重新启动8401，再访问一次测试接口，发现又出来了

再次测试请求，发现规则依旧生效