微服务09-Sentinel的入门

文章目录

微服务中的雪崩现象
- 解决办法：
- 1. 超时处理
- 2. 舱壁模式
- 3. 熔断降级
- 4.流量控制
Sentinel
- 1.介绍
- 2.使用操作
- 3.限流规则
- 4.实战：流量监控
- 5.高级选项功能的使用
- 1.关联模式
- 2.链路模式
- 3.总结
流控效果
- 1.预热模式
- 2.排队等待模式
- 3.总结
- 4.热点参数限流
- 5.实战

微服务中的雪崩现象

首先，我们介绍一下微服务中雪崩现象：因为微服务中服务是互相调用的，错综复杂，当一个服务D出现问题时，那么调用D的服务请求就会失败，当请求累积到一定的量时，请求D的服务也会出问题——>(因为我们内置的tomcat连接数是有限制的，如果一直请求那个失败的服务，当请求达到一定的数量)，服务A也会炸掉，从而引起整个链路服务不可用；

在这里插入图片描述

解决办法：

1. 超时处理

我们可以设置超时时间，超过了就会返回错误信息，释放tomcat资源

劣势：起到了缓解雪崩问题，当服务请求的时间比超时时间短，假设1s内多个请求，而你超时时间是1s，那么还是会出现雪崩

在这里插入图片描述

2. 舱壁模式

将每个业务隔离开（有一个线程池），限定每个业务能够使用的线程数，就算这个服务挂了，也就损失这一部分的线程，从而避免了损失整个tomcat资源——>也就是线程隔离

在这里插入图片描述

3. 熔断降级

根据异常请求的比例，比如说你异常请求达到了1/2，超过了这个阈值就会熔断该业务，拒绝一切请求访问该业务

在这里插入图片描述

4.流量控制

首先我们了解一下QPS——>每秒能够处理的请求数；流量控制——>限制服务访问的QPS，避免服务因为流量突然增大而挂掉；

它是一种预防的功能，给大量请求进行限流，以一定数量请求进行访问

在这里插入图片描述

Sentinel

1.介绍

首先我们来说一下信号量隔离和线程池隔离之间的区别：

信号量隔离：用的还是tomcat池子，只是我们每一个业务都被限定了能够用多少个线程去访问，当请求数超过这个限定的数量时，就会拒绝访问了——>也就是说它会限制每个业务能使用的线程数量

好处：不用创建线程池，节省资源，轻量级；

坏处：隔离性较差，相当于吃大锅饭，每个规定了盛多少饭；

线程池隔离：就跟我们上面的舱壁模式一样，每个业务分配一个线程池，线程池里面限定了一定的线程数，起到了隔离作用，当服务挂了也就浪费这个池子

好处：隔离性好，方便控制，可以异步调用，毕竟每个服务都有线程池，我们请求给到线程池中处理，用户就可以干自己的事情了;

坏处：浪费了资源；

控制台：

Sentinel支持开箱即用，那些第三方配置都可以直接用，比如：查看监控，配置规则等等

熔断降级策略:

除了根据失败的请求比例来判断是否熔断，是否拒绝其他的请求请求该业务之外；还可以根据请求服务的时间来进行熔断降级——>因为请求服务时间可能太长了，拖垮我们的服务，我们进行熔断；

限流：

可以让突发的流量平稳运行——>进行一种流量控制，支持慢启动和匀速排队模式

在这里插入图片描述

2.使用操作

文件目录cmd打开小黑窗口然后运行代码

java -jar sentinel-dashboard-1.8.x.jar //启动sentinel

修改配置（启动有效）：

java -jar sentinel-dashboard-1.8.x.jar -Dserver.port=8090//修改端口配置

在这里插入图片描述

然后我们后台启动服务，Sentinel进行监控

 cloud:nacos:discovery:server-addr: localhost:8848 # nacos服务地址cluster-name: Hangzhou # 实例集群ephemeral: false  # 非临时实例sentinel:transport:dashboard: localhost:8080 #sentinel控制台版本

        <!--        sentinel依赖--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId><version>0.9.0.RELEASE</version></dependency>