Spring Cloud：Nacos，Sentinel

Spring Cloud Alibaba 简介

Spring Cloud 是若干个框架的集合，包括 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。Spring Cloud 通过 Spring Boot 风格的封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、容易部署的分布式系统开发工具包。一般来说，Spring Cloud 包含以下组件，主要以 Netflix 开源为主。

同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

API 网关：[Zuul, Gateway]

限流降级：Sentinel 高可用

服务层：
{
  可集成 Ribbon、OpenFeign，
  [Dubbo 服务调用，Dubbo 服务调用，Dubbo 服务调用]，
  Seata 分布式事务
}

消息驱动：RocketMQ

服务治理：
[Nacos 服务发现，Nacos 服务中心，Arths 服务监控]

阿里云商业化组件：
[Alibaba Cloud ACM, Alibaba Cloud OSS, Alibaba Cloud SchedulerX]

数据层

阿里开源组件

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

RocketMQ：开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：在国内应用非常广泛的一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Arthas：开源的 Java 动态追踪工具，基于字节码增强技术，功能非常强大。

阿里商业化组件

阿里巴巴推出 Spring Cloud Alibaba，很大程度上市希望通过抢占开发者生态，来帮助推广自家的云产品。所以在开源社区，夹带了不少私货，阿里商业化组件，整体易用性和稳定性还是很高的。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS：阿里云对象存储服务 Object Storage Service，OSS，是阿里云提供的云存储服务。

Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准的定时（基于 Cron 表达式）任务调度服务。

集成 Spring Cloud 组件

Spring Cloud Alibaba 作为整套的微服务解决组件，只依靠目前阿里的开源组件是不够的，更多的是集成当前的社区组件，所以 Spring Cloud Alibaba 可以集成 Zuul，GateWay 等网关组件，也可继承 Ribbon、OpenFeign 等组件。

Nacos 服务注册和配置中心

Nacos 介绍

Nacos - Dynamic Naming and Configuration Service 是阿里巴巴开源的一个针对微服务架构中服务发现、配置管理和服务管理平台。

Nacos 就是注册中心 + 配置中心的组合。

Nacos = Eureka + Config + Bus。

官网 - https://nacos.io，下载地址 - https://github.com/alibaba/Nacos。

Nacos 功能特性：

• 服务发现与健康检查。
• 动态配置管理。
• 动态 DNS 服务。
• 服务和元数据管理；管理平台的角度，Nacos 也有一个 UI 页面，可以看到注册的服务及其实例信息（元数据信息）等；动态的服务权重调整、动态服务优雅下线，都可以去做。

Nacos 单例服务部署

下载解压安装包，执行命令启动（使用最近比较稳定的版本 nacos-server-1.2.0.tar.gz）：

# linux/mac: 
sh startup.sh -m standalone
# windows: 
cmd startup.cmd

访问 nacos 控制台：http://127.0.0.1:8848/nacos/#/login 或者 http://127.0.0.1:8848/nacos/index.html（默认端口 8848，账号和密码 nacos / nacos）。

微服务注册到 Nacos

1）在 lagou-parent 父项目 pom 中增加 SCA 的依赖版本管理：

<dependencyManagement>
    <dependencies>
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-dependenciesartifactId>
            <version>Greenwich.RELEASEversion>
            <type>pomtype>
            <scope>importscope>
        dependency>
        
        <dependency>
            <groupId>com.alibaba.cloudgroupId>
            <artifactId>spring-cloud-alibaba-dependenciesartifactId>
            <version>2.1.0.RELEASEversion>
            <type>pomtype>
            <scope>importscope>
        dependency>
    dependencies>
dependencyManagement>

2）在商品服务提供者和消费者工程中引入 nacos 客户端依赖，必须删除 eureka-client 依赖（另外在 page 服务中删除 bus-amqp 和 config-client 的依赖，删除完后，把出现报错的注解也一并删除）：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>

3）application.yml 修改，添加 nacos 配置信息：

在 yml 文件中需要删除调用 config 和 eureka 相关的配置，否则启动失败（另外在 page 服务中删除 spring.cloud.config 和 spring.rabbitmq 的配置）。

spring:
  cloud:
    nacos:
      discovery:
        # nacos server 地址
        server-addr: 127.0.0.1:8848

4）启动微服务，观察 nacos 控制台：服务管理 -> 服务列表。

保护阈值：可以设置为 0 - 1 之间的浮点数，它其实是一个比例值（当前服务健康实例数 / 当前服务总实例数）。

场景：

一般流程下，nacos 是服务注册中心，服务消费者要从 nacos 获取某一个服务的可用实例信息，对于服务实例有健康 / 不健康状态之分，nacos 在返回给消费者实例信息的时候，会返回健康实例。这个时候在一些高并发、大流量场景下会存在一定的问题。

如果服务 A 有 100 个实例，98 个实例都不健康了，只有 2 个实例是健康的，如果 nacos 只返回这两个健康实例的信息的话，那么后续消费者的请求将全部被分配到这两个实例，流量洪峰到来，2 个健康的实例也扛不住了，整个服务 A 就扛不住，上游的微服务也会导致崩溃，产生雪崩效应。

保护阈值的意义在于当服务 A 的 健康实例数 / 总实例数 < 保护阈值 的时候，说明健康实例真的不多了，这个时候保护阈值会被触发（状态 true）；Nacos 将会把该服务所有的实例信息（健康的 + 不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也比造成雪崩要好，牺牲了一些请求，保证了整个系统的一个可用。

注意：阿里内部在使用 nacos 的时候，也经常调整这个保护阈值参数。

负载均衡

Nacos 客户端引入的时候，会关联引入 Ribbon 的依赖包，使用 OpenFiegn 的时候也会引入 Ribbon 的依赖，Ribbon 包括 Hystrix 都按原来方式进行配置即可。

此处将商品微服务，再启动了一个 9001 端口，注册到 Nacos 上，便于测试负载均衡，通过后台也可以看出。

启动：

• lagou-server-page

• lagou-server-product

• lagou-server-proudct2

测试：GET http://localhost:9100/page/getPort

Nacos 数据模型（领域模型）

Namespace 命名空间、Group 分组、集群这些都是为了进行归类管理，把服务和配置文件进行归类，归类之后就可以实现一定的效果，比如隔离。

比如，对于服务来说，不同命名空间中的服务不能够互相访问调用。

Namespace 包含 Group
Group 包含 Service/DataId

在一个命名空间中可用定义多个分组，
各个分组之间相互隔离；
每个分组定义多个服务，
每个服务互相隔离。

Namespace：命名空间，对不同的环境进行隔离，比如隔离开发环境、测试环境和生产环境。

Group：分组，将若干个服务或者若干个配置集归为一组，通常习惯一个系统归为一个组。

Service：某一个服务，比如商品微服务。

DataId：配置集或者可以认为是一个配置文件。

Namespace + Group + Service：如同 Maven 中的 GAV 坐标，GAV 坐标是为了锁定 Jar，而这里是为了锁定服务。

Namespace + Group + DataId：如同 Maven 中的 GAV 坐标，GAV 坐标是为了锁定 Jar，而这里是为了锁定配置文件。

Nacos 抽象出了 Namespace、Group、Service、DataId 等概念，具体代表什么取决于怎么用（非常灵活），推荐用法如下：

• Namespace 代表不同的环境，如开发 dev、测试 test、生产环境 prod。
• Group 代表某项目，比如在线商城项目。
• Service 某个项目中具体 xxx 服务。
• DataId 某个项目中具体的 xxx 配置文件。

Nacos 配置中心

之前需要使用 Spring Cloud Config + Bus（配置的自动更新）：

1. Github 上添加配置文件。

2）创建 Config Server 配置中心 --> 从 Github 上去下载配置信息。

3）具体的微服务中配置 Config Client --> ConfigServer 获取配置信息，其为最终使用的配置信息。

有 Nacos 之后，分布式配置就简单很多。

首先，Github 不需要了，配置信息直接配置在 Nacos server 中；然后 Bus 也不需要了，依然可以完成动态刷新。

接下来：

1、去 Nacos Server 中添加配置信息。

2、改造具体的微服务，使其成为 Nacos Config Client，能够从 Nacos Server 中获取到配置信息。

Nacos Server 添加配置

1）打开 Nacos 控制台：http://localhost:8848/nacos。

2）点击“命名空间”菜单，点击“新建命名空间”按钮。

3）输入命名空间名为 test，描述为 测试环境。

4）同样地，新建一个命名空间，名为 dev，描述为 开发环境；然后，再新建另一个命名空间，名为 prod，描述为 生产环境。

5）点开“配置管理”，点击“配置列表”，再点击 “+” 新建配置。

6）输入 Data ID 为 lagou-service-page.yaml，Group 为 DEFAULT_GROUP，配置格式选择 YAML，配置内容为：

renda:
  message: 你好

database:
  type: mysql5.7.3

7）点击“发布”按钮。此时连接 nacos 的微服务就可以获取配置信息了。

微服务中开启 Nacos 配置管理

1）lagou-service-page 添加依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>

2）微服务中如何锁定 Nacos Server 中的配置文件 - dataId。

通过 Namespace + Group + dataId 来锁定配置文件，Namespace 不指定就默认为 public，Group 不指定就默认为 DEFAULT_GROUP。

dataId 的完整格式：

${prefix}-${spring.profile.active}.${file-extension}

• prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。

• spring.profile.active 即为当前环境对应的 profile。 注意：当 spring.profile.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension}。

• file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。

确保配置文件名为 boostrap.yml，配置信息：

Spring:
  application:
    name: lagou-service-page
  cloud:
    nacos:
      discovery:
        # nacos server 地址
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
#        # 命名空间的 ID，当前为 PUBLIC，默认是空，可以注释掉
#        namespace:
#        # 如果使用的默认分组, 可以不设置
#        group: DEFAULT_GROUP

3）通过 Spring Cloud 原生注解 @RefreshScope 实现配置自动更新。

com.renda.page.controller.ConfigClientController

@RestController
@RequestMapping("/config")
@RefreshScope // 手动刷新
public class ConfigClientController {

    // @Value("${mysql.user}")
    // private String user;

    // @Value("${person.name}")
    // private String name;

    @Value("${renda.message}")
    private String message;

    @Value("${database.type}")
    private String type;

    @RequestMapping("/query")
    public String getRemoteConfig() {
        return message + ", " + type;
    }

}

测试：GET http://127.0.0.1:9100/config/query。

测试成功后，在 nacos 控制台更新配置内容，然后重新测试一次，发现数据自动同步更新了。

4）一个微服务希望从配置中心 Nacos server 中获取多个 dataId 的配置信息。

首先，在 Nacos 控制台中新建一个配置，输入 Data ID 为 pageA.yaml，Group 为 DEFAULT_GROUP，配置格式选择 YAML，配置内容为：

pageA:
  pageA

然后，再新建一个配置，输入 Data ID 为 pageB.yaml，Group 为 DEFAULT_GROUP，配置格式选择 YAML，配置内容为：

pageB:
  pageB

接下来，在 boostrap.yml 中引入新建的多个配置：

Spring:
  application:
    name: lagou-service-page
  cloud:
    nacos:
      discovery:
        # nacos server 地址
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
        # 扩展的配置文件
        ext-config[0]:
          data-id: pageA.yaml
          # 启用启动更新
          refresh: true
        ext-config[1]:
          data-id: pageB.yaml
          # 启用启动更新
          refresh: true

最后，更新 com.renda.page.controller.ConfigClientController：

@RestController
@RequestMapping("/config")
@RefreshScope // 手动刷新
public class ConfigClientController {

    @Value("${renda.message}")
    private String message;

    @Value("${database.type}")
    private String type;

    @Value("${pageA}")
    private String pageA;

    @Value("${pageB}")
    private String pageB;

    @RequestMapping("/query")
    public String getRemoteConfig() {
        return "ConfigClientController{" +
                "message='" + message + '\'' +
                ", type='" + type + '\'' +
                ", pageA='" + pageA + '\'' +
                ", pageB='" + pageB + '\'' +
                '}';
    }

}

测试：GET http://127.0.0.1:9100/config/query。

测试成功后，在 nacos 控制台更新多个配置的内容，然后重新测试一次，发现数据也能自动同步更新了。

SCA Sentinel 分布式系统的流量防卫兵

Sentinel 介绍

Sentinel 是一个面向云原生微服务的流量控制、熔断降级组件，替代 Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流。

服务消费者（静态化微服务）–> 调用服务提供者（商品微服务），在调用方引入 Hystrix：

1）自己搭建监控平台 dashboard。

2）没有提供 UI 界面进行服务熔断、服务降级等配置（使用的是 @HystrixCommand 参数进行设置，代码入侵）。

Sentinel：

1）独立可部署 Dashboard / 控制台组件（其实就是一个 jar 文件，直接运行即可）。

2）减少代码开发，通过 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 部署

下载地址：https://github.com/alibaba/Sentinel/releases，使用 v1.7.1。

启动：java -jar sentinel-dashboard-1.7.1.jar &。

使用浏览器访问，如：http://localhost:8080。

用户名 / 密码：sentinel / sentinel。

服务改造

在已有的业务场景中，“静态化微服务”调用了“商品微服务”，在静态化微服务进行的熔断降级等控制，那么接下来改造静态化微服务，引入 Sentinel 核心包。

为了不污染之前的代码，复制一个页面静态化微服务命名为 lagou-service-page-sentinel，端口号 9101。

pom.xml 引入依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-sentinelartifactId>
dependency>

application.yml 修改（配置 sentinel dashboard，删除原有 hystrix 配置，删除原有 OpenFeign 的降级配置）：

server:
  port: 9101
Spring:
  # 解决 bean 重复注册问题
  main:
    allow-bean-definition-overriding: true
  application:
    name: lagou-service-page
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
        ext-config[0]:
          data-id: pageA.yaml
          refresh: true
        ext-config[1]:
          data-id: pageB.yaml
          refresh: true
    sentinel:
      transport:
        # 指定 sentinel 控制台的地址
        dashboard: 127.0.0.1:8080
        # 在微服务运行时会启动一个 Http Server，该 Server 的作用就是与 sentinel 的 dashboard 进行交互 push
        port: 8719

...

上述配置之后，启动静态化微服务 lagou-service-page-sentinel，使用 Sentinel 监控静态化微服务。

此时发现控制台没有任何变化，因为懒加载，只需要发起一次请求触发即可。

Sentinel 关键概念

• 资源 - 它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。请求的 API 接口就是资源。
• 规则 - 围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

Sentinel 流量规则模块

系统并发能力有限，比如系统 A 的 QPS 支持 1 个，如果太多请求过来，那么 A 就应该进行流量控制了，比如其他请求直接拒绝。

访问 Sentinel 的控制台：http://localhost:8080，执行新增流控规则，然后会有弹窗来填写信息：

资源名：默认请求路径。

针对来源：Sentinel 可以针对调用者进行限流，填写微服务名称，默认 default（不区分来源）。

阈值类型 / 单机阈值：
+ QPS（每秒钟请求数量）当调用该资源的 QPS 达到阈值时进行限流。
+ 线程数：当调用该资源的线程数达到阈值的时候进行限流（线程处理请求的时候，如果说业务逻辑执行时间很长，流量洪峰来临时，会耗费很多线程资源，这些线程资源会堆积，最终可能造成服务不可用，进一步上游服务不可用，最终可能服务雪崩）。

是否集群：是否集群限流。

流控模式：
+ 直接 - 资源调用达到限流条件时，直接限流。
+ 关联 - 关联的资源调用达到阈值时候限流自己。
+ 链路 - 只记录指定链路上的流量。

流控效果：
+ 快速失败 - 直接失败，抛出异常
+ Warm Up - 根据冷加载因子（默认3）的值，从阈值/冷加载因子，经过预热时长，才达到设置的 QPS 阈值
+ 排队等待 - 匀速排队，让请求匀速通过，阈值类型必须设置为QPS，否则无效流控模式之关联限流

流控模式之直连限流

• 创建一个流控规则，QPS 阈值设置为 1；然后使用 Postman 一秒发起十个请求，可以看到，只有一个请求通过，其余九个都被限制了。

在 lagou-service-page-sentinel 的 com.renda.page.controller.PageController 中增加休眠代码：

@RestController
@RequestMapping("/page")
public class PageController {

    @Autowired
    private ProductFeign productFeign;

    @GetMapping("/loadProductServicePort")
    public String getProductServerPort() {
        try {
            // 休眠 5 秒
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return productFeign.getPort();
    }

    ...
}

• 然后修改流控规则，设置阈值类型为线程数，并设置阈值为 1；然后使用 Postman 一秒发起两个请求（GET http://localhost:9101/page/loadProductServicePort），可以看到第二次请求被限制了。

流控模式之关联限流

关联的资源调用达到阈值时候限流自己，比如用户注册接口，需要调用身份证校验接口（往往身份证校验接口），如果身份证校验接口请求达到阈值，使用关联，可以对用户注册接口进行限流。

为了模拟这个场景，在 lagou-service-page-sentinel 中新建 com.renda.page.controller.UserController：

@RestController
@RequestMapping("/user")
public class UserController {

    /**
     * 用户注册接口
     */
    @GetMapping("/register")
    public String register() {
        String now = new SimpleDateFormat("yyyy/MM/dd mm:ss").format(new Date());
        System.out.println(now);
        System.out.println("Register success!");
        return "Register success!";
    }

    /**
     * 验证注册身份证接口（需要调用公安户籍资源）
     */
    @GetMapping("/validateID")
    public String validateID() {
        System.out.println("validateID");
        return "ValidateID success!";
    }

}

• 新建一个流控规则，资源名为 /user/register，阈值类型选 QPS，单机阈值为 1，流控模式选择“关联”，关联资源为 /user/validateID；然后使用 Postman 模拟密集式请求 /user/validateID 验证接口，会发现 /user/register 接口也被限流了。

流控模式之链路限流

链路指的是请求链路（调用链：C --> B --> A，D --> E --> A）。

链路模式下会控制该资源所在的调用链路入口的流量。需要在规则中配置入口资源，即该调用链路入口的上下文名称。

一棵典型的调用树：

                  machine-root
                    /       \
                   /         \
             Entrance1     Entrance2
                /              \
               /                \
      DefaultNode(nodeA)     DefaultNode(nodeA)

上图中来自入口 Entrance1 和 Entrance2 的请求都调用到了资源 NodeA ，Sentinel 允许只根据某个调用入口的统计信息对资源限流。比如链路模式下设置入口资源为 Entrance1 来表示只有从入口 Entrance1 的调用才会记录到 NodeA 的限流统计当中，而不关心经 Entrance2 到来的调用。

指定入口资源，进行限流统计时，只统计入口进来的流量。

流控效果之 Warm up

当系统长期处于空闲的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮，比如电商网站的秒杀模块。

通过 Warm Up 预热模式，让通过的流量缓慢增加，经过设置的预热时间以后，到达系统处理请求速率的设定值。

Warm Up 模式默认会从设置的 QPS 阈值的 1/3 开始慢慢往上增加至 QPS 设置值；预热时长默认为秒。

• 新建流控规则，资源名为 /user/register， 设置 QPS 阈值为 10，流控效果选择“Warm Up”，预热时长为 10；然后使用 Postman 即可测试预热效果。

流控效果之排队等待

排队等待模式下会严格控制请求通过的间隔时间，即请求会匀速通过，允许部分请求排队等待，通常用于消息队列削峰填谷等场景。需设置具体的超时时间（以毫秒为单位），当计算的等待时间超过超时时间时请求就会被拒绝。

使用的是漏桶算法。

很多流量过来了，并不是直接拒绝请求，而是请求进行排队，一个一个匀速通过（处理），请求能等就等着被处理，不能等（等待时间 > 超时时间）就会被拒绝

例如，QPS 配置为 5，则代表请求每 200 ms 才能通过一个，多出的请求将排队等待通过。超时时间代表最大排队时间，超出最大排队时间的请求将会直接被拒绝。排队等待模式下，QPS 设置值不要超过 1000（请求间隔 1 ms）。

Sentinel 降级规则模块

流控是对外部来的大流量进行控制，熔断降级的视角是对内部问题进行处理。

Sentinel 降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断，这里的降级其实是 Hystrix 中的熔断。

Sentinel 不会像 Hystrix 那样放过一个请求尝试自我修复，就是明明确确按照时间窗口来，熔断触发后，时间窗口内拒绝请求，时间窗口后就恢复。

降级策略有：RT 平均响应时间 、异常比例、异常数。

RT 平均响应时间

如果设置 RT 为 200，时间窗口为 5，则当 1s 内持续进入 >= 5 个请求，平均响应时间超过 200 阈值（以 ms 为单位），那么在接下的时间窗口 5（以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。

注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

前提条件：
1. 一秒持续进入 5 个及以上的请求。
2. 平均响应时间大于阈值。

满足前提条件 
----> 触发降级（熔断跳闸）
----> 时间窗口结束
----> 关闭降级

异常比例

当资源的每秒请求量 >= 5，并且每秒异常总数占通过量的比值超过阈值之后，资源进入降级状态，即在接下的时间窗口（以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

前提条件：
1. 一秒持续进入 5 个及以上的请求。
2. 异常比例大于阈值。

满足前提条件 
----> 触发降级（熔断跳闸）
----> 时间窗口结束
----> 关闭降级

异常数

当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态，时间窗口 >= 60s。

前提条件：
分钟内统计异常数超过设定阈值。

满足前提条件 
----> 触发降级（熔断跳闸）
----> 时间窗口结束
----> 关闭降级

SCA 总结

SCA 提供的三套组件：

• 开源出来的一些组件。
• 阿里内部维护了一个分支，自己业务线使用。
• 阿里云平台部署一套，付费使用。

从战略上来说，SCA 更是为了贴合阿里云。

目前来看，开源出来的这些组件，推广及普及率不高，社区活跃度不高，稳定性和体验度上仍需进一步提升，根据实际使用来看 Sentinel 的稳定性和体验度要好于 Nacos。

想了解更多，欢迎关注我的微信公众号：Renda_Zhang