Sentinel概述
Sentinel 是什么?
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel具有以下特性:
- 丰富的应用场景: Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控: Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态: Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
- 完善的 SPI 扩展点: Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

可以代替Hystrix、Sleuth
下载和运行
下载地址:https://github.com/alibaba/Sentinel/releases
这里选择 sentinel-dashboard-1.7.1.jar
下载
下载成功后直接运行:
java -jar .\sentinel-dashboard-1.7.1.jar

启动成功后直接访问 http://localhost:8080 即可看到管理界面,默认用户名和密码都是sentinel。
构建测试模块
新建模块cloudalibaba-sentinel-service8401
,依赖如下:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- sentinel-datasource-nacos 后续持久化用 -->
<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.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>
<dependency>
<groupId>com.rhett</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
yaml配置:
server:
port: 8401
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
nacos:
discovery:
server-addr: localhost:1111
sentinel:
transport:
dashboard: localhost:8080
# 默认8719端口,如果被占用会从8719开始依次+1扫描,直到找到未被占用的端口
port: 8719
management:
endpoints:
web:
exposure:
include: '*'
启动类:
@SpringBootApplication
@EnableDiscoveryClient
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() + "...testB ");
return "testB -----";
}
}
至此该模块构建完成,访问一次 http://localhost:8401/testA ,即至少调用一次该服务,就可以在sentinel的控制界面上看到该服务了。

实时监控

流控规则

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

即QPS最高为1。
设置完成之后频繁访问 http://localhost:8401/testA 可见超过QPS的请求网页响应:
Blocked by Sentinel (flow limiting)
而如果设置阈值为线程数最高为1,因为请求处理的很快看不出效果,可以做如下修改:
@GetMapping("/testA")
public String testA() throws InterruptedException {
//等待0.8秒
TimeUnit.MILLISECONDS.sleep(800);
return "testA-----";
}
再次频繁访问网页,就可以看到部分请求被阻拦。
关联
当两个资源之间具有资源争抢或者依赖关系的时候,这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢,读的速度过高会影响写得速度,写的速度过高会影响读的速度。如果放任读写操作争抢资源,则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢。
新建如下流控规则:

该流控规则的意思是,如果对/testB
的QPS大于1,则对/testA
进行限流
该流控规则通常用于两个资源存在优先级,优先级低的给优先级高的让资源。
链路
资源中是存在着调用关系的,Sentinel 允许只根据某个入口的统计信息对资源限流。比如下面这棵调用树:
machine-root
/ \
/ \
Entrance1 Entrance2
/ \
/ \
DefaultNode(nodeA) DefaultNode(nodeA)
nodeA资源可以通过Entrance1
或者Entrance2
资源得到,我们可以对nodeA进行限流,指定流控规则为链路,并指定入口资源为/Entrance1
,就可以只对来自/Entrance1
的调用限流,而不对来自/Entrance2
的调用限流
流控效果
warm up
上面的案例中我们都是使用的流控效果中的快速失败,而流控效果中的warm up,即预热/冷启动方式。当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮。(通常和此时系统中没有足量的缓存数有关)
根据codeFactor(冷加载因子,默认3)的值,请求QPS从阈值/codeFactor
开始, 经过预热时长,逐渐升至设置的QPS阈值。
我们建立如下配置:

它的意思则是QPS从300/3=100
开始,在10秒内逐渐升至300
排队等待
匀速排队方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。
该方式的作用如下图所示:

排队等待可以设置超时时间:

该规则的效果是,QPS上限为2,超过QPS的请求排队等待,排队时间超过10秒则快速失败。
降级规则
选择新建降级规则,可以看到如下配置窗

它支持三种降级策略,而Hystrix似乎只有异常比例。
Sentinel断路器没有半开状态,时间窗口过了就直接打开。(而hystrix中的时间窗口概念是一个统计失败率的时间范围)
RT
RT(平均响应时间):当 1s 内持续进入 5 个请求,对应时刻的平均响应时间(秒级)均超过阈值(count,以 ms 为单位),那么在接下的时间窗口之内,对这个方法的调用都会自动地熔断(抛出 DegradeException)。注意 Sentinel 默认统计的 RT 上限是 4900 ms
,超出此阈值的都会算作 4900 ms,若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx
来配置。
异常比例
异常比例:当资源的每秒请求量 >= 5,并且每秒异常总数占通过量的比值超过阈值(DegradeRule 中的 count)之后,资源进入降级状态,即在接下的时间窗口之内,对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
异常数
异常数:当资源近 1 分钟的异常数目超过阈值之后会进行熔断。 注意由于统计时间窗口是分钟级别的,若 timeWindow 小于 60s,则结束熔断状态后仍可能再进入熔断状态。
原创文章,作者:彭晨涛,如若转载,请注明出处:https://www.codetool.top/article/sentinel%e6%b5%81%e6%8e%a7%e8%a7%84%e5%88%99%e4%b8%8e%e9%99%8d%e7%ba%a7%e8%a7%84%e5%88%99/