Sentinel规则持久化实战

1.Sentinel规则推模式原理分析

改造拉模式的缺点：不够实时，需要找到对应的配置文件，并熟悉规则

推模式可以直接在nacos控制台配置，配置中心推送给客户端

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

2.基于Nacos配置中心控制台推送规则实战

<!--sentinel持久化 采用 Nacos 作为规则配置数据源-->
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

spring:
  application:
    name: mall-user-sentinel-demo
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

    sentinel:
      transport:
        # 添加sentinel的控制台地址
        dashboard: 127.0.0.1:8080
        # 指定应用与Sentinel控制台交互的端口，应用本地会起一个该端口占用的HttpServer
        port: 8719
      datasource:
        ds1:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: ${spring.application.name}
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow #规则和下面的一一对应

nacos配置中心中添加

3.基于Nacos控制台的推模式持久化源码分析

这里也是一个spring的扩展点，SentinelDataSourceHandler实现了SmartInitializingSingleton，所以最后会通过ApplicationContext的refresh方法中this.finishBeanFactoryInitialization(beanFactory); 在所有非懒加载单例bean初始化完成之后，最后的是这个调用smartSingleton.afterSingletonsInstantiated();

方法中循环所有的datasource，就是前面配置的ds1，dataSourceName=ds1-sentinel-nacos-datasource，最后获取到对应规则的NacosDataSource对象，把对应的property注册到RuleManager，根据ruleType注册到不同的规则管理器，流控对应流控，热点对应热点........

最后NacosDataSource被微服务获取到，创建对应的listener，在nacos控制台对应的dataId配置发生变化，会回调listener，更新内存中的配置

 

 

4.Sentinel控制台改造思路分析

在nacos配置流控规则之后，在sentinel控制台也能看到这个配置了，修改也会同步过来（控制台主动去getRules的），而在sentinel控制台修改配置，也会setRules更新到微服务，但是nacos的配置没有发生改变，所以没持久化。这个时候 sentinel dashboard没有和nacos-confIg-center通信，而是直接和微服务通信了，只实现了读数据源，没有实现写数据源，这就是推模式的问题所在。

扩展改造的思路：

Sentinel Dashboard监听Nacos配置的变化，如发生变化就更新本地缓存。在Sentinel Dashboard端新增或修改规则配置在保存到内存的同时，直接发布配置到nacos配置中心；Sentinel Dashboard直接从nacos拉取所有的规则配置。

sentinel Dashboard和sentinel client 不直接通信，而是通过nacos配置中心获取到配置的变更。

5.基于Sentinel控制台推送规则实战