SpringCloud Alibaba Sentinel

最新推荐文章于 2024-04-11 16:35:10 发布

阳光宅男dh

最新推荐文章于 2024-04-11 16:35:10 发布

阅读量168

点赞数

原文链接：https://blog.csdn.net/u013343114/article/details/110521642

版权

SpringCloud 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

服务雪崩

微服务架构中经常会出现多个服务级联调用的情况，如下图所示：A作为服务提供者，B作为服务消费者，B调用A，C又调用B，D又调用C，如果A出现问题，那么可能导致B调用失败，B出现问题又会导致C调用失败，这样问题不断向上延伸，导致整个系统不可用，也就是服务雪崩了。
导致服务雪崩原因有很多，比如：流量激增、缓存问题、硬件故障、程序bug、线程长时间等待等。

Sentinel是啥？

Sentinel翻译过来就是哨兵，从字面上理解就是国家如果出现了任何的状况，他会第一时间出现，把危险拦在外面。
阿里巴巴的Sentinel组件就是分布式系统的哨兵，它从流量控制、熔断降级、负载保护等多个方面对系统进行保护。

Sentinel的主要特性：
在这里插入图片描述

Sentinel VS Hystrix

在SpringCloud Netflix中有一个类似的组件：Hystrix 豪猪，下面我们把哨兵和豪猪进行对比：
在这里插入图片描述
可以看到Sentinel的功能更加完善，它的最大特点是有一套Web控制台界面，方便监控和配置各种限流规则，而且Hystrix早已停止更新了，显然Sentinel是它的最佳替代者。

安装Sentinel

到Sentinel官网下载jar包，这里使用的版本是1.8.0
https://github.com/alibaba/Sentinel/releases

在这里插入图片描述

运行Sentinel的前提是安装了Java环境，Windows系统中打开cmd命令行，切换到jar包所在目录，输入：

java -jar sentinel-dashboard-1.8.0.jar

就可以看到Sentinel的启动日志
在这里插入图片描述
在浏览器输入 http://localhost:8080 就可以看到控制台界面，账号密码默认都是sentinel

在这里插入图片描述
登录进去会发现：啥都没有

在这里插入图片描述

使用Sentinel

下面我们在之前的nacos案例基础上加入Sentinel。
1、给provider-service服务添加依赖

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

2、application.yml

server:
  port: 8888
spring:
  application:
    name: provider-service
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.7.188:8848
    sentinel:
      transport:
        dashboard: 192.168.7.188:8080 # sentinel 控制台的地址
        port: 8719  # sentinel的端口
management:
  endpoints:
    web:
      exposure:
        include: '*'

3、添加测试的控制器

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello(){
        return "hello sentinel!!";
    }
}

4、启动nacos服务，再启动sentinel控制台，然后启动provider-service服务
在nacos里面可以看到该服务
在这里插入图片描述
5、在浏览器上输入：http://localhost:8888/hello

然后我们会发现Sentinel的控制台，出来东西了

在这里插入图片描述
这就表示我们成功启动了Sentinel，并且用它监控了我们服务的接口调用情况。

什么是流控

流控就是流量控制，那么为什么要进行流控呢？

因为大型互联网应用都会有大量的用户流量，当遇到了某些特殊的时间节点，如：双十一秒杀、春节抢票等，大量的流量突然涌入系统，远远超过了服务器的处理能力，服务器可能直接宕机，造成整个系统不可用。

那么对这种问题，我们就需要对流量进行限制，对于超过限制的流量，我们可以采用熔断、降级、排队等待等方式来解决。

流控入门

下面我们通过边讲边练的方式，来讲解流控的基本概念。
首先我们再执行一下上篇文章的api接口：
在这里插入图片描述
然后我们进入Sentinel后台，在簇点链路中，可以看到/hello，在列表右边可以看到添加流控的按钮

基本流控规则

点下流控按钮，可以看到
在这里插入图片描述
在流控规则窗体里面，可以看到很多选项，那么这些都是些什么东东呢？

我们重点介绍下面三个：

资源名
这个比较好理解，就是api接口的名称了
阈值类型
阈值可以理解为最大值，如水的沸点是100度，水的温度阈值就是100。
那么这个阈值类型就是最大值的不同类型，有两种：
1. QPS （Query Per Seconds）每秒的请求数，1秒内对资源的请求次数，超过阈值后就启动限流
2. 线程数这个就是对资源访问的线程数，超过阈值就启动限流
单机阈值
这个就是根据上面选择的类型，设置的最大值了

流控测试

光看文字介绍可能还是不好理解，那么我们来动手操作试试。

先来演示QPS：阈值类型选择QPS，然后单机阈值设置为1，也就是说1秒内请求/hello接口的次数超过1次，就会启动限流，最后点击新增，下面就出现了添加的流控规则：
在这里插入图片描述
测试下，浏览器访问下/hello，慢慢点击是没事的，快速点击（1秒点击多次），就会出现下面的文字，意思是被Sentinel进行了限流。

然后我们在编辑下刚才的流控规则，把QPS改为线程数，阈值设置为3，点击保存。

在这里插入图片描述
然后我们浏览器测试刚才的接口，可以看到不管点多快，接口都可以正常访问，没有出现限流。

那么怎么才能按线程数实现限流呢？
我们可以使用JMeter进行测试，JMeter的基本使用这里就不介绍了，大家可以百度下。

添加线程组
设置线程数为5和永远循环，意思就是每次都会启动5个线程来访问上面的接口
添加取样器

配置接口访问的选项
可以添加个监听器，看访问结果
最后点击上面的启动测试按钮

结果是：出现了限流
在这里插入图片描述

流控模式

打开流控的高级选项，可以看到流控模式和流控效果两个选项。

直接

默认的流控模式是直接，流控效果是快速失败。如果看过上篇文章就比较好理解，直接就是直接访问上面的资源，快速失败就是效果是访问失败直接出现限流的文字。
在这里插入图片描述

关联

我们再看看关联是什么，微服务的系统资源一般都有关联关系，比如：
订单接口会调用支付接口，如果支付接口出现流量激增的情况，会导致调用订单接口出现问题，这时我们除了直接对支付接口限流外，也可以对订单接口限流。
在这里插入图片描述
为验证效果，我们编写控制器

@RestController
public class OrderController {

    @GetMapping("/order")
    public String order(){
        return "这是订单接口!";
    }

    @GetMapping("/payment")
    public String payment(){
        return "这是支付接口!";
    }
}

先访问一下/order接口，然后给它添加流控规则，流控模式选择关联，关联资源设置为/payment，也就是：payment接口每秒访问超过1次后，将对order接口进行限流。
在这里插入图片描述
测试还是使用JMeter，配置线程组、HTTP请求。

这是http配置的是访问payment接口

启动测试前，order接口访问是正常的。

启动测试后，order接口被限流了。

总结一下，关联就是：关联资源超过了阈值，限流当前的资源。

链路

链路是资源的调用可能出现上下级的层次结构，如下图：
在这里插入图片描述
A是根节点，以A为入口，可以访问B和C，B和C又可以访问D和E，那么我们如果对A进行限流，就可以对A下面的所有资源进行限流了。

做下测试：查看簇点链路，选择树状视图，就可以看到上下级的关系了。
在这里插入图片描述

我们看到上层的资源是/order，下层资源也是/order，给下面的/order添加流控

测试/order，会出现限流

流控效果

上面我们了解了流控的几种模式，下面我们在来了解下流控效果：

快速失败

快速失败是默认效果，既当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。

Warm Up

即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。
比如：在春节抢热点地区火车票的时候，如果直接把流量放进来，可能会一下直接把12306的服务器打死，那么我们可以设定一个预热时间，给服务器一个缓冲期，慢慢的把流量放进来，直到达到最大的阈值。

修改一下前面的流控规则，这里阈值是10，预热时间是5秒，前面讲过流量是逐步加到阈值上限的，那么就有一个初始的阈值：初始阈值 = 阈值上限 / coldFactor， coldFactor 是冷加载因子，默认为3，则初始阈值为 10 / 3 = 3
下面配置的效果就是：一开始限流的阈值是3，然后5秒后上升到10.
在这里插入图片描述
测试时，快速点击（1秒3次以上），就会出现限流

等5秒后，再快速点击，都没有限流，因为阈值上升到10了

排队等待

排队等待方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。也比较好理解，就是不管流量再多，进来访问资源时都必须排队，一个个的访问。
这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

为方便查看效果，给接口加上日志

@Slf4j
@RestController
public class OrderController {

    @GetMapping("/order")
    public String order(){
        log.info("Thread:{},time:{}",Thread.currentThread().getName(),System.currentTimeMillis());
        return "这是订单接口!";
    }

    @GetMapping("/payment")
    public String payment(){
        return "这是支付接口!";
    }
}

修改下流控
在这里插入图片描述
快速访问/order，发现日志输出的时间间隔都是控制在1秒，也就是排队等待设置的超时时间

@SentinelResource

Sentinel提供了@SentinelResource来处理限流、熔断降级
注解的配置基于AOP实现，需要添加Aspect配置

@Configuration
public class SentinelAspectConfiguration {

    @Bean
    public SentinelResourceAspect sentinelResourceAspect() {
        return new SentinelResourceAspect();
    }
}

@SentinelResource的源码

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
public @interface SentinelResource {
    String value() default "";

    EntryType entryType() default EntryType.OUT;

    String blockHandler() default "";

    Class<?>[] blockHandlerClass() default {};

    String fallback() default "";

    Class<? extends Throwable>[] exceptionsToTrace() default {Throwable.class};
}

@SentinelResource的属性

value 资源名称
entryType entry类型，有IN、OUT两种
blockHandler 限流处理方法
blockHandlerClass 限流处理类
fallback 熔断降级处理方法
fallbackClass 熔断降级处理类
exceptionsToTrace 异常跟踪列表

限流处理

在这里插入图片描述
前面出现限流情况后，都会出现一样的错误信息，那么我们是否能定义一个自己的限流处理方法呢？
在

@Slf4j
@RestController
@RequestMapping("provider")
public class GoodsController {

    @GetMapping("goods")
    @SentinelResource(value = "goods",blockHandler = "findGoodsExceptionHandler")
    public String findGoods(){
        log.info("正常返回商品");
        return "正常返回商品";
    }

    public String findGoodsExceptionHandler(BlockException ex){
        log.error("出现限流",ex);
        return "出现限流";
    }

blockHandler属性指定限流处理的方法名，默认情况下该方法必须定义在当前类中，而且参数和返回值和原方法一致，可以多定义一个BlockException参数代表限流异常。

如果不希望处理方法和原方法耦合在一起，可以单独定义处理类，处理方法必须是静态的。

@Slf4j
public class MyBlockHandler {

    public static String findGoodsExceptionHandler(BlockException ex){
        log.error("出现限流",ex);
        return "出现限流";
    }
}

然后@SentinelResource加上属性

blockHandlerClass = MyBlockHandler.class

配置限流规则
在这里插入图片描述
出现限流后，调用的是自定义方法

处理降级

通过fallback属性指定降级方法，降级方法必须在同一个类中，返回值和参数和原方法一致

@Slf4j
@RestController
@RequestMapping("provider")
public class GoodsController {

    @GetMapping("goods")
    @SentinelResource(value = "goods",fallback = "findGoodsFallback")
    public String findGoods(){
        if(new Random().nextInt(2) == 0){
            throw new RuntimeException("Error");
        }
        log.info("正常返回商品");
        return "正常返回商品";
    }


    public String findGoodsFallback(){
        log.info("出现异常熔断");
        return "出现异常熔断";
    }
}

添加一个降级规则，选择异常数，异常数、熔断时长、请求数都设置为1
在这里插入图片描述
原方法有1/2的机会抛出异常，抛出异常后，调用了降级方法