sentinel持久化到nacos(规则管理与推送)
一般来说,规则的推送有下面三种模式:
推送模式 说明 优点 缺点 原始模式 API 将规则推送至客户端并直接更新到内存中,扩展写数据源( WritableDataSource
)简单,无任何依赖 不保证一致性;规则保存在内存中,重启即消失。严重不建议用于生产环境 Pull 模式 扩展写数据源( WritableDataSource
), 客户端主动向某个规则管理中心定期轮询拉取规则,这个规则中心可以是 RDBMS、文件 等简单,无任何依赖;规则持久化 不保证一致性;实时性不保证,拉取过于频繁也可能会有性能问题。 Push 模式 扩展读数据源( ReadableDataSource
),规则中心统一推送,客户端通过注册监听器的方式时刻监听变化,比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。规则持久化;一致性;快速 引入第三方依赖 Push模式
生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心(ZooKeeper, Nacos, Apollo等等),推送的操作不应由 Sentinel 客户端进行,而应该经控制台统一进行管理,直接进行推送,数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel,而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了:
前置条件
依赖
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
配置yml
spring:
application:
name: cloud-consumer-feign
cloud:
nacos:
discovery:
namespace: public
server-addr: localhost:8848
sentinel:
transport:
dashboard: localhost:8080
port: 8719
//[0]
datasource:
ds1:
nacos:
server-addr: localhost:8848
[1]
data-id: cloud-consumer-feign
[2]
group-id: DEFAULT_GROUP
[3]
data-type: json
[4]
rule-type: flow
实践
-
nacos中新建配置
注意yml配置:
[0]表示sentinel数据源配置开始;
[1]对应下图的0
[2]对应下图的1
[3]对应下图的2
json中的名词解释:
[4]rule-type需要单独讲,它取值如下:
/**
* flow.
*/
FLOW("flow", FlowRule.class),
/**
* degrade.
*/
DEGRADE("degrade", DegradeRule.class),
/**
* param flow.
*/
PARAM_FLOW("param-flow", ParamFlowRule.class),
/**
* system.
*/
SYSTEM("system", SystemRule.class),
/**
* authority.
*/
AUTHORITY("authority", AuthorityRule.class),
/**
* gateway flow.
*/
GW_FLOW("gw-flow",
"com.alibaba.csp.sentinel.adapter.gateway.common.rule.GatewayFlowRule"),
/**
* api.
*/
GW_API_GROUP("gw-api-group",
"com.alibaba.csp.sentinel.adapter.gateway.common.api.ApiDefinition");
全部配置好之后点击发,此时可以看到sentinel页面也跟着变化了:
测试
-
配置jmeter
一秒20个请求
-
结果
总结
- 配合nacos可以实现规则持久化
- 也可以利用redis,zk等实现持久化
- 生产环境持久化使用推模式
- 这个持久化很难用