改造拉模式的缺点:不够实时,需要找到对应的配置文件,并熟悉规则
推模式可以直接在nacos控制台配置,配置中心推送给客户端
生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心(ZooKeeper, Nacos, Apollo等等),推送的 *** 作不应由 Sentinel 客户端进行,而应该经控制台统一进行管理,直接进行推送,数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel
2.基于Nacos配置中心控制台推送规则实战com.alibaba.csp sentinel-datasource-nacos
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控制台推送规则实战欢迎分享,转载请注明来源:内存溢出
评论列表(0条)