【Spring Cloud】Spring Cloud Alibaba Sentinel
Sentinel 简介
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Sentinel 具有以下特征:
- 丰富的应用场景:Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控:Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
- 完善的 SPI 扩展点:Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性:
Hystrix 与 Sentinel 比较:
- Hystrix(【Spring Cloud】Hystrix)
- 需要我们程序员自己手工搭建监控平台
- 没有一套web界面可以给我们进行更加细粒度化得配置流控、速率控制、服务熔断、服务降级
- Sentinel
- 单独一个组件,可以独立出来。
- 直接界面化的细粒度统一配置。
sentinel
英 [ˈsentɪnl] 美 [ˈsentɪnl]
n. 哨兵
服务使用中的各种问题:
- 服务雪崩
- 服务降级
- 服务熔断
- 服务限流
Sentinel 分为两个部分:
- 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有 Java 运行时环境,同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
- 控制台(Dashboard)基于 Spring Boot 开发,打包后可以直接运行,不需要额外的 Tomcat 等应用容器。
服务熔断框架对比
Sentinel 下载安装运行
下载地址:https://github.com/alibaba/Sentinel/release
安装步骤:
- 下载到本地
sentinel-dashboard-1.7.0.jar
- 运行命令
java -jar sentinel-dashboard-1.7.0.jar
前提:
- Java 8 环境
- 8080端口不能被占用
进入Sentinel管理界面方式:访问 http://localhost:8080,登录账号密码均为sentinel
Sentinel 实时监控
- 启动Nacos服务中心(见文章【Spring Cloud】Spring Cloud Alibaba Nacos)
- 新建Module:
cloudalibaba-sentinel-service8401
- 导入Maven依赖:
1 |
|
- 配置文件:
1 | server: |
- 主启动类:
1 | import org.springframework.boot.SpringApplication; |
- 业务类 FlowLimitController:
1 | import com.alibaba.csp.sentinel.annotation.SentinelResource; |
- 启动Sentinel Dashboard:
java -jar sentinel-dashboard-1.7.0.jar
- 测试:发出请求 http://localhost:8401/testA 后,可在Sentinel Dashboard看到监控中的微服务8401
Sentinel 流控规则
流控规则
Sentinel 流控:控制流量访问的规则,超出限制的流量禁止访问,从而达到限流的目的。
进一步解释说明:
- 资源名:唯一名称,默认请求路径。
- 针对来源:Sentinel可以针对调用者进行限流,填写微服务名,默认default(不区分来源)。
- 阈值类型/单机阈值:
- QPS(每秒钟的请求数量)︰当调用该API的QPS达到阈值的时候,进行限流。
- 线程数:当调用该API的线程数达到阈值的时候,进行限流。
- 是否集群:不需要集群。
- 流控模式:
- 直接:API达到限流条件时,直接限流。
- 关联:当关联的资源达到阈值时,就限流自己。
- 链路:只记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就进行限流)【API级别的针对来源】。
- 流控效果:
- 快速失败:直接失败,抛异常。
- Warm up:根据Code Factor(冷加载因子,默认3)的值,从阈值/codeFactor,经过预热时长,才达到设置的QPS阈值。
- 排队等待:匀速排队,让请求以匀速的速度通过,阈值类型必须设置为QPS,否则无效。
QPS 直接失败
QPS(每秒钟的请求数量),系统默认为直接 -> 快速失败:
上图配置表示1秒钟内查询1次就是OK,若超过次数1,就直接->快速失败,报默认错误 Blocked by Sentinel (flow limiting)
。
线程数直接失败
线程数:当调用该请求的线程数达到阈值的时候,进行限流。
关联
关联模式下,当自己关联的资源达到阈值时,就限流自己。例如当与A关联的资源B达到阀值后,就限流A自己(B惹事,A挂了)
链路
只记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就进行限流)【API级别的针对来源】
预热 Warm Up
Warm Up(RuleConstant.CONTROL_BEHAVIOR_WARM_UP
)方式,即预热/冷启动方式。当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮。详细文档可以参考流量控制 - Warm Up 文档,具体的例子可以参见 WarmUpFlowDemo。
通常冷启动的过程系统允许通过的 QPS 曲线如下图所示:
默认coldFactor
为3,即请求QPS 从 threshold / 3
开始,经预热时长逐渐升至设定的QPS阈值。
WarmUp配置案例,阀值为10 + 预热时长设置5秒:
系统初始化的阀值为 10 / 3
约等于3,即阀值刚开始为3。然后过了5秒后阀值才慢慢升高恢复到10:
应用场景
如:秒杀系统在开启的瞬间,会有很多流量上来,很有可能把系统打死,预热方式就是把为了保护系统,可慢慢的把流量放进来,慢慢的把阀值增长到设置的阀值。
排队等待
匀速排队,让请求以均匀的速度通过,阀值类型必须设成QPS,否则无效。
设置:/testA
每秒1次请求,超过的话就排队等待,等待的超时时间为20000毫秒:
匀速排队
匀速排队(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。详细文档可以参考 流量控制 - 匀速器模式,具体的例子可以参见 PaceFlowDemo。
这种方式主要用于处理间隔性突发的流量,例如消息队列。想象一下这样的场景,在某一秒有大量的请求到来,而接下来的几秒则处于空闲状态,我们希望系统能够在接下来的空闲期间逐渐处理这些请求,而不是在第一秒直接拒绝多余的请求。
测试:添加日志记录代码到FlowLimitController
的testA
方法
1 |
|
Postman模拟并发密集访问 /testA
。后台显示:
@SentinelResource 服务限流配置
方式1:指定资源名:
在 Controller 上使用 @SentinelResource 注解修饰目标方法,并设置资源名:value = "byResource"
,同时设置满足限流条件时的回调方法blockHandler = "handleException"
:
1 | import com.alibaba.csp.sentinel.annotation.SentinelResource; |
在控制台为该资源 "byResource"
设置流控规则,表示1秒钟内查询次数大于1,就跳转到blockHandler
指定的handleException()
方法:
方式2:指定URL:
1 |
|
可以在流控规则中指定URL,这样符合该URL的请求在满足条件时都会调用自定义的方法:
注意:blockHandler
只能处理限流和降级相关的异常 BlockException
,若是业务本身出现异常则不会响应 blockHandler
指定的方法,此情况需要使用 fallback
属性。
Sentinel 服务降级规则
熔断降级概述
除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库,或者第三方 API 等。例如,支付的时候,可能需要远程调用银联提供的 API;查询某个商品的价格,可能需要进行数据库查询。然而,这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用。
现代微服务架构都是分布式的,由非常多的服务组成。不同服务之间相互调用,组成复杂的调用链路。以上的问题在链路调用中会产生放大的效果。复杂链路上的某一环不稳定,就可能会层层级联,最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务调用进行熔断降级,暂时切断不稳定调用,避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段,通常在客户端(调用端)进行配置。
服务熔断和服务降级的区别:
- 服务降级是在服务执行的时候,出现超时或异常等情况中断执行,转去执行fallback里的代码
- 服务熔断是在开启熔断机制后,服务不再尝试执行,而是直接进入fallback里的代码
Sentinel 服务降级规则
- RT(平均响应时间,毫秒级)
- 平均响应时间超出阈值且
QPS >= 5
(在1s时间窗口内通过的请求>=5),两个条件同时满足后触发降级 - 窗口期过后关闭断路器
- RT最大4900(更大的需要通过
-Dcsp.sentinel.statistic.max.rt=XXXX
才能生效)
- 平均响应时间超出阈值且
- 异常比列(秒级):
QPS >= 5
且异常比例(秒级统计)超过阈值时触发降级;时间窗口结束后,关闭降级 - 异常数(分钟级):异常数(分钟统计)超过阈值时,触发降级;时间窗口结束后,关闭降级
Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。
当资源被降级后,在接下来的降级时间窗口之内,对该资源的调用都自动熔断(默认行为是抛出 DegradeException
)。
1.7.0版本的 Sentinel 的断路器是没有类似Hystrix半开状态的(Sentinei 1.8.0 已有半开状态)。半开的状态系统自动去检测是否请求有异常,没有异常就关闭断路器恢复使用,有异常则继续打开断路器不可用。断路器的介绍见【Spring Cloud】Hystrix。
Sentinel 降级策略 - RT
Sentinel 1.7.0 版本的平均响应时间(DEGRADE_GRADE_RT
):
RT 平均响应时间(DEGRADE_GRADE_RT
):当1s内持续进入5个请求,对应时刻的平均响应时间均超过阈值( count,以ms为单位),那么在接下的时间窗口(DegradeRule
中的timeWindow
,以s为单位)之内,对这个方法的调用都会自动地熔断(抛出DegradeException
)。注意 Sentinel 默认统计的RT上限是4900 ms,超出此阈值的都会算作4900ms,若需要变更此上限可以通过启动配置项-Dcsp.sentinel.statistic.max.rt=xxx
来配置。窗口期时间到了,自动结束熔断。
Sentinel 1.8.0 没有平均响应时间,取而代之的是慢调用比例 (SLOW_REQUEST_RATIO
):
慢调用比例 (SLOW_REQUEST_RATIO
):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs
)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN
状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断
Sentinel 1.7.0 版本平均响应时间示意图:
如上配置时,若1s内请求数>=5,并且平均响应时间>200ms,则触发熔断,在1s的时间窗后结束熔断。
Sentinel 降级策略 - 异常比例
Sentinel 1.7.0 版本的异常比例:
异常比例(DEGRADE_GRADE_EXCEPTION_RATIO
):当资源的每秒请求量 >= 5,并且每秒异常总数占通过量的比值超过阈值( DegradeRule
中的 count
)之后,资源进入降级状态,即在接下的时间窗口( DegradeRule
中的timeWindow
,以s为单位)之内,对这个方法的调用都会自动地返回。异常比率的阈值范围是[0.0, 1.0],代表0% -100%。
Sentinel 1.8.0 版本的异常比例:
异常比例 (ERROR_RATIO
):当单位统计时长(statIntervalMs
)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN
状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
Sentinel 1.7.0 版本异常比例示意图:
如上配置时,若1s内请求数>=5且出现异常的请求数占比大于0.2时触发熔断,在1s的时间窗后结束熔断。
Sentinel 降级策略 - 异常数
Sentinel 1.7.0 版本的异常数:
异常数(DEGRADE_GRADF_EXCEPTION_COUNT
):当资源近1分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的,若timeWindow
小于60s,则结束熔断状态后码可能再进入熔断状态。异常数是按照分钟统计的,时间窗口一定要大于等于60秒。
Sentinel 1.8.0 版本的异常数:
异常数(ERROR_COUNT
):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN
状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。
Sentinel 1.8.0 版本异常比例示意图:
如上配置时,若1s内请求数>=5且出现异常的请求数大于5时触发熔断,在61s的时间窗后结束熔断。(异常数是按照分钟统计的,时间窗口一定要大于等于60秒)
@SentinelResource 服务降级配置
方式1:指定资源名:
在 Controller 上使用 @SentinelResource 注解修饰目标方法,并设置资源名:value = "byResource"
,同时设置满足降级条件时的回调方法blockHandler = "handleException"
:
1 | import com.alibaba.csp.sentinel.annotation.SentinelResource; |
在控制台为该资源 "byResource"
设置降级规则,表示1秒钟内查询次数大于1,就跳转到blockHandler
指定的handleException()
方法:
方式2:指定URL:
1 |
|
可以在降级规则中指定URL,这样符合该URL的请求在满足条件时都会调用自定义的降级方法:
Sentinel 热点规则
何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如:
- 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
- 用户 ID 为参数,针对一段时间内频繁访问的用户 ID 进行限制
热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源调用生效。
Sentinel 利用 LRU 策略统计最近最常访问的热点参数,结合令牌桶算法来进行参数级别的流控。热点参数限流支持集群模式。
热点 key 配置代码案例:
- 使用 @SentinelResource 注解指定热点 key 值为
"testHotKey"
- 添加降级处理方法
blockHandler="deal_testHotKey"
,若不满足限流规则就执行降级处理方法
1 |
|
配置热点规则,指定资源名为代码中的 "testHotKey"
,且参数索引为0(即对第一个参数限流):
测试
- error
- right
热点规则参数例外项
在“高级选项”中可以设置参数例外项,即某个特殊值的时候限流值与其他普通值不同。
前提条件 - 热点参数必须是基本类型或者String。参数例外项配置如下:
效果:
- 普通参数值 - 超过1秒钟一个后,达到阈值1后马上被限流
- 某个特殊值时,限流值为200
- 特例 - 假如当p1的值等于5时,它的阈值可以达到200
测试:
- right - http://localhost:8401/testHotKey?p1=5
- error - http://localhost:8401/testHotKey?p1=3
- 当p1等于5的时候,阈值变为200
- 当p1不等于5的时候,阈值就是平常的1
Sentinel 系统规则
Sentinel 系统自适应限流从整体维度对应用入口流量进行控制,结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标,通过自适应的流控策略,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性
系统规则
系统保护规则是从应用级别的入口流量进行控制,从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效。入口流量指的是进入应用的流量(EntryType.IN),比如 Web 服务或 Dubbo 服务端接收的请求,都属于入口流量。
系统规则支持的模式
- Load 自适应(仅对 Linux/Unix-like 机器生效):系统的 load1 作为启发指标,进行自适应系统保护。当系统 load1 超过设定的启发值,且系统当前的并发线程数超过估算的系统容量时才会触发系统保护(BBR 阶段)。系统容量由系统的
maxQps * minRt
估算得出。设定参考值一般是CPU cores * 2.5
。 - CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0),比较灵敏。
- 平均 RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。
- 并发线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
- 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
@SentinelResource 配置
@SentinelResource 详解
@SentinelResource
用于定义资源,并提供可选的异常处理和 fallback
配置项。该注解包含以下属性:
value
:资源名称,必需项(不能为空),与控制台配置的资源名一一对应entryType
:entry 类型,可选项(默认为EntryType.OUT
)blockHandler
/blockHandlerClass
:blockHandler
对应处理BlockException
的方法名称,可选项。blockHandler
方法访问范围需要是public
,返回类型需要与原方法相匹配,参数类型需要和原方法相匹配并且最后加一个额外的参数,类型为BlockException
。blockHandler
方法默认需要和原方法在同一个类中。若希望使用其他类的方法,则可以指定blockHandlerClass
为对应的类的Class
对象,注意对应的方法必须为static
方法,否则无法解析。fallback
/fallbackClass
:fallback
方法名称,可选项,用于在抛出异常的时候提供fallback
处理逻辑。fallback
方法可以针对所有类型的异常(除了exceptionsToIgnore
里面排除掉的异常类型)进行处理。fallback
方法签名和位置要求:- 返回值类型必须与原方法返回值类型一致;
- 方法参数列表需要和原方法一致,或者可以额外多一个
Throwable
类型的参数用于接收对应的异常。 fallback
方法默认需要和原方法在同一个类中。若希望使用其他类的方法,则可以指定fallbackClass
为对应的类的Class
对象,注意对应的方法必须为static
方法,否则无法解析。
defaultFallback
(since 1.6.0):默认的fallback
方法名称,可选项,通常用于通用的fallback
逻辑(即可以用于很多服务或方法)。默认 fallback 方法可以针对所有类型的异常(除了exceptionsToIgnore
里面排除掉的异常类型)进行处理。若同时配置了fallback
和defaultFallback
,则只有fallback
会生效。defaultFallback
方法签名要求:- 返回值类型必须与原方法返回值类型一致;
- 方法参数列表需要为空,或者可以额外多一个
Throwable
类型的参数用于接收对应的异常。 - defaultFallback 方法默认需要和原方法在同一个类中。若希望使用其他类的方法,则可以指定
fallbackClass
为对应的类的Class
对象,注意对应的方法必需为 static 方法,否则无法解析。
exceptionsToIgnore
(since 1.6.0):用于指定哪些异常被排除掉,不会计入异常统计中,也不会进入fallback
逻辑中,而是会原样抛出。
blockHandler 属性
在 Controller 上使用 @SentinelResource 注解修饰目标方法,并设置资源名:value = "byResource"
,同时设置满足限流条件时的回调方法blockHandler = "handleException"
:
1 | import com.alibaba.csp.sentinel.annotation.SentinelResource; |
blockHandlerClass 属性
上述方式自定义的处理方法和业务代码耦合在一块,不直观。同时每个业务方法都添加—个方法将导致代码膨胀加剧。全局统—的处理方法没有能够体现。
解决方法:自定义限流处理类 - 创建 CustomerBlockHandler
类用于自定义限流处理逻辑(注意对应的方法必须为 static
方法,否则无法解析):
1 | import com.alibaba.csp.sentinel.slots.block.BlockException; |
RateLimitController
上指定 blockHandlerClass
:
1 |
|
blockHandlerClass
:指定自定义限流类CustomerBlockHandler.class
blockHandler
:指定该类中的指定限流方法handlerException2()
注意:
blockHandler
只能处理限流和降级相关的异常BlockException
,若是业务本身出现异常则不会响应blockHandler
指定的方法,此情况需要使用fallback
属性。blockHandlerClass
里的方法必须为static
方法,否则无法解析
fallback 属性
fallback
只负责处理业务异常,若同时发生限流/降级异常 BlockException
,则优先处理 BlockException
异常的处理方法。
- 开启 Ribbon 功能
1 | import org.springframework.cloud.client.loadbalancer.LoadBalanced; |
- Controller 测试
fallback
和blockHandler
的区别:
1 |
|
exceptionsToIgnore 属性
exceptionsToIgnore
:忽略指定异常,即这些异常不用回调方法处理。
1 |
|
Sentinel 整合 OpenFeign
注意:Sentinel 整合 OpenFeign 的使用方法类似于 Hystrix 整合 OpenFeign(见文章【Spring Cloud】Hystrix),区别在于配置文件中 feign 开启的是 sentinel 的降级处理
- 导入Maven依赖:
1 | <!--SpringCloud openfeign --> |
- 配置文件中添加 OpenFeign对 Sentinel 的支持:
1 | # 激活Sentinel对Feign的支持 |
- 主启动类标志 @EnableFeignClients 注解开启 OpenFeign:
1 | import org.springframework.cloud.client.discovery.EnableDiscoveryClient; |
- 业务接口标注 @Feignclient 注解,并指定降级处理实现类
fallback = PaymentFallbackService.class
:
1 | import com.zhao.springcloud.entities.CommonResult; |
- 创建
PaymentService
接口的实现类PaymentFallbackService
,实现接口的所有方法,在其添加降级业务:
1 | import com.zhao.springcloud.entities.CommonResult; |
- Controller 调用
PaymentService
接口的动态代理类即可实现远程调用与负载均衡,同时若服务出现异常,则会调用PaymentFallbackService
类的paymentSQL()
方法进行降级:
1 |
|
Sentinel 持久化规则
在未配置持久化时,一旦我们重启应用,之前配置的Sentinel规则将消失。因此生产环境需要将配置规则进行持久化。
思路:将限流配置规则持久化进Nacos保存,只要刷新8401某个rest地址,sentinel控制台的流控规则就能看到,只要Nacos里面的配置不删除,针对8401上sentinel上的流控规则持续有效。
实现方法:
- 修改
cloudalibaba-sentinel-service8401
,加入Maven依赖:
1 | <!--SpringCloud ailibaba sentinel-datasource-nacos 后续做持久化用到--> |
- 修改配置文件,添加Nacos数据源配置:
1 | server: |
- 添加Nacos业务规则配置(该配置需要与上述配置文件中的名称一致才能被sentinel获取到):
配置内容解析:
1 | [ |
resource
:资源名称;limitApp
:来源应用;grade
:阈值类型,0表示线程数, 1表示QPS;count
:单机阈值;strategy
:流控模式,0表示直接,1表示关联,2表示链路;controlBehavior
:流控效果,0表示快速失败,1表示Warm Up,2表示排队等待;clusterMode
:是否集群。
- 启动8401后刷新sentinel发现业务规则有了
- 关闭8401再看sentinel,发现流控规则没有了
- 重新启动8401再看sentinel,多次访问 http://localhost:8401/rateLimit/byUrl 后发现配置重新出现,说明规则配置持久化成功