Springcloud----Sentinel微服务保护

        谈及微服务保护的问题之前,我们先要明确一下雪崩问题.

        在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。

        由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。

         雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问题，不会影响到其它服务的正常运行。也就是＂雪落而不雪崩＂。   

解决雪崩问题的常见方式有四种：

• 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
• 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
• 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求
• 流量控制：限制业务访问的QPS，避免服务因流量的突增而故障

常见的两种服务保护技术的对比:Sentinel对比Hystrix:

 一.认识Sentinel

        Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html
        Sentinel 具有以下特征:

• 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
• 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
• 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

二.Sentinel控制台的安装

解压后,在文件所在位置用命令窗口输入命令的方式运行该jar包

java -jar + 文件名

 默认的端口号为8080,我们可以在其中添加命令来改变端口号

java -Dserver.port=8000 -jar + 文件名

 除了修改端口号,还有如下配置可以修改:

启动以后,我们可以在浏览器中输入对应的端口号来进入ui界面:

初始的账号和密码都为:sentinel 我们可以通过在启动时添加配置项的方式修改密码

输入密码以后就会来到这个界面.

三.微服务整合Sentinel

我们可以给需要的微服务中都整合上sentinel,网关服务可以不用加.

1.引入依赖

<!--引入sentinal的依赖jar文件-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

 2.修改配置文件

在配置文件中配置上控制台的url地址.

spring.cloud.sentinel.transport.dashboard=localhost:8000

 3.重启微服务,查看控制台

.(记得先访问一次才能在控制台中显示)

 可以看到我们的微服务已经整合上了sentinel.

四.限流规则

簇点链路

首先我们要了解一下簇点链路.

簇点链路：就是项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

1.快速入门

点击资源/product/getById/{id}后面的流控按钮，就可以弹出表单。表单中可以添加流控规则，如下图所示：

 做个案例:给 /product/getById/{id}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

(1)
设置流控规则：

 这里可以查看我们的流控规则:

 (2)使用Jemeter(压测工具)测试：

 理论上来说,我们一秒发送20次请求,会有15个请求会失败,让我们看看结果如何:

 虽然结果并不是15个被拦截,但是已经证明我们的流控规则已经生效了,可以看到前五个请求可以正常发出,但是第六个开始就请求失败了,也许这些失败的请求导致Jemeter的并发出现了问题,让这20个请求没有在同一秒内发出,所以并不是理想值.我们可以实验QPS为1然后让每秒发送两个请求:

这次试验结果就符合预想了,所以问题不是我们的sentinel,而是压测工具.

2.流控模式:

在添加限流规则时，点击高级选项，可以选择三种流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

我们上面的入门运用的就是直接模式,下面给大家演示关联模式和链路模式. 

 2.1流控模式----关联

• 关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
• 使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

满足下面条件可以使用关联模式：

• 两个有竞争关系的资源
• 一个优先级较高，一个优先级较低

案例:当修改的并发请求量大时,限制对查询的请求(我们可以理解为修改的优先级要大于查询的优先级).

(1)在ProductController新建两个端点：/product/query和/product/update,无需实现业务

(2)配置流控规则，当/product/update资源被访问的QPS超过5时，对/product/query请求限流

要明确,对谁限流,就对谁设置,所以我们应该对/product/query进行设置.

(3)在Jemeter中对/peoduct/update进行压测,让他每秒的请求量大于5,然后在浏览器中访问/product/query,查看是否可以访问

 可以看到product/query已经无法成功访问,证明关联模式流控规则生效.

 2.2流控模式----链路

        链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流。它的功能有点类似于针对来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度更细。        

例如有两条请求链路：
/test1 -> /common
/test2  -> /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：

 案例:

(1) 我们在ProductController中还是运用关联模式创建的两个端口,让他们都去访问同一个service方法(getMsg),该service方法不需要实现内容.

这里我们要注意一点,Sentinel默认只会标记Controller中的方法为资源,如果想要将service中的方法标记为资源,则需要在service层对应的方法上加@SentinelResource注解,并且在配置文件中追加配置,关闭context整合,才能使该注解生效:

spring.cloud.sentinel.web-context-unify=false

 然后重启该服务.在Sentinel控制台中就可以看到我们新添加的资源:"getMsg".(记得先访问一次才能在控制台中显示)

 (2) 我们可以对product/query->getMsg这条链路做流控规则.对该链路访问的QPS限制为2

 使用压测工具Jemeter同时对product/query 和 prodcut/update两条链路做压测,让他们2秒内都请求10次.

product/query:

product/update:

理论结果应该是:update中的请求全部成功,query中的请求每秒只允许通过2个.让我们看结果:

product/query:

 product/update:

 实验结果表示流控规则----链路模式设置成功.

3.流控效果

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：
快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

我们上面在测试流控模式的时候,效果运用的都是快速失败,下面主要讲解一下预热效果和排队等待.

 3.1流控效果----预热模式

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor，持续指定时长后，逐渐提高到threshold值。而coldFactor的默认值是3.
例如，我设置QPS的threshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.预热模式适合处理激增形式的流量.

 案例:

我们给product/query这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

(1)设置流控规则:

 (2)在Jemeter中进行压测该资源,让他每秒发送10次请求,持续7秒:

让我们运行并查看结果:

从图中可以看出,一开始,每秒发送的10次请求只能通过三个,到中间慢慢的每秒通过的请求逐渐增多,到最后每秒发送的10次请求全部通过.这符合我们一开始设置的预热效果.

3.2流控效果----排队等待

当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。
例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待超过2000ms的请求会被拒绝并抛出异常

排队等待适合处理脉冲型的流量:当流量波形为脉冲形式时(即一阵流量大一阵流量小,形成脉冲的形式),我们可以利用起流量少的时间,作为排队等待时间.让QPS过滤掉的请求在等待时间内去处理,等待时间过了没有处理的请求都让他直接失败.

 案例:

我们给product/query资源设置流控规则,最大QPS为5，利用排队的流控效果，超时时长设置为5s,在Jemeter中我们模拟一个脉冲型的流量,每秒请求15次,中间间隔5s,重复4次.

让我们看结果:

我们可以看到,每一次都会有10个请求在等待池中排队等待,然后5s等待时间内完成了这10个请求,充分利用了空闲时间,完成了全部的请求量.

们可以尝试着加大请求量,让每秒发送20次请求,中间空闲5s,重复4次.

可以看到就算增加到20次我们的请求也会全部处理完.

我们甚至可以再尝试着加到每秒30次请求.

可以看到只有一瞬间拒绝了5次请求,随后的所有请求都被处理完成,并且我们的脉冲型流量最终变成了一个平稳的波段

        在实际运用中,如果我们发现某个资源的请求呈现脉冲形式,我们可以根据脉冲中的空闲时间段当作排队等待时间,从而分摊流量高峰时期的压力,做到削峰补平的效果.

五.热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

配置示例：

代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5

在热点参数限流的高级选项中，可以对部分参数设置例外配置：

结合上一个配置，这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：

• 如果参数值是100，则每1秒允许的QPS为10
• 如果参数值是101，则每1秒允许的QPS为15

案例:

给/order/buy/{pid}/{num}这个资源添加热点参数限流，规则如下：

• 默认的热点参数规则是每1秒请求量不超过2
• 给pid=1这个参数设置例外：每1秒请求量不超过4
• 给pid=2这个参数设置例外：每1秒请求量不超过10

注意:热点参数限流对默认的SpringMVC资源无效

所以我们在设置之前,要先给该资源设置@SentinelResource.让热点参数能够对该资源起作用.

 配置文件不要忘了关闭context整合

 这时我们重启服务,并按照要求设置热点资源限流规则
我们不能直接点该资源右边的热点,这样点没有高级设置.我们需要在左侧菜单热点资源出新建一个规则.

 配置已经完成,我们继续使用我们的压测工具Jemeter实验一下.

我们给pid=3的请求设置1秒发送3次请求模拟默认参数规则;pid=1设置1秒发送5次参数请求;pid=2设置1秒发送11次请求.根据我们设置的热点参数规则, 他们都会有一个请求被判定失败.让我们直接看看结果是不是这样:

 六.隔离和降级

虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。
不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

1.OpenFeign整合Sentinel

SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。

(1)修改OrderService的application.yml文件，开启Feign的Sentinel功能

(2)给FeignClient编写失败后的降级逻辑

方式一：FallbackClass，无法对远程调用的异常做处理
方式二：FallbackFactory，可以对远程调用的异常做处理，我们选择这种
①在lrs-order项目中定义类，实现FallbackFactory

@Component
@Slf4j
public class ProductFeignFactory implements FallbackFactory<ProductFeign> {
    @Override
    public ProductFeign create(Throwable throwable) {
        //创建ProductFeign接口实现类,实现其中的方法,编写失败降级的处理逻辑
        ProductFeign productFeign = new ProductFeign() {
            @Override
            public Product getById(Integer id) {
                //记录异常信息
                log.error("出现了问题,调用该兜底方法");
                Product p = new Product();
                //返回文字描述和异常信息
                p.setPname("服务器正忙,请稍后再试"+throwable.getMessage());
                return p;
            }
        };
        return productFeign;
    }
}

②在lrs-order项目中的UserClient接口中使用ProductFeignFactory：

@FeignClient(value = "lrs-product",fallbackFactory = ProductFeignFactory.class)
public interface ProductFeign {
    @GetMapping("/product/getById/{id}")
    public Product getById(@PathVariable Integer id);

}

配置完成后重启项目,访问一遍该路径,在Sentinel控制台中就可以看到这个资源:

 我们之后的降级操作都时对该资源进行操作的.

2.线程隔离

线程隔离有两种方式实现：
线程池隔离
信号量隔离（Sentinel默认采用）

线程池隔离会创建出新的线程,而信号量隔离是增加一个计数器,没有额外增加新的线程.

使用Sentinel设置线程隔离（舱壁模式）

在添加限流规则时，可以选择两种阈值类型：

QPS：就是每秒的请求数，在快速入门中已经演示过
线程数：是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现舱壁模式。

 案例:

我们给GET:http://lrs-product/product/getById/{id}设置线程隔离,线程数不能超过2.

我们用Jemeter进行测试.

我们给/order/buy/1/1这个请求进行测试,他同样会调取我们设置线程隔离的这个资源.我们设置0秒发送10次请求.

可以看到,我们请求只通过了两个,剩下的8个线程都被拒绝掉了.

3.熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器熔断策略有三种：慢调用、异常比例、异常数
慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。例如：

解读：RT超过500ms的调用是慢调用，统计最近10000ms内的请求，如果请求量超过10次，并且慢调用比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。

熔断策略----慢调用

为了方便演示,我们给host资源的业务代码增加100ms的睡眠时间

@Override
    public Product getById(Integer id) {
        if (id==1){
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        return productMapper.selectById(id);
    }

 这样远程调用我们这个方法时,如果传入的id=1,那么就睡眠100ms.其他的正常运行.

传入id=1时,耗时在100ms以上.

 正常情况下耗时都在40左右.

 这样我们就可以以100ms为界限规定是否为慢调用.10s内如果发送请求大于5个,那么如果发送的这些请求中,慢调用的比例大于0.5,就让断路器对该服务进行熔断.

我们在浏览器中疯狂刷新一下order/getOrder/1的请求,让其熔断.

 可以看到,已经被熔断了.我们这时就算访问不是慢调用的请求一样是显示熔断效果

对于熔断的半开请求,注意,当熔断的时间到了以后,会使熔断处于半开状态.这时第一个访问的请求如果还是慢调用的请求,那么该服务继续熔断.如果是正常请求,那么就关闭熔断状态.

熔断策略----异常比例、异常数

断路器熔断策略有三种：慢调用、异常比例或异常数
异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。例如：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。

 我们再演示一个异常比例的熔断策略.我们修改一下业务代码,让其id=1时产生一个异常.

    @Override
    public Product getById(Integer id) {
        if (id==1){
            try {
                throw  new Exception("出现了异常");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        return productMapper.selectById(id);
    }

然后设置降级规则.当 10s内发送请求大于5个时,发送的请求中如果发生异常的比例大于0.5就熔断.

 熔断前:

熔断后:

七.自定义异常

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

public interface BlockExceptionHandler {

    /**

     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException

     */

    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;

}

而BlockException包含很多个子类，分别对应不同的场景：

我们在lrs-order服务中定义类，实现BlockExceptionHandler接口：

package com.lrs.order.handler;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException;
import com.alibaba.csp.sentinel.slots.block.flow.FlowException;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class SentinelBlockHandler implements BlockExceptionHandler {
    @Override
    public void handle(
            HttpServletRequest httpServletRequest,
            HttpServletResponse httpServletResponse, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;
        if (e instanceof FlowException) {
           msg = "请求被限流了！";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了！"; 
        } else if (e instanceof ParamFlowException) {
            msg = "热点参数限流！";
        } else if (e instanceof AuthorityException) {
            msg = "请求没有权限！";
           status = 401;
       }
       httpServletResponse.setContentType("application/json;charset=utf-8");
        httpServletResponse.setStatus(status);
        httpServletResponse.getWriter().println("{\"message\": \"" + msg + "\", \"status\": " + status + "}");
   }
}

随后重启服务.我们测试一个限流异常:

八.持久化规则

Sentinel的控制台规则管理有三种模式：

原始模式：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。然后保存在内存中，服务重启则丢失

 

pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

 实现pull模式:

1 编写处理类

package com.lrs.order.config;

import com.alibaba.csp.sentinel.command.handler.ModifyParamFlowRulesCommandHandler;
import com.alibaba.csp.sentinel.datasource.*;
import com.alibaba.csp.sentinel.init.InitFunc;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityRule;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityRuleManager;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeRule;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeRuleManager;
import com.alibaba.csp.sentinel.slots.block.flow.FlowRule;
import com.alibaba.csp.sentinel.slots.block.flow.FlowRuleManager;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowRule;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowRuleManager;
import com.alibaba.csp.sentinel.slots.system.SystemRule;
import com.alibaba.csp.sentinel.slots.system.SystemRuleManager;
import com.alibaba.csp.sentinel.transport.util.WritableDataSourceRegistry;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.TypeReference;
import org.springframework.beans.factory.annotation.Value;

import java.io.File;
import java.io.IOException;
import java.util.List;
public class FilePersistence implements InitFunc {

    @Value("${spring.application.name}")
    private String appcationName;

    @Override
    public void init() throws Exception {
        String ruleDir = System.getProperty("user.home") + "/sentinel-rules/" + appcationName;
        String flowRulePath = ruleDir + "/flow-rule.json";
        String degradeRulePath = ruleDir + "/degrade-rule.json";
        String systemRulePath = ruleDir + "/system-rule.json";
        String authorityRulePath = ruleDir + "/authority-rule.json";
        String paramFlowRulePath = ruleDir + "/param-flow-rule.json";

        this.mkdirIfNotExits(ruleDir);
        this.createFileIfNotExits(flowRulePath);
        this.createFileIfNotExits(degradeRulePath);
        this.createFileIfNotExits(systemRulePath);
        this.createFileIfNotExits(authorityRulePath);
        this.createFileIfNotExits(paramFlowRulePath);

        // 流控规则
        ReadableDataSource<String, List<FlowRule>> flowRuleRDS = new FileRefreshableDataSource<>(
                flowRulePath,
                flowRuleListParser
        );
        FlowRuleManager.register2Property(flowRuleRDS.getProperty());
        WritableDataSource<List<FlowRule>> flowRuleWDS = new FileWritableDataSource<>(
                flowRulePath,
                this::encodeJson
        );
        WritableDataSourceRegistry.registerFlowDataSource(flowRuleWDS);

        // 降级规则
        ReadableDataSource<String, List<DegradeRule>> degradeRuleRDS = new FileRefreshableDataSource<>(
                degradeRulePath,
                degradeRuleListParser
        );
        DegradeRuleManager.register2Property(degradeRuleRDS.getProperty());
        WritableDataSource<List<DegradeRule>> degradeRuleWDS = new FileWritableDataSource<>(
                degradeRulePath,
                this::encodeJson
        );
        WritableDataSourceRegistry.registerDegradeDataSource(degradeRuleWDS);

        // 系统规则
        ReadableDataSource<String, List<SystemRule>> systemRuleRDS = new FileRefreshableDataSource<>(
                systemRulePath,
                systemRuleListParser
        );
        SystemRuleManager.register2Property(systemRuleRDS.getProperty());
        WritableDataSource<List<SystemRule>> systemRuleWDS = new FileWritableDataSource<>(
                systemRulePath,
                this::encodeJson
        );
        WritableDataSourceRegistry.registerSystemDataSource(systemRuleWDS);

        // 授权规则
        ReadableDataSource<String, List<AuthorityRule>> authorityRuleRDS = new FileRefreshableDataSource<>(
                authorityRulePath,
                authorityRuleListParser
        );
        AuthorityRuleManager.register2Property(authorityRuleRDS.getProperty());
        WritableDataSource<List<AuthorityRule>> authorityRuleWDS = new FileWritableDataSource<>(
                authorityRulePath,
                this::encodeJson
        );
        WritableDataSourceRegistry.registerAuthorityDataSource(authorityRuleWDS);

        // 热点参数规则
        ReadableDataSource<String, List<ParamFlowRule>> paramFlowRuleRDS = new FileRefreshableDataSource<>(
                paramFlowRulePath,
                paramFlowRuleListParser
        );
        ParamFlowRuleManager.register2Property(paramFlowRuleRDS.getProperty());
        WritableDataSource<List<ParamFlowRule>> paramFlowRuleWDS = new FileWritableDataSource<>(
                paramFlowRulePath,
                this::encodeJson
        );
        ModifyParamFlowRulesCommandHandler.setWritableDataSource(paramFlowRuleWDS);
    }

    private Converter<String, List<FlowRule>> flowRuleListParser = source -> JSON.parseObject(
            source,
            new TypeReference<List<FlowRule>>() {
            }
    );
    private Converter<String, List<DegradeRule>> degradeRuleListParser = source -> JSON.parseObject(
            source,
            new TypeReference<List<DegradeRule>>() {
            }
    );
    private Converter<String, List<SystemRule>> systemRuleListParser = source -> JSON.parseObject(
            source,
            new TypeReference<List<SystemRule>>() {
            }
    );

    private Converter<String, List<AuthorityRule>> authorityRuleListParser = source -> JSON.parseObject(
            source,
            new TypeReference<List<AuthorityRule>>() {
            }
    );

    private Converter<String, List<ParamFlowRule>> paramFlowRuleListParser = source -> JSON.parseObject(
            source,
            new TypeReference<List<ParamFlowRule>>() {
            }
    );

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

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

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

2 添加配置

在resources下创建配置目录 META-INF/services ,然后添加文件

com.alibaba.csp.sentinel.init.InitFunc

在文件中添加配置类的全路径

com.lrs.order.config.FilePersistence

 

 

未完待续.....................................