SpringCloud学习笔记(十)----服务熔断与限流 Sentinel

SpringCloud Alibaba Sentinel实现熔断与限流

Sentinel概述

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

Sentinel下载地址

安装Sentinel控制台

Sentinel组件由俩部分组成：后台和前台8080。

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

下载到本地sentinel-dashboard-1.7.0.jar

运行命令：

• 前提：java8环境OK，8080端口不能被占用。
• 命令：java -jar sentinel-dashboard-1.7.0.jar

访问sentinel管理界面:

• http://localhost:8080
• 账号密码均为sentinel

微服务整合sentinel

1.启动Nacos
2.新建cloudalibaba-sentinel-service8401 Module
2.1 POM.xml

<dependencies>
        <dependency>
            <groupId>com.atguigu.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>${
     project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
        </dependency>

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

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
      
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-all</artifactId>
            <version>4.6.3</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

    </dependencies>

2.2application.yml

server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    sentinel:
      transport:
        dashboard: localhost:8080
        port: 8719  #默认8719，假如被占用了会自动从8719开始依次+1扫描。直至找到未被占用的端口

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

2.3主启动类

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

2.4controller

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

    @GetMapping("/testB")
    public String testB() {
     

        return "------testB";
    }
}

3.启动Sentinel8080 启动微服务8401

4.查看sentinel控制台，发现空空如也，啥都没有。是因为sentinel是采用懒加载，需要我们执行一次访问，才会有信息。
访问localhost/8401/testA

可以看到，已经开始监听了。

流控规则

基本介绍

• 资源名：唯一名称，默认请求路径。
• 针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default(不区分来源)
• 阈值类型/单机阈值：
  • QPS(每秒钟的请求数量)：当调用该api的QPS达到阈值的时候，进行限流。
  • 线程数：当调用该api的线程数达到阈值的时候，进行限流。

• 流控模式：
  • 直接：api达到限流条件时，直接限流。
  • 关联：当关联的资源达到阈值时，就限流自己。
  • 链路：只记录指定链路上的流量(指定资源从入口资源进行的流量，如果达到阈值，就进行限流)【api级别的针对来源】
• 流控效果：
  • 快速失败：直接失败，抛异常。
  • Warm UP：根据codeFactor(冷加载因子，默认3)的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值。
  • 排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置伟QPS，否则无效。

流控模式

直接->快速失败

快速点击访问http://localhost:8401/testA，直接失败的效果如下图：

线程数：

比如a请求过来，处理的慢，在一直处理，此时b请求又过来了，此时因为a占用一个线程，此时要处理b请求就只有额外开启一个线程，那么就会报错。

修改controller中testA方法，使用定时器来模拟业务处理请求比较慢的情况。

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

关联

当关联的资源达到阈值时，就限流自己。
一句话来说，当与A关联的资源B达到阈值后，就限流自己，B惹事，A挂了。

应用场景：比如支付接口达到阈值时，就要限流下订单的接口，防止一直有订单。

这里可以使用postman模拟并发密集访问testB，大批量线程高并发访问B，导致A失效了。 这时候再去访问testA，可以发现testA挂了。

链路

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

流控效果

直接->快速失败(默认的流控处理)

直接失败，抛出异常

Blocked by Sentinel (flow limiting)

源码：

com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController

预热

公式：阈值除以coldFactor(默认值为3)，经过预热时长后才会达到阈值。

Warmup配置：

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

排队等待：

降级规则

基本介绍

就是熔断降级。


Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高)，对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。
当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断(默认行为是抛出DegradeException)。

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

降级策略

RT

测试：
1.在controller添加一个方法，用于测试

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

        return "------testD";
    }

2.配置RT，这里的配置的RT，默认是秒级的平均响应时间。

默认计算平均时间是，1秒内进入5个请求，并且响应的平均值超过阈值(这里设置的200ms)，就报错。 1秒5请求是Sentinel默认设置的。

测试：

后续停止jmeter，没有这么大的访问量了，断路器关闭(保险丝恢复)，微服务恢复OK。

异常比例

测试：
1.修改请求方法：

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

2.配置

上面配置一句话来说，当1秒请求量>5，并且请求次数中出现异常的次数/总请求次数>0.2(我们设置的异常比例)，就会出现服务熔断。
3.jmeter

4.结论：
按照上述配置，单独访问一次，必然来一次报错一次(int age = 10/0)，调一次错一次。因为没有达到每秒的请求量>5。

开启jmeter后，直接高并发发送请求，多次调用达到我们的配置条件了。
断路器开启(保险丝跳闸)，微服务不可用了，不再报错error而是服务降级了。

异常数

注意：异常数是按照分钟统计的。
一分钟内，有5个请求发生异常，进入熔断。

测试：
1.添加请求方法

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

2.配置

热点key限流

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

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

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

比如:

• localhost:8080/aa?name=aa
• localhost:8080/aa?name=bb
• 这两个请求中，带有参数aa的请求访问频次非常高，我们就限制name=aa的请求，但是bb的不限制。

如何自定义降级方法，而不是默认的抛出异常？

使用@SentinelResource直接实现降级方法，它等同Hystrix的@HystrixCommand。

 @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) {
     
        //int age = 10/0;
        return "------testHotKey";
    }

    //兜底方法
    public String deal_testHotKey (String p1, String p2, BlockException exception) {
     
        return "------deal_testHotKey";
    }

定义热点规则：

比如说：我们controller中，有两个参数p1，p2，这个参数索引0表示 是对p1进行限制，1表示对p2进行限制，以此类推。

测试:
此时我们访问/testHotkey并且带上p1，如果qps大于1，就会触发我们定义的降级方法。

如果我们的参数是p2，就没有问题。

如果修改controller为@SentinelResource(value = “testHotKey”)，不指定降级方法。那么异常会打到前台用户界面，不太友好。

只有带上p1，才会触发热点限流。

设置热点规则的其他选项

需求：

添加配置：

测试：

注意：
参数类型只支持8种基本类型+String类型。

注意：
如果我们程序出现异常，是不会走blockHander的降级方法的，因为这个方法只配置了热点规程，没有配置限流规则。
我们这里配置的降级方法是sentinel针对热点规则配置的。只有触发热点规则才会降级。

系统规则

系统自适应限流：从整体维度对应用入口进行限流。
对整体限流，比如qps到达100，这里限流会限制整个系统不可用。


测试：

这里设置了，如果QPS到达1，那么整个系统将不可用。

@SentinelResource

用于配置降级等功能。

按资源名称限流

1.启动Nacos+Sentinel成功。
2.为8401添加依赖，添加我们自己的common包的依赖

<dependency>
    <groupId>com.atguigu.springcloud</groupId>
    <artifactId>cloud-api-commons</artifactId>
    <version>${
     project.version}</version>
</dependency>

3.额外创建一个controller类

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

    public CommonResult handleException(BlockException exception) {
     
        return new CommonResult(444, exception.getClass().getCanonicalName() + "\t 服务不可用");
    }
}

3.配置限流
注意，我们这里配置规则，资源名指定的是@SentinelResource注解value的值，这样也是可以的，也就是不一定要指定访问路径。

4.测试，可以看到已经进入降级方法了

5.此时，我们关闭8401服务，可以看到，这些定义的规则是临时的，关闭服务，规则就没有了。

按照Url地址限流

通过访问的URL来限流，会返回Sentinel自带默认的限流处理信息
1.controller中添加一个方法，用于测试

@GetMapping("/rateLimit/byUrl")
@SentinelResource(value = "byUrl")
public CommonResult byUrl()
{
     
    return new CommonResult(200,"按url限流测试OK",new Payment(2020L,"serial002"));
}

2.Sentinel控制台配置

3.测试 返回Sentinel自带默认的限流处理信息

上面兜底方法面临的问题

• 系统默认的，没有体现我们自己的业务要求。
• 依照现有条件，我们自定义的处理方法又和业务代码耦合在一块，不直观。
• 每个业务方法都对应一个兜底的方法，代码膨胀加剧。
• 全局统一的处理方法没有体现。