Sentinel服务熔断与限流

---

Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量控制、流量路由、熔断降级、系统自适应保护等多个维度来帮助用户保障微服务的稳定性。

官网地址：home | Sentinelhttps://sentinelguard.io/zh-cn/

下载地址:https://github.com/alibaba/Sentinel/releases

Sentinel 基本概念

资源

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

规则

围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

操作流程：

 ================================改pom,添加相关依赖================================
 <!--SpringCloud alibaba sentinel -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
        </dependency>

        
==============================写yml文件，配置相关信息===============================
server:
  port: 8401
​
spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848         #Nacos服务注册中心地址
    sentinel:
      transport:
        dashboard: localhost:8080 #配置Sentinel dashboard控制台服务地址
        port: 8719 #默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口

=============================主启动类，程序入口=====================================
@EnableDiscoveryClient
@SpringBootApplication
public class Main8401
{
    public static void main(String[] args)
    {
        SpringApplication.run(Main8401.class,args);
    }
}

==============================业务类，进行相关测试==================================
@RestController
public class FlowLimitController
{
​
    @GetMapping("/testA")
    public String testA()
    {
        return "------testA";
    }
​
    @GetMapping("/testB")
    public String testB()
    {
        return "------testB";
    }
}

 

流控规则

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

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

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

• resource：资源名，即限流规则的作用对象

• count: 限流阈值

• grade: 限流阈值类型，QPS 或线程数

• strategy: 根据调用关系选择策略

选项	描述
资源名	资源的唯一名称，默认就是请求的接口路径，可以自行修改，但是要保证唯一。
针对来源	具体针对某个微服务进行限流，默认值为default，表示不区分来源，全部限流。
阈值类型	QPS表示通过QPS进行限流，并发线程数表示通过并发线程数限流。
单机阈值	与阈值类型组合使用。如果阈值类型选择的是QPS，表示当调用接口的QPS达到阈值时，进行限流操作。如果阈值类型选择的是并发线程数，则表示当调用接口的并发线程数达到阈值时，进行限流操作。
是否集群	选中则表示集群环境，不选中则表示非集群环境。

三种流控模式

直接模式：当资源的请求达到设置的阈值时，直接对该资源触发流量控制。

关联模式：当与当前资源具有关联关系的另一个资源达到阈值时，对当前资源触发流量控制。

链路模式：只记录从指定链路访问到当前资源的请求，当这些请求达到阈值时，对指定链路上的资源触发流量控制

①直接模式

相关配置图如下所示：

当访问/testA资源时，超过单机阈值时（超过每秒1次访问量时），就会直接启动流控程序快速失败

②关联模式

相关配置图如下所示：

当访问/testA资源时，超过单机阈值时（超过每秒1次访问量时），就会对关联的资源路径启动流控程序快速失败

③链路模式

相关配置图如下所示：

有两个controller方法都调用了service层的common方法，配置链路对资源（common）进行监控通过入口/testC进而调用common方法的，超过单机阈值时（超过每秒1次访问量时），就会启动流控快速失败

@GetMapping("/testC")
    public String testC()
    {
        flowLimitService.common();
        return "------testC";
    }
    @GetMapping("/testD")
    public String testD()
    {
        flowLimitService.common();
        return "------testD";
    }

三种流控效果

快速失败（Fast Fail）

描述：当请求量超过设定的阈值时，新的请求会立即被拒绝，并抛出FlowException异常。

Warm Up（预热）

描述：系统启动后，流量从较低的阈值开始逐渐增加，经过一段预热时间后，达到设定的最大阈值。预热期间，系统会动态调整阈值，避免冷启动时的流量冲击。

冷启动（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式。该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。具体的例子参见 WarmUpFlowDemo。

冷却因子：在Sentinel的流量控制功能中，冷却因子（Cold Factor）是一个与Warm Up（预热）流控效果紧密相关的参数。它用于控制预热期间流量限制的宽松程度，从而影响系统从空闲状态到繁忙状态的过渡过程。默认状态下冷却因子为3

初始阈值计算公式：阈值/Cold Factor（冷却因子）

排队等待（Rate Limiter）

描述：所有请求会按照先进先出的顺序排队等待处理，请求之间的处理间隔由系统根据设定的QPS（每秒请求数）自动调整。如果请求预计的等待时间超过设定的最大等待时间，则会被拒绝。

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

①快速失败（Fast Fail）

相关配置图如下所示：

与直接模式图一样，可以参考上图解释

②Warm Up（预热）

单机阈值为10，预热时长设置5秒。

系统初始化的阈值为10 / 3 约等于3,即单机阈值刚开始为3(我们人工设定单机阈值是10，sentinel计算后QPS判定为3开始)；

然后过了5秒后阀值才慢慢升高恢复到设置的单机阈值10，也就是说5秒钟内QPS为3，过了保护期5秒后QPS为10

③排队等待（Rate Limiter）

相关配置图如下所示：

按照单机阈值，一秒钟通过一个请求，10秒后的请求作为超时处理，放弃,假设在一秒内有20个请求打入，那么系统只会排队处理前十个请求，以后的请求全部放弃

熔断规则

一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。然而，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长，线程会产生堆积，最终可能耗尽业务自身的线程池，服务本身也变得不可用。复杂链路上的某一环不稳定，就可能会层层级联，最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

 

选项	描述
资源名	资源的唯一名称，默认就是请求的接口路径，可以自行修改，但是要保证唯一。
最大RT	最大的响应时间,超过该值的调用为慢调用
比例阈值	在对应的熔断策略下，大于比例阈值就开启熔断
熔断时长	发生熔断后，经过多长时间熔断器从开启状态（OPEN）进入探测恢复状态（HALF-OPEN 状态）
最小请求数	请求到达多少时才开始计算调用比例
统计时长	统计该值范围内的所有请求

熔断策略

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

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

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

①慢调用比例

相关配置图如下所示：

当一秒钟内的请求数大于或者等于5个时，开始计算慢调用的比例，当慢调用的比例大于0.1时，就会启动熔断器。

  @GetMapping("/testH")
    public String testH()
    {
        //暂停几秒钟线程
        try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
        System.out.println("----测试:新增熔断规则-慢调用比例 ");
        return "------testH 新增熔断规则-慢调用比例";
    }

②异常比例

相关配置图如下所示：

当一秒钟内的请求数大于或者等于5个时，开始计算异常调用的比例，当异常调用的比例大于0.1时，就会启动熔断器

 @GetMapping("/testG")
    public String testG()
    {
        System.out.println("----测试:新增熔断规则-异常比例 ");
        int age = 10/0;
        return "------testG,新增熔断规则-异常比例 ";
    }

③异常数

相关配置图如下所示：

当一秒钟内的请求数大于或者等于5个时，开始计算异常个数，异常个数大于1个时，熔断器启动

@GetMapping("/testK")
    public String testK()
    {
        System.out.println("----测试:新增熔断规则-异常数 ");
        int age = 10/0;
        return "------testK,新增熔断规则-异常数 ";
    }

@SentinelResource注解

@SentinelResource 是 Sentinel（一款开源的流量控制、熔断降级组件）提供的一个注解，用于定义资源（Resource）和配置相应的熔断降级规则。通过该注解，开发者可以非常方便地对业务方法进行流量控制、熔断降级等操作，从而提高系统的稳定性和可用性。

注解属性

• value：资源的名称，用于标识不同的资源。

• entryType：资源的入口类型，默认为 EntryType.OUT，表示正常资源调用。其他类型包括 EntryType.IN（表示入口资源，通常用于注解在 Controller 方法上）等。

• blockHandler：熔断降级处理的方法名。当资源被限流或熔断时，会调用该方法。该方法必须与被注解的方法在同一个类中，且参数列表需要与被注解方法一致或多一个 BlockException 类型的参数。

• fallback：备用处理的方法名。当资源发生异常时，会调用该方法进行兜底处理。与 blockHandler 类似，该方法也必须与被注解的方法在同一个类中，且参数列表需要一致或多一个 Throwable 类型的参数。

• defaultFallback：默认的备用处理方法名。当 fallback 方法指定的备用处理方法不存在时，会调用此方法。该方法通常用于通用异常处理。

blockHandler与fallback的区别

在Sentinel中，@SentinelResource注解用于定义资源，并可以指定当资源被限流、降级或系统异常时的处理逻辑。其中，fallback和blockHandler是两个重要的属性，它们分别用于处理不同类型的异常情况。

1. fallback：

   • 作用：fallback属性指定了一个降级方法，当资源发生异常（包括Sentinel定义的异常和业务代码抛出的异常）时，会调用该方法。

   • 触发条件：任何类型的异常，无论是Sentinel定义的异常（如限流异常、降级异常）还是业务代码中的异常，都会触发fallback方法。

   • 方法签名：降级方法的签名应与原方法一致，或者可以额外添加一个Throwable类型的参数来接收异常信息。

2. blockHandler：

   • 作用：blockHandler属性指定了一个限流处理逻辑，当资源被限流时会调用该方法。

   • 触发条件：仅当资源访问被Sentinel限流时会触发blockHandler方法。

   • 方法签名：限流处理方法的签名除了与原方法一致外，还可以包含额外的参数，这些参数用于接收被限流的上下文信息，如BlockException对象。

3. 区别总结：

   • 触发条件不同：fallback是由任何异常触发的，而blockHandler仅由限流异常触发。

   • 处理逻辑不同：fallback用于处理所有类型的异常，提供通用的降级逻辑；而blockHandler专注于处理限流场景，提供针对性的限流处理逻辑。

   • 方法签名可能不同：虽然两者都可以与原方法签名一致，但blockHandler通常包含额外的参数来接收限流相关的上下文信息。

@GetMapping("/rateLimit/doAction/{p1}")
    @SentinelResource(value = "doActionSentinelResource",
            blockHandler = "doActionBlockHandler", fallback = "doActionFallback")
    public String doAction(@PathVariable("p1") Integer p1) {
        if (p1 == 0){
            throw new RuntimeException("p1等于零直接异常");
        }
        return "doAction";
    }
​
    public String doActionBlockHandler(@PathVariable("p1") Integer p1,BlockException e){
        log.error("sentinel配置自定义限流了:{}", e);
        return "sentinel配置自定义限流了";
    }
​
    public String doActionFallback(@PathVariable("p1") Integer p1,Throwable e){
        log.error("程序逻辑异常了:{}", e);
        return "程序逻辑异常了"+"\t"+e.getMessage();
    }
​

热点规则（了解）

对于经常访问的数据我们称之为热点，热点参数限流会统计出传入参数中的热点参数，对包含热点参数的资源调用进行限流操作。热点参数限流，可以看作是一种特殊的流控规则，仅对包含热点参数的资源生效。

授权规则（了解）

用于实现访问控制的机制，允许开发者根据请求来源（origin）来限制资源的访问。授权规则主要有以下两种类型

1. 白名单
定义：如果请求来源（origin）在白名单内，则允许访问。
应用场景：适用于只允许特定来源访问资源的场景，例如仅允许特定网关或服务访问某些接口。
2. 黑名单
定义：如果请求来源（origin）在黑名单内，则拒绝访问。
应用场景：适用于需要阻止某些已知恶意来源访问资源的场景。

//==========================controller方法===========================================
@RestController
@Slf4j
public class EmpowerController //Empower授权规则，用来处理请求的来源
{
    @GetMapping(value = "/empower")
    public String requestSentinel4(){
        log.info("测试Sentinel授权规则empower");
        return "Sentinel授权规则";
    }
}

//========================获取RequestOriginParser====================================
@Component
public class MyRequestOriginParser implements RequestOriginParser
{
    @Override
    public String parseOrigin(HttpServletRequest httpServletRequest) {
        return httpServletRequest.getParameter("serverName");
    }
}
 

规则持久化

每次项目在启动之后，我们就会看见之前配置的规则全部失效，又要自己手动重新配置，这样耗时耗力，非常的不方便。所以我们可以将规则保存进入Nacos中再持久化到数据库中。在生产级别的项目中，Nacos是很少会关闭的，但是项目的重启不可避免的。

================添加pom文件============================================
<!--SpringCloud ailibaba sentinel-datasource-nacos -->
        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
        </dependency>

===============================配置文件=============================================
server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service #8401微服务提供者后续将会被纳入阿里巴巴sentinel监管
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848         #Nacos服务注册中心地址
    sentinel:
      transport:
        dashboard: localhost:8080 #配置Sentinel dashboard控制台服务地址
                port: 8719 #默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口
            web-context-unify: false # controller层的方法对service层调用不认为是同一个根链路
            datasource:
         ds1:
           nacos:
             server-addr: localhost:8848
             dataId: ${spring.application.name}
             groupId: DEFAULT_GROUP
             data-type: json
             rule-type: flow # com.alibaba.cloud.sentinel.datasource.RuleType

在 Nacos 控制台中添加配置，配置内容为 JSON 格式的规则