Alibaba Sentinel

一.介绍

Sentinel 是由阿里巴巴开源的一个面向分布式、多语言异构化服务架构的流量治理组件。主要以流量为切入点，从流量路由、流量控制 、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

Sentinel分为两个部分：

|----------------|-----------------------------------------------------------------|
| 核心库(Java 客户端) | 不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo /Spring Cloud 等框架也有较好的支持 |
| 控制台(Dashboard) | 基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器 |

Sentinel 官方提供了一个轻量级的开源控制台，方便我们观察和操作，可以通过下面的地址下载Sentinel Dashboard：Releases · alibaba/Sentinel

打开CMD，使用下面的命令启动 jar 包：

java -jar .\sentinel-dashboard-1.8.9.jar

可以访问127.0.0.1:8080，默认的用户名和密码都是 sentinel ：

当然可以修改端口号和账号密码：

java -jar -Dserver.port=8100 -Dsentinel.dashboard.auth.username=admin -
Dsentinel.dashboard.auth.password=admin -
Dserver.servlet.session.timeout=1440m sentinel-dashboard-1.8.9.jar

更多配置信息查看：dashboard | Sentinel

二.快速入门

1.添加依赖

添加 Sentinel 核心库：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
</dependency>

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2.定义资源

资源是 Sentinel 的关键概念，被 Sentinel 监控的每个接口就是一个资源。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。限流，熔断等都是针对资源来设置的。

private static void test(int i) {
    try(Entry entry = SphU.entry("resourceName")){
        //业务逻辑处理
        System.out.println("执⾏test⽅法"+ i);
    } catch (BlockException e) {
        //处理限流时的逻辑
        System.out.println("触发限流.." +i );
    }
}

在test方法中，通过使用 Sentinel 中的 SphU.entry("resourceName") 定义一个资源，方便后续配置流控规则。

它表示当请求进行test方法时，需要进行限流判断，如果抛出 BlockException 异常，则表示触发了限流。

3.针对该资源定义限流规则

对资源 resourceName 设置QPS不超过10：

private static void initFlowRules() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource("resourceName");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setCount(10);
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

针对资源 resourceName 设置限流规则：

|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| resource | 资源名称 |
| Grade | 限流阈值类型。QPS模式(1) 或并发线程数模式(0) 1）RuleConstant.FLOW_GRADE_QPS : 默认的流量控制阈值类型，表示每秒请求次数(QPS)。当设置 grade 为 RuleConstant.FLOW_GRADE_QPS 时，Sentinel会根据设置的QPS值来控制流量 2）RuleConstant.FLOW_GRADE_THREAD ：并发线程数。当设置 grade 为RuleConstant.FLOW_GRADE_THREAD 时，Sentinel会根据设置的并发线程数来控制流量 |
| count | 限流阈值 |

4.调用资源，校验规则是否生效

public static void main(String[] args) {
    initFlowRules();
    for (int i = 0; i < 20; i++) {
        test(i);
    }
}

测试结果：

三.流量控制

下面测试会用到JMeter，如果还不知道怎么用的话可以看看我的这篇文章：【快速入门】JMeter

1.配置流控规则

选择流控，如果测试的多可以将阈值调成1：

进行测试，快速请求接口触发限流：

2.基于QPS/并发数的流量控制

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

关于并发线程数

线程数限流用于保护业务线程数不被耗尽。

比如A调用B，而B服务因为某种原因导致服务不稳定或响应延迟，那么对于A服务来说，它的吞吐量会下降，也意味着占用更多的线程（线程阻塞之后⼀直末释放），极端情况会造成线程池耗尽。

针对这种问题，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离），或者使用信号量来控制同时请求的个数（信号量隔离）。

这种隔离方案虽然能够控制线程数量，但无法控制请求排队时间。当请求过多时排队也是无意的，直接拒绝能够迅速降低系统压力。如果超出阈值，新的请求会被立即拒绝。

关于QPS流量控制

当 QPS 超过某个阈值的时候，则进行流量控制。流量控制的手段分为三种：快速失败，Warm Up，排队等待。

3.流控效果

流量超过配置的阈值时，会采用流量控制，流量控制的手段分为三种：

对应对应 FlowRule 中的 controlBehavior 字段。取值分别为：

|---------|--------------------------------------------|
| 快速失败 | RuleConstant.CONTROL_BEHAVIOR_DEFAULT |
| Warm Up | RuleConstant.CONTROL_BEHAVIOR_WARM_UP |
| 排队等待 | RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER |

下面测试一些这三种手段：

快速失败

快速失败（直接拒绝） ，对应 RuleConstant.CONTROL_BEHAVIOR_DEFAULT 。该方法是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException 。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位。

上面举的例子适用的就是快速失败。

Warm Up

Warm up ，对应 RuleConstant.CONTROL_BEHAVIOR_WARM_UP 。Warm Up 也叫预热模式。阈值一般是一个微服务能承受的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化，如果直接将QPS跑到最大值，可能导致服务瞬间宕机。

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

下面进行测试，设置单机阈值设置为10，Warm Up 模式，预热时长为5s，可以理解为系统在5s后单机阈值逐渐增长到10：

查看测试结果：

排队等待

排队等待 ，对应 RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER 。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过。可以理解为让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后面的请求必须等待前面执行完成，直到超时。

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

超时时间也就是请求等待时长。

比如阈值为1，那么每秒执行一个请求。超时时间为5s。现在一下子来了10个请求，那么:

第3个请求的 等待时长为: 100 * (3-1) = 2000ms

第6个请求的 等待时长为: 100 * (6-1) = 5000ms

也就是说，同一时间发起10个请求，那么会通过6个，拒绝4个。

执行结果：

4.流控模式

流控模式分为三种：直接 ，关联 ，链路

调用关系包括调用方，被调用方。方法又可能会调用其它方法，形成一个调用链路的层次关系。 Sentinel记录资源之间的调用链路，这些资源通过调用关系，相互之间构成一棵调用树。

Sentinel根据这些调用关系，建立不同资源间的调用关系，并记录每个资源的实时统计信息。有了调用链路的统计信息，我们可以衍生出多种流量控制手段。

根据调用方限流

也就是上述流控模式中的: **直接**

这是默认的流量控制方式。当QPS超过任意规则的阈值后，对当前资源直接限流。

根据调用链路入口限流

也就是上述流控模式中的: **链路**

链路限流是指：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流。

针对资源添加链路流控规则，只针对入口资源 为 /order/read 的请求进行限流：

查看结果：

具有关系的资源流量控制

也就是上述流控模式中的: **关联**

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。

关联限流就是统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。

比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写的速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢。

当 /order/wirte 资源访问量触发阈值时, 就会对 /order/read 资源限流，避免影响 /order/wirte 资源（看好了关系）：

read接口被限流了：

四.热点参数限流

热点即经常访问的数据。

在上面的配置中，对一个接口进行限流，所有的请求参数一视同仁，只要达到阈值，就一起限流。

热点参数限流 会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

对 /sentinel/id 这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5：

参数索引：资源热点参数的索引，从0开始。

参数分别为1，2，3 的请求，阈值达到5后，就被限流了：

上述的热点参数配置中，所有的参数一视同仁，QPS都被限定为5，但是在一些场景下，我们希望可以对某些热点参数进行单独限流，例如有一些热点商品，比如排名比较靠前的，访问次数比较多，我们希望可以对这个热点商品进行单独限流，让他的阈值高一些或者低一些，就需要使用到热点参数限流规则里面的高级选项了。

参数1的QPS限流阈值为8，参数2的限流阈值为15，其他的参数为5：

配置说明：

|-------|----------------------------------------------------|
| 单机阈值 | 对第一个参数的值进行统计，当相同值参数阈值超过5时，进行限流 |
| 参数例外项 | 针对一些特殊的参数，进行单独设置 |
| 参数类型 | 热点参数的类型，只支持 int、double、String、long、float、char、byte |
| 参数值 | 特殊的参数值 |
| 限流阈值 | 对这个参数进行额外的阈值设置 |

五.熔断降级

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。

一个服务常常会调用别的模块，可能是另一个远程服务，数据库，或者第三方 API 等。例如：支付的时候，可能需要远程调用银联提供的 API。查询某个商品的价格，可能需要进行数据库查询。

现代微服务架构都是分布式的，由非常多的服务组成。不同服务之间相互调用，组成复杂的调用链路。复杂链路上的某一环不稳定，就可能会层层级联，最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务调用进行熔断，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。

熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

Sentinel 提供了三种熔断策略：

|----------------------------------|-------------------------------------------------------------------------------------------|
| 慢调用比例 ( SLOW_REQUEST_RATIO ) | 需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。在指定时间内，如果请求数量 > 设定的最小数量，且慢调用比例 > 设定的阈值，则触发熔断 |
| 异常比例（ ERROR_RATIO ） | 指定时间内，请求数量 > 设置的最小数量，且异常比例大于阈值，则触发熔断 |
| 异常数（ ERROR_COUNT ） | 指定时间内，异常数目超过阈值后，则触发熔断 |

1.状态机

熔断的思路是由断路器（或者叫熔断器）统计服务调用的慢请求比例，异常比例等，如果超过阈值，则熔断该服务，也就是拦截对该服务的请求，当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断 和放行 是通过状态机 来完成的，状态机有三个状态：

|---------------|---------------------------------------------------------------------------------------------------------------------|
| Closed | 关闭状态，所有请求都会通过断路器，并开始统计慢请求比例，异常比例，超过阈值则切换到open状态 |
| Open | 打开状态，服务调用被熔断。这时所有 访问被熔断服务的请求 都会被拒绝 |
| Half-open | 半开状态，当经过一段时间后，断路器会从Open状态切换到Half-open状态，这时会有一定数量的请求被放入，根据这些请求的失败率来判断后续操作： ◦ 失败率低于阈值：切换到closed状态 ◦ 失败率超过阈值：切换到open状态 |

2.慢调用比例

慢调用比例：需要设置允许的慢调用RT，也就是最大响应时间。

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

下面简单测试一下：

上述配置表示：超过50ms的调用是慢调用，统计最近10000内的请求，如果请求量超过5次，并且慢调用比例不低于0.5，则触发熔断。熔断时长为5s，然后进入 half-open 状态，放行一次请求做测试。

3.降级

当调用失败后，业务直接报错，给用户体验不太好，应该返回用户一个友好提示或者默认结果，这个就是降级。降级通常有以下方式：

|-------------------------------|
| 捕获异常，根据异常进行降级逻辑处理 |
| 通过FallbackFactory，对远程调用的异常做处理 |

第一种方式更通用，适合各种场景，第二种方式需要远程调用的服务进行处理。这两种方式在服务开发中经常搭配着使用。

捕获异常

@SentinelResource("/sentinel/id")
@RequestMapping("/{orderId}")
public OrderInfo getOrderById(@PathVariable("orderId") Integer orderId){
    try {
        OrderInfo orderInfo = orderService.selectOrderById(orderId);
        return orderInfo;
    }catch (UndeclaredThrowableException e){
        log.error("获取订单详情失败");
        return new OrderInfo();
    }
    return orderService.selectOrderById(orderId);
}

FallbackFactory

FallbackFactory 是一个在微服务架构中用于实现服务降级的接口，当远程服务调用失败或超时，FallbackFactory 会根据提供的异常信息创建一个降级处理实例，以替代原服务调用。并且可以根据错误类型，返回不同的降级响应。

定义降级逻辑：

@Slf4j
public class ProductFallbackFactory implements FallbackFactory<ProductApi> {
    @Override
    public ProductApi create(Throwable cause) {
        return new ProductApi() {
            @Override
            public ProductInfo getProductInfo(Integer productId) {
                log.error("获取商品信息失败");
                return new ProductInfo();
            }

            @Override
            public String p1(Integer id) {
                log.error("p1 请求失败");
                return "p1 请求失败";
            }

            @Override
            public String p2(Integer id, String name) {
                log.error("p2 请求失败");
                return "p2 请求失败";
            }

            @Override
            public String p3(ProductInfo productInfo) {
                log.error("p3 请求失败");
                return "p3 请求失败";
            }

            @Override
            public String p4(ProductInfo productInfo) {
                log.error("p4 请求失败");
                return "p4 请求失败";
            }
        };
    }
}

4.异常比例

异常比例 ( ERROR_RATIO )：统计单位时长（ statIntervalMs ）内，请求数目 > 最小请求数目，并且异常的比例 > 阈值，则触发熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态)，若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

5.异常数

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

六.授权规则

**存在问题：**目前订单项目，直接就可以通过浏览器访问，获取订单的信息，这样很不安全。

**解决方案：**微服务架构中，许多系统包含敏感信息，如个人身份信息，财务数据，商业机密等。只有经过验证或者授权的用户才可以访问这些数据。比如在医疗系统中，只有授权的医生和护士可以查看患者的病历。

授权规则是对请求者的身份进行判断，决定是否允许该请求访问特定资源。

Sentinel提供了两种授权模式：

|-----|--------------------------------|
| 白名单 | 请求来源位于白名单内的调用者才允许访问 |
| 黑名单 | 请求来源位于黑名单内的调用者不允许访问，其余请求通过 |

Sentinel 根据来源来进行判断，所以调用方需要设置来源，被调用方需要获取来源。

Sentinel 进行授权管理，主要分以下几步：

|------------------|
| 1. 服务端（被调用方）获取来源 |
| 2. 客户端（调用方）设置来源 |
| 3. 配置授权规则，即黑白名单 |

设置一个白名单：

此时我们再使用127.0.0.1:9091/order/1就访问不了了：

使用网关gateway就可以访问了：

七.定义异常返回结果

这个其实上面我一直都在用，其实本来被限流了或被降级了，返回的结果不是这个，是英文：

我们可以自定义异常返回的结果，这样也方便调用方明白发生了什么。

Sentinel提供了一个接口 BlockExceptionHandler ，用于自定义处理 BlockException 异常。当请求被 Sentinel 限流、降级或授权拒绝时，会抛出 BlockException 。通过实现BlockExceptionHandler接口，可以定义统一的异常处理逻辑，返回更友好的错误信息或执行特定的降级操作。

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest httpServletRequest, HttpServletResponse response, BlockException e) throws Exception {
        response.setContentType("text/html; charset=utf-8");
        PrintWriter out = response.getWriter();

        int status = 429;
        String msg = "Blocked by Sentinel (flow limiting)";

        if (e instanceof AuthorityException) {
            status = 401;
            msg = "授权失败, 请联系服务端进行配置";
        }else if(e instanceof DegradeException){
            msg = "触发降级规则, 请联系服务端进行配置";
        }else if(e instanceof FlowException){
            msg = "触发限流规则, 请联系服务端进行配置";
        }else if(e instanceof ParamFlowException){
            msg = "触发热点限流规则, 请联系服务端进行配置";
        }

        response.setStatus(status);
        out.print(msg);
        out.flush();
        out.close();
    }
}

八.规则管理及推送

不知道大家有没有发现一个问题，就是服务重启后，我们之前设定的规则就会消失。这是因为Sentinel 默认是将这些管理规则保存在内存中，在生产环境中，这个问题是不可接受的。规则的丢失会导致系统失去流量控制和保护机制。

生产环境中，Sentinel需要规则持久化，sentinel-core 提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式。同时，规则最好在控制台中集中管理。

更多请参考官方文档：在生产环境中使用 Sentinel · alibaba/Sentinel Wiki

一般来说，规则的推送有下面三种模式：

|---------|----------------------------------------------------------------------------------------------------------------------------|----------------|---------------------------------|
| 推送模式 | 说明 | 优点 | 缺点 |
| 原始模式 | API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource） | 简单，无任何依赖 | 不保证一致性；规则保存在内存中，重启即消失。不建议用于生产环境 |
| Pull 模式 | 扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等 | 简单，无任何依赖；规则持久化 | 不保证一致性；实时性不保证，拉取过于频繁可能会有性能问题 |
| Push 模式 | 扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源 | 规则持久化；一致性；快速 | 引入第三方依赖 |

1.原始模式

如果不做任何修改，Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中。

2.Pull 模式

Pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的WritableDataSourceRegistry 中。

以本地文件数据源为例：

1）注册数据源

public class FileDataSourceInit implements InitFunc {

    @Override
    public void init() throws Exception {
        String rulePath = System.getProperty("user.home") + "/sentinel/rules/order-service";
        //流控文件
        String flowRulePath = rulePath + "/flow-rule.json";

        mkdirIfDirExist(rulePath);
        createFileIfExist(flowRulePath);

        ReadableDataSource<String, List<FlowRule>> ds = new FileRefreshableDataSource<>(
                flowRulePath, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {})
        );
        // 将可读数据源注册至 FlowRuleManager.
        FlowRuleManager.register2Property(ds.getProperty());

        WritableDataSource<List<FlowRule>> wds = new FileWritableDataSource<>(flowRulePath, this::encodeJson);
        // 将可写数据源注册至 transport 模块的 WritableDataSourceRegistry 中.
        // 这样收到控制台推送的规则时，Sentinel 会先更新到内存，然后将规则写入到文件中.
        WritableDataSourceRegistry.registerFlowDataSource(wds);
    }

    private void createFileIfExist(String filePath) throws IOException {
        File file = new File(filePath);
        if (!file.exists()){
            file.createNewFile();
        }
    }

    private void mkdirIfDirExist(String rulePath) {
        File file = new File(rulePath);
        if (!file.exists()){
            file.mkdirs();
        }
    }

    private <T> String encodeJson(T t) {
        return JSON.toJSONString(t);
    }
}

2）配置数据源路径

在 resources 下创建 META-INF/services 目录，并创建文件：com.alibaba.csp.sentinel.init.InitFunc，写本地数据源的路径。

3.Push 模式

生产环境下一般更常用的是 Push 模式的数据源。对于 Push 模式的数据源，如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：

借助 Sentinel 的 InitFunc SPI 扩展接口。只需要实现自己的 InitFunc 接口，在 init 方法中编写注册数据源的逻辑。

1）添加依赖

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2）注册数据源

public class NacosDatasourceInit implements InitFunc {
    @Override
    public void init() throws Exception {
        // remoteAddress 代表 Nacos 服务端的地址
        // groupId 和 dataId 对应 Nacos 中相应配置
        final String remoteAddress = "127.0.0.1:8848";
        final String groupId = "SENTINEL_GROUP";
        final String dataId = "order-service-flow-rule";


        ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = new NacosDataSource<>(remoteAddress, groupId, dataId,
                source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));
        FlowRuleManager.register2Property(flowRuleDataSource.getProperty());
    }
}

3）配置数据源路径

在 resources下创建 META-INF/services 目录，并创建文件：com.alibaba.csp.sentinel.init.InitFunc ，写本地数据源的路径

4）配置Nacos

5）验证结果

重启服务，会发现 Sentinel Dashboard 已经从 Nacos 获取规则配置信息了。修改Nacos文件，发现Sentinel Dashboard 会及时更新。通过Sentinel Dashboard修改规则，发现Nacos配置文件并没有同步更新。