sentinel 前方参考
计算QPS-Sentinel限流算法 https://www.cnblogs.com/yizhiamumu/p/16819497.html
Sentinel 介绍与下载使用 https://www.cnblogs.com/yizhiamumu/p/16823313.html
sentinel的四种流控规则介绍 https://www.cnblogs.com/yizhiamumu/p/16819593.html
sentinel 的限流规则及流量控制 https://www.cnblogs.com/yizhiamumu/p/16819680.html
sentinel中如何使用@SentinelResource和openFeign来进行服务熔断和降级的操作 https://www.cnblogs.com/yizhiamumu/p/16823146.html
Sentinel 介绍
分布式系统的流量防卫兵: 随着微服务的普及,服务调用的稳定性也变的越来越重要,Sentinel以“流量”为切入点,在流量控制、断路、负载保护等多个方面进行续航,保证服务的可靠性。
Sentinel具有以下特征:
丰富的应用场景: Sentinel承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控:Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。同时 Sentinel 提供 Java/Go/C++ 等多语言的原生实现。
完善的 SPI 扩展机制:Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性:
Sentinel的妙用
当我们的分布式系统,面临复杂的体系结构中应用程序可能有数十个依赖关系,每个依赖关系在某些时候将不可避免的失败,比如我们调用 D\F\K 这几个服务,如果这些服务中某一个出现问题了,那么有可能会出现整体系统效率的下降,严重的甚至出现服务雪崩。
多个微服务之间互相调用的时候,如果D调用K和F,而K和F又调用其他的微服务,那么就会形成扇出
,如果扇出某个链路上的微服务调用超时或者响应很慢,那么微服务D就会占用越来越多的系统资源,从而导致系统崩溃,也就是服务雪崩。
对于高流量的应用来说,单一的后端依赖可能会导致服务器上的资源在极短的时间内被耗光,同时还有可能导致这些应用程序服务之间的响应时间增加,队列、线程和其他系统资源变的紧缺,导致整个系统之间发生更多的次生故障,如果我们单个应用服务故障处理和延迟进行隔离管控,当单个依赖关系失败时,不能对这个系统和资源产生影响,当某个模块实例失败以后,如果这个时候服务还能接收请求和流量访问,同时这个服务还去调用其他模块时,这样的级联故障,就会导致雪崩的发生
对比与其他的断流产品(Hystrix)而言,他不需要我们自己手动搭建监控平台,而且它有一套属于自己的Web界面,可对多种指标进行流控、熔断,且提供了实时监控和控制面板,功能更为强大
Sentinel 使用
下载地址:https://github.com/alibaba/Sentinel/releases
Sentinel分为两个部分:
核心库:不依赖任何框架/库,只需要Java运行时环境,同时对Dubbo\SpringCloud等框架也有很好的支持
控制台:基于SpringBoot开发,打包后可以直接运行,不需要额外的应用容器
注意:jdk1.8环境/8080端口不能被占用
启动命令:java -jar sentinel-dashboard-1.8.4.jar
访问地址:http://localhost:8080/
账号密码:sentinel/sentinel
到这里呢,我们的Sentinel就安装成功了,可能有点同学在界面上没有看到任何东西,并没有发现监控的服务,这是因为我们还没有启动项目,而Sentinel本身采用的是懒加载模式,所以我们需要先去访问服务对应的接口,Sentinel才会进行工作,接下来我们就来搭建我们的测试项目
搭建项目
Sentinel官方参考文档:https://sentinelguard.io/zh-cn/docs/quick-start.html
注意: 这里我们使用到了Nacos,不会Nacos的小伙伴,可以看我之前的文章,里面有详细的介绍,其实只需要你启动一个端口为8848的Nacos就行
导入依赖:
<!-- Nacos客户端依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- sentinel依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
配置属性:
server:
port: 8006
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
sentinel:
transport:
#配置Sentinel地址,就是我们的WEB界面
dashboard: localhost:8080
#Sentinel配置默认8719端口,被占用端口会自动从+1,直到找到未被占用的端口
port: 8719
management:
endpoints:
web:
exposure:
include: '*'
测试类:
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.concurrent.TimeUnit;
@RestController
public class TestController {
@GetMapping("/playA")
public String playA() {
return "hello my name is playA ,wo shi boy";
}
@GetMapping("/playB")
public String playB(){
return "hi my name is playB, me girl";
}
}
最后在我们的启动类上加上 :@EnableDiscoveryClient,点击启动,然后我们来访问我们的测试地址:
http://localhost:8006/playA
http://localhost:8006/playB
访问之后,我们就能在Sentinel上看到我们的监控信息了,如下所示:
Sentinel 流控规则
首先我们先来看一张图:
上面这张图,就包含了,我们要讲解的全部内容,主要分为以下几点:
资源名:流控规则中唯一的名称,默认为我们的请求路径
针对来源:Sentinel 对调用者进行限流,填写我们的微服务名,默认为default,对来源不进行区分
阈值类型/单机阈值:
QPS(每秒请求数量),使用该类型时,QPS达到我们设置的单机阈值,进行限流
线程数:当使用该类型时,线程数量达到我们设置的单机阈值,进行限流
是否集群:默认否,如果是集群勾选
流控模式:
直接:API达到限流条件时,直接限流,如果我们设置QPS为1,如果大于这个数量,直接返回错误
关联:当关联的资源达到阈值时,限流自己,比如A调用B,B达到了阈值,A进行限流
链路:只记录链路上的流量,指定对应的链路路径,从入口开始,如果达到阈值,则进行限流
流控效果:
快速失败:直接抛异常
Warm Up:根据冷加载因子codeFactor经过预热时长,才达到设置的QPS阈值
排队等待:匀速排队,让请求以匀速速度进行请求,阈值类型,需要设置为QPS,否则无效
我们先来新增一个流控规则看一下,操作方式有两种
在流控规则中添加
在簇点链路中添加
因为方便,我们一般会选择在簇点链路中添加,我们先来试一下QPS的操作:
这里我们设置单机阈值为1,所以playA
这个接口一秒中只能被访问一次,如果超过,则进行限流操作进行一个阻塞操作,这个效果我们是可以直接看到的,当我们不停的刷新playA
时,就会现在如下信息,而没有设置的playB
,则不会
在这里我们如果设置为线程数会怎么样呢?我们来看一下。
在这里我们要注意:如果项目重新启动,需要将修改后的playA
,重新访问后重新,添加流控规则
同时我们需要在代码中设置延时执行,如果处理太快,我们是看不到实际效果的,如果有兴趣的小伙伴可以自己启动线程去跑,在这里我们设置playA
,进行一秒钟的延时操作,
@GetMapping("/playA")
public String playA() {
try {
//阻塞1 秒
TimeUnit.MILLISECONDS.sleep(1000);
}catch (Exception e){
e.printStackTrace();
}
return "hello my name is playA ,wo shi boy";
}
这里要使用两个不同浏览器去跑,同一个浏览器使用的是同一线程,先请求的某歌后请求的某火效果如下所示:
QPS和并发线程数的规则如下所示:
总结
虽然最终效果是一样的,但是规则是不同的,每种应对不用的业务场景,大家可以合理化的去使用
标签:阈值,介绍,sentinel,限流,playA,Sentinel,我们,下载 From: https://www.cnblogs.com/yizhiamumu/p/16823313.html