彻底搞懂 Spring Cloud 前世今生系列之第⼆代 Spring Cloud 核⼼组件（SCA）- Sentinel 分布式系统的流量防卫兵_sca 组件

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>
  1
  2
  3
  4
  5

• 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
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42

• 上述配置之后，启动⾃动投递微服务，使⽤ Sentinel 监控⾃动投递微服务
  此时我们发现控制台没有任何变化，因为懒加载，我们只需要发起⼀次请求触发即可
  

Sentinel 关键概念

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!";
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

模拟密集式请求/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
    

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;
   }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23

• ⾃定义兜底逻辑类
  注意：兜底类中的⽅法为static静态⽅法

  public class SentinelHandlersClass {
  	// 整体要求和当时Hystrix⼀样，这⾥还需要在形参最后添加BlockException参数，⽤于接收异常
  	// 注意：⽅法是静态的
  	public static Integer handleException(Long userId, BlockException blockException) {
  		return -100;
  	}
  		 
  	public static Integer handleError(Long userId) {
  		return -500;
  	}
  }
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11

基于 Nacos 实现 Sentinel 规则持久化

⽬前，Sentinel Dashboard中添加的规则数据存储在内存，微服务停掉规则数据就消失，在⽣产环境下不合适。我们可以将Sentinel规则数据持久化到Nacos配置中⼼，让微服务从Nacos获取规则数据。

• ⾃动投递微服务的pom.xml中添加依赖

  <!-- Sentinel⽀持采⽤ Nacos 作为规则配置数据源，引⼊该适配依赖 -->
  <dependency> 
  	<groupId>com.alibaba.csp</groupId> 
  	<artifactId>sentinel-datasource-nacos</artifactId>
  </dependency>
  1
  2
  3
  4
  5

• ⾃动投递微服务的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类
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29

• Nacos Server中添加对应规则配置集（public命名空间—>DEFAULT_GROUP中添加）
  流控规则配置集 learn-service-autodeliver-flow-rules

  [
   {
  	"resource":"findResumeOpenState",
  	"limitApp":"default",
  	"grade":1,
  	"count":1,
  	"strategy":0,
  	"controlBehavior":0,
  	"clusterMode":false
    }
  ]
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11

  所有属性来⾃源码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
    }
  ]
  1
  2
  3
  4
  5
  6
  7
  8

  所有属性来⾃源码DegradeRule类

  • resource：资源名称
  • grade：降级策略 0 RT 1 异常⽐例 2 异常数
  • count：阈值
  • timeWindow：时间窗

• Rule 源码体系结构
  
  注意

  • ⼀个资源可以同时有多个限流规则和降级规则，所以配置集中是⼀个json数组
  • Sentinel控制台中修改规则，仅是内存中⽣效，不会修改Nacos中的配置值，重启后恢复原来的值； Nacos控制台中修改规则，不仅内存中⽣效，Nacos中持久化规则也⽣效，重启后规则依然保持