Sentinel 分布式系统的流量防卫兵
Sentinel 介绍
Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。
替代Hystrix,针对问题:服务雪崩、服务降级、服务熔断、服务限流
Hystrix:
- 服务消费者(⾃动投递微服务)—>调⽤服务提供者
在调⽤⽅引⼊Hystrix—> 单独搞了⼀个Dashboard项⽬—>Turbine - ⾃⼰搭建监控平台 dashboard
- 没有提供UI界⾯进⾏服务熔断、服务降级等配置(⽽是写代码,⼊侵了我们源程序环境)
Sentinel:
- 独⽴可部署Dashboard/控制台组件
- 减少代码开发,通过UI界⾯配置即可完成细粒度控制
Sentinel 分为两个部分:
- 核⼼库:(Java 客户端)不依赖任何框架/库,能够运⾏于所有 Java 运⾏时环境,同时对 Dubbo /Spring Cloud 等框架也有较好的⽀持。
- 控制台:(Dashboard)基于 Spring Boot 开发,打包后可以直接运⾏,不需要额外的 Tomcat 等应⽤容器。
Sentinel 具有以下特征:
- 丰富的应⽤场景:
Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。 - 完备的实时监控:
Sentinel 同时提供实时的监控功能。您可以在控制台中看到接⼊应⽤的单台机器秒级数据,甚⾄ 500 台以下规模的集群的汇总运⾏情况。 - ⼴泛的开源⽣态:
Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。 - 完善的 SPI 扩展点:
Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝。您可以通过实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性:
Sentinel 的开源⽣态:
Sentinel 部署
-
下载地址 我们使⽤v1.7.1
-
启动:java -jar sentinel-dashboard-1.7.1.jar &
-
⽤户名/密码:sentinel/sentinel
服务改造
在我们已有的业务场景中,“⾃动投递微服务”调⽤了“简历微服务”,我们在⾃动投递微服务进⾏的熔断降级等控制,那么接下来我们改造⾃动投递微服务,引⼊Sentinel核⼼包。
为了不污染之前的代码,复制⼀个⾃动投递微服务 learn-service-autodeliver-8098-sentinel
-
pom.xml引⼊依赖
<!--sentinel 核⼼环境 依赖--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency>
-
application.yml修改(配置sentinel dashboard,暴露断点依然要有,删除原有hystrix配置,删除原有OpenFeign的降级配置)
server: port: 8098 spring: application: name: learn-service-autodeliver cloud: nacos: discovery: server-addr: 127.0.0.1:8848 sentinel: transport: dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址 port: 8719 # sentinel会在该端⼝启动http server,那么这样的话,控制台定义的⼀些限流等规则才能发送传递过来, #如果8719端⼝被占⽤,那么会依次+1 management: endpoints: web: exposure: include: "*" # 暴露健康接⼝的细节 endpoint: health: show-details: always #针对的被调⽤⽅微服务名称,不加就是全局⽣效 learn-service-resume: ribbon: #请求连接超时时间 ConnectTimeout: 2000 #请求处理超时时间 ##########################################Feign超时时⻓设置 ReadTimeout: 3000 #对所有操作都进⾏重试 OkToRetryOnAllOperations: true ####根据如上配置,当访问到故障请求的时候,它会再尝试访问⼀次当前实例(次数由MaxAutoRetries配置), ####如果不⾏,就换⼀个实例进⾏访问,如果还不⾏,再换⼀次实例访问(更换次数由MaxAutoRetriesNextServer配置), ####如果依然不⾏,返回失败信息。 MaxAutoRetries: 0 #对当前选中实例重试次数,不包括第⼀次调⽤ MaxAutoRetriesNextServer: 0 #切换实例的重试次数 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整 logging: level: # Feign⽇志只会对⽇志级别为debug的做出响应 com.learn.edu.controller.service.ResumeServiceFeignClient: debug
-
上述配置之后,启动⾃动投递微服务,使⽤ Sentinel 监控⾃动投递微服务
此时我们发现控制台没有任何变化,因为懒加载,我们只需要发起⼀次请求触发即可
Sentinel 关键概念
概念名称 | 概念描述 |
---|---|
资源 | 它可以是 Java 应⽤程序中的任何内容,例如,由应⽤程序提供的服务,或由应⽤程序调⽤的其它应⽤提供的服务,甚⾄可以是⼀段代码。我们请求的API接⼝就是资源 |
规则 | 围绕资源的实时状态设定的规则,可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。 |
Sentinel 流量规则模块
系统并发能⼒有限,⽐如系统A的QPS⽀持1个,如果太多请求过来,那么A就应该进⾏流量控制了,⽐如其他请求直接拒绝
- 资源名:默认请求路径
- 针对来源:Sentinel可以针对调⽤者进⾏限流,填写微服务名称,默认default(不区分来源)
- 阈值类型/单机阈值
- QPS:(每秒钟请求数量)当调⽤该资源的QPS达到阈值时进⾏限流
- 线程数:当调⽤该资源的线程数达到阈值的时候进⾏限流(线程处理请求的时候,如果说业务逻辑执⾏时间很⻓,流量洪峰来临时,会耗费很多线程资源,这些线程资源会堆积,最终可能造成服务不可⽤,进⼀步上游服务不可⽤,最终可能服务雪崩)
- 是否集群:是否集群限流
- 流控模式:
- 直接:资源调⽤达到限流条件时,直接限流
- 关联:关联的资源调⽤达到阈值时候限流⾃⼰
- 链路:只记录指定链路上的流量
- 流控效果:
- 快速失败:直接失败,抛出异常
- Warm Up:根据冷加载因⼦(默认3)的值,从阈值/冷加载因⼦,经过预热时⻓,才达到设置的QPS阈 值
- 排队等待:匀速排队,让请求匀速通过,阈值类型必须设置为QPS,否则⽆效
流控模式之关联限流**
- 关联的资源
调⽤达到阈值时候限流⾃⼰,⽐如⽤户注册接⼝,需要调⽤身份证校验接⼝(往往身份证校验接⼝),如果身份证校验接⼝请求达到阈值,使⽤关联,可以对⽤户注册接⼝进⾏限流。
@RestController
@RequestMapping("/user")
public class UserController {
/**
* ⽤户注册接⼝
* @return
*/
@GetMapping("/register")
public String register() {
System.out.println("Register success!");
return "Register success!";
}
/**
* 验证注册身份证接⼝(需要调⽤公安户籍资源)
* @return
*/
@GetMapping("/validateID")
public String findResumeOpenState() {
System.out.println("validateID");
return "ValidateID success!";
}
}
模拟密集式请求/user/validateID验证接⼝,我们会发现/user/register接⼝也被限流了
-
流控模式之链路限流
链路指的是请求链路(调⽤链)链路模式下会控制该资源所在的调⽤链路⼊⼝的流量。需要在规则中配置⼊⼝资源,即该调⽤链路⼊⼝的上下⽂名称。
⼀棵典型的调⽤树如下图所示:(阿⾥云提供)
上图中来⾃⼊⼝ Entrance1 和 Entrance2 的请求都调⽤到了资源 NodeA ,Sentinel 允许只根据某个调⽤⼊⼝的统计信息对资源限流。⽐如链路模式下设置⼊⼝资源为 Entrance1 来表示只有从⼊⼝Entrance1 的调⽤才会记录到 NodeA 的限流统计当中,⽽不关⼼经 Entrance2 到来的调⽤。
-
流控效果之Warm up
当系统⻓期处于空闲的情况下,当流量突然增加时,直接把系统拉升到⾼⽔位可能瞬间把系统压垮,⽐如电商⽹站的秒杀模块。通过 Warm Up 模式(预热模式),让通过的流量缓慢增加,经过设置的预热时间以后,到达系统处理请求速率的设定值。
Warm Up 模式默认会从设置的 QPS 阈值的 1/3 开始慢慢往上增加⾄ QPS 设置值。
-
流控效果之排队等待
排队等待模式下会严格控制请求通过的间隔时间,即请求会匀速通过,允许部分请求排队等待,通常⽤于消息队列削峰填⾕等场景。需设置具体的超时时间,当计算的等待时间超过超时时间时请求就会被拒绝。很多流量过来了,并不是直接拒绝请求,⽽是请求进⾏排队,⼀个⼀个匀速通过(处理),请求能等就等着被处理,不能等(等待时间>超时时间)就会被拒绝
例如,QPS 配置为 5,则代表请求每 200 ms 才能通过⼀个,多出的请求将排队等待通过。超时时间代表最⼤排队时间,超出最⼤排队时间的请求将会直接被拒绝。排队等待模式下,QPS 设置值不要超过1000(请求间隔 1 ms)。
Sentinel 降级规则模块
流控是对外部来的⼤流量进⾏控制,熔断降级的视⻆是对内部问题进⾏处理。
Sentinel 降级会在调⽤链路中某个资源出现不稳定状态时(例如调⽤超时或异常⽐例升⾼),对这个资源的调⽤进⾏限制,让请求快速失败,避免影响到其它的资源⽽导致级联错误。当资源被降级后,在接下来的降级时间窗⼝之内,对该资源的调⽤都⾃动熔断。
这⾥的降级其实是Hystrix中的熔断
还记得当时Hystrix的⼯作流程么? 不记得了点这里回顾
- 策略
Sentinel不会像Hystrix那样放过⼀个请求尝试⾃我修复,就是明明确确按照时间窗⼝来,熔断触发后,时间窗⼝内拒绝请求,时间窗⼝后就恢复。- RT(平均响应时间 )
当 1s 内持续进⼊ >=5 个请求,平均响应时间超过阈值(以 ms 为单位),那么在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地熔断(抛出 DegradeException)。注意Sentinel 默认统计的 RT 上限是 4900 ms,超出此阈值的都会算作 4900 ms,若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
- 异常⽐例
当资源的每秒请求量 >= 5,并且每秒异常总数占通过量的⽐值超过阈值之后,资源进⼊降级状态,即在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地返回。异常⽐率的阈值范围是 [0.0, 1.0] ,代表 0% - 100%。
- 异常数
当资源近 1 分钟的异常数⽬超过阈值之后会进⾏熔断。注意由于统计时间窗⼝是分钟级别的,若timeWindow ⼩于 60s,则结束熔断状态后仍可能再进⼊熔断状态。
时间窗⼝ >= 60s
- RT(平均响应时间 )
Sentinel ⾃定义兜底逻辑
@SentinelResource注解类似于Hystrix中的@HystrixCommand注解
@SentinelResource注解中有两个属性需要我们进⾏区分,blockHandler属性⽤来指定不满⾜Sentinel规则的降级兜底⽅法,fallback属性⽤于指定Java运⾏时异常兜底⽅法
-
在API接⼝资源处配置
/** * @SentinelResource value:定义资源名 blockHandlerClass:指定Sentinel规则异常兜底逻辑所在class类 blockHandler:指定Sentinel规则异常兜底逻辑具体哪个⽅法 fallbackClass:指定Java运⾏时异常兜底逻辑所在class类 fallback:指定Java运⾏时异常兜底逻辑具体哪个⽅法 */ @GetMapping("/checkState/{userId}") @SentinelResource(value = "findResumeOpenState",blockHandlerClass = SentinelFallbackClass.class,blockHandler = "handleException",fallback = "handleError",fallbackClass = SentinelFallbackClass.class) public Integer findResumeOpenState(@PathVariable Long userId) { // 模拟降级: /*try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); }*/ // 模拟降级:异常⽐例 int i = 1/0; Integer defaultResumeState = resumeServiceFeignClient.findDefaultResumeState(userId); return defaultResumeState; }
-
⾃定义兜底逻辑类
注意:兜底类中的⽅法为static静态⽅法public class SentinelHandlersClass { // 整体要求和当时Hystrix⼀样,这⾥还需要在形参最后添加BlockException参数,⽤于接收异常 // 注意:⽅法是静态的 public static Integer handleException(Long userId, BlockException blockException) { return -100; } public static Integer handleError(Long userId) { return -500; } }
基于 Nacos 实现 Sentinel 规则持久化
⽬前,Sentinel Dashboard中添加的规则数据存储在内存,微服务停掉规则数据就消失,在⽣产环境下不合适。我们可以将Sentinel规则数据持久化到Nacos配置中⼼,让微服务从Nacos获取规则数据。
-
⾃动投递微服务的pom.xml中添加依赖
<!-- Sentinel⽀持采⽤ Nacos 作为规则配置数据源,引⼊该适配依赖 --> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency>
-
⾃动投递微服务的application.yml中配置Nacos数据源
spring: application: name: learn-service-autodeliver cloud: nacos: discovery: server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850 sentinel: transport: dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址 port: 8719 # sentinel会在该端⼝启动http server,那么这样的话,控制台定义的⼀些限流等规则才能发送传递过来, #如果8719端⼝被占⽤,那么会依次+1 # Sentinel Nacos数据源配置,Nacos中的规则会⾃动同步到sentinel控制台的流控规则中 datasource: # 此处的flow为⾃定义数据源名 flow: # 流控规则 nacos: server-addr: ${spring.cloud.nacos.discovery.server-addr} data-id: ${spring.application.name}-flow-rules groupId: DEFAULT_GROUP data-type: json rule-type: flow # 类型来⾃RuleType类 degrade: nacos: server-addr: ${spring.cloud.nacos.discovery.server-addr} data-id: ${spring.application.name}-degrade-rules groupId: DEFAULT_GROUP data-type: json rule-type: degrade # 类型来⾃RuleType类
-
Nacos Server中添加对应规则配置集(public命名空间—>DEFAULT_GROUP中添加)
流控规则配置集 learn-service-autodeliver-flow-rules[ { "resource":"findResumeOpenState", "limitApp":"default", "grade":1, "count":1, "strategy":0, "controlBehavior":0, "clusterMode":false } ]
所有属性来⾃源码FlowRule类
- resource:资源名称
- limitApp:来源应⽤
- grade:阈值类型 0 线程数 1 QPS
- count:单机阈值
- strategy:流控模式,0 直接 1 关联 2 链路
- controlBehavior:流控效果,0 快速失败 1 Warm Up 2 排队等待
- clusterMode:true/false 是否集群
-
降级规则配置集 learn-service-autodeliver-degrade-rules
[ { "resource":"findResumeOpenState", "grade":2, "count":1, "timeWindow":5 } ]
所有属性来⾃源码DegradeRule类
- resource:资源名称
- grade:降级策略 0 RT 1 异常⽐例 2 异常数
- count:阈值
- timeWindow:时间窗
-
Rule 源码体系结构
注意- ⼀个资源可以同时有多个限流规则和降级规则,所以配置集中是⼀个json数组
- Sentinel控制台中修改规则,仅是内存中⽣效,不会修改Nacos中的配置值,重启后恢复原来的值; Nacos控制台中修改规则,不仅内存中⽣效,Nacos中持久化规则也⽣效,重启后规则依然保持