Sentinel的流控与熔断降级规则详解

往期回顾

Nacos的安装与配置

Spring Cloud集成Nacos作为注册中心

LoadBalacer集成Nacos实现负载均衡

常见的负载均衡策略分析

Spring Cloud集成Dubbo实现RPC调用

SpringCloud集成Nacos作为配置中心

Nacos整合OpenFegin实现RPC调用

Nacos整合Gateway入门实例

Spring Cloud Gateway的过滤器配置

Nacos整合Gateway实现动态路由

Sentinel的安装与配置

@SentinelResource详解

在上一篇文章中介绍了@SentineResource 的一些基本概念以及使用方法，但是同学们可能对服务的熔断降级，以及Sentinel的流量控制这些名词不是很清楚，这篇文章就让我们一起来看看这些具体指什么吧

服务降级

1. 什么是服务降级

   服务降级一般是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而**释放服务器资源的资源以保证核心业务的正常高效运行。**说白了，就是尽可能的把系统资源让给优先级高的服务。

2. 为什么需要服务降级

   服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大

3. 应用场景

   多用于微服务架构中，一般当整个微服务架构整体的负载超出了预设的上限阈值（和服务器的配置性能有关系），或者即将到来的流量预计会超过预设的阈值时（比如双11、6.18等活动或者秒杀活动）

4. 服务降级策略

   • 拒绝服务
   • 关闭服务

服务熔断

1. 什么是服务熔断?

应对微服务雪崩效应的一种链路保护机制，类似股市、保险丝，可看作降级的特殊情况

2. 为什么需要服务熔断？

微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务c，某一时间链路上对服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，导致请求的堆积，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应

服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。

降级与熔断的区别

1. 触发原因不一样，服务熔断由链路上某个服务引起的，服务降级是从整体的负载考虑
2. 管理目标层次不一样，服务熔断是一个框架层次的处理，服务降级是业务层次的处理
3. 实现方式不一样，服务熔断一般是自我熔断恢复，服务降级相当于人工控制
4. 触发原因不同，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑

流量控制

Sentinel除了提供服务的熔断与降级以外，还提供了流量控制来保证服务的高可用

流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

通俗点来说限流就是限制并发的请求访问量，超过阈值则拒绝，以下是Sentinel官网对流量控制的介绍：

流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状,如下图所示：

流量控制有以下几个角度:

• 资源的调用关系，例如资源的调用链路，资源和资源之间的关系；
• 运行指标，例如 QPS、线程池、系统负载等；
• 控制的效果，例如直接限流、冷启动、排队等。

Sentinel 的设计理念是让您自由选择控制的角度，并进行灵活组合，从而达到想要的效果

Sentinel的流控规则介绍

FlowSlot 会根据预设的规则，结合前面 NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot 统计出来的实时信息进行流量控制。

限流的直接表现是在执行 Entry nodeA = SphU.entry(resourceName) 的时候抛出 FlowException 异常。FlowException 是 BlockException 的子类，您可以捕捉 BlockException 来自定义被限流之后的处理逻辑。

同一个资源可以创建多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。

一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

• resource：资源名，即限流规则的作用对象
• count: 限流阈值
• grade: 限流阈值类型（QPS 或并发线程数）
• limitApp: 流控针对的调用来源，若为 default 则不区分调用来源
• strategy: 调用关系限流策略
• controlBehavior: 流量控制效果（直接拒绝、Warm Up、匀速排队

我们结合Sentinel的控制台来看：

参数解释：

• 资源名：Sentinel定义的资源名称，通常在代码中通过@SentinelResource进行埋点，名称唯一

• 针对来源：Sentinel可以针对调用者进行限流，填写微服务名，指定对哪个微服务进行限流 ，默认default(不区分来源，全部限制)

  • default :表示不区分调用者，来自任何调用者的请求都将进行限流统计。如果这个资源名的调用总和超过了这条规则定义的阈值，则触发限流（默认）
  • {some_origin_name}：表示针对特定的调用者，只有来自这个调用者的请求才会进行流量控制。例如 NodeA 配置了一条针对调用者caller1的规则，那么当且仅当来自 caller1 对 NodeA 的请求才会触发流量控制。
  • other：表示针对除 {some_origin_name} 以外的其余调用方的流量进行流量控制。例如，资源NodeA配置了一条针对调用者 caller1 的限流规则，同时又配置了一条调用者为 other 的规则，那么任意来自非 caller1 对 NodeA 的调用，都不能超过 other 这条规则定义的阈值。

• 阈值类型：流量控制主要有两种统计类型，一种是统计并发线程数，另外一种则是统计 QPS

  • QPS：当 QPS 超过某个阈值的时候，则采取措施进行流量控制

  • 并发线程数控制：当调用该接口的线程数超过阈值时，进行限流

    **并发数控制用于保护业务线程池不被慢调用耗尽。**例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

• 单机阈值

  • 基于QPS：QPS的阈值，超过该阈值会进行流控
  • 基于线程数：线程的阈值，超过该阈值拒绝请求

• 流控效果：当 QPS 超过某个阈值的时候，则采取措施进行流量控制，流量控制的效果包括以下几种：直接拒绝（快速失败）、Warm Up、匀速排队（排队等待）

  • 快速失败：该方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。

  • Warm Up：即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮

  • 排队等待：该方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法

    该方式的作用如下图所示：

    

    这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求

    注意：匀速排队模式暂时不支持 QPS > 1000 的场景。

• 流控模式

  • 直接：接口达到限流条件时，直接限流

  • 关联：当关联的资源达到阈值时，就限流自己

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tu177g3z-1662654429037)(https://pymjl.oss-cn-shanghai.aliyuncs.com/picgo/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%202022-09-08%20233907.png)]

    当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢，举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的：设置 strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource 为 write_db。这样当写库操作过于频繁时，读数据的请求会被限流

  • 只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）[api级别的针对来源]

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xUy50EZI-1662654429037)(https://pymjl.oss-cn-shanghai.aliyuncs.com/picgo/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%202022-09-08%20233320.png)]

    Sentinel链路流控失效请参考Issues Sentinel 链路流控模式失效 #1213

    Sentinel的熔断降级规则

    1. 慢调用比例 (SLOW_REQUEST_RATIO)：

       选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

       [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uhU9DpiM-1662654429038)(https://pymjl.oss-cn-shanghai.aliyuncs.com/picgo/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%202022-09-08%20235141.png)]

       2. 异常比例 (ERROR_RATIO)

          当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

       3. 异常数 (ERROR_COUNT)

          当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

       注意异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（BlockException）不生效。

       @SentinelResource 注解会自动统计业务异常，无需手动调用。其他统计异常方式请参考官网：熔断降级

       至此，对Sentinel的流控规则和熔断降级规则的介绍就到这里了，下面一篇文章我们一起来看看如何对Sentinel的持久化以及动态拉取吧，感谢大家的观看

       参考文章：

       Sentinel官方文档

       服务降级与服务熔断区别