前言
之前我们定义的流控和熔断规则应用每次重启之后就丢失了,是因为在控制定义规则这些规则仅在内存态生效,应用重启之后,该规则会丢失,这就是规则推送的原始模式。
规则推送分为 3 种模式,包括 “原始模式”、“Pull 模式” 和"Push 模式"。
这里我们主要介绍官方推荐的 push 模式,结合Nacos来完成Sentinel规则的存储。
一、规则管理及推送
一般来说,规则的推送有下面三种模式:
推送模式 | 说明 | 优点 | 缺点 |
---|---|---|---|
原始模式 | API 将规则推送至客户端并直接更新到内存中,扩展写数据源(WritableDataSource) | 简单,无任何依赖 | 不保证一致性;规则保存在内存中,重启即消失。严重不建议用于生产环境 |
Pull 模式 | 扩展写数据源(WritableDataSource), 客户端主动向某个规则管理中心定期轮询拉取规则,这个规则中心可以是 RDBMS、文件 等 | 简单,无任何依赖;规则持久化 | 不保证一致性;实时性不保证,拉取过于频繁也可能会有性能问题。 |
Push 模式 | 扩展读数据源(ReadableDataSource),规则中心统一推送,客户端通过注册监听器的方式时刻监听变化,比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。 | 规则持久化;一致性;快速 | 引入第三方依赖 |
通过表格可以看出Push模式
是目前比较完善的解决方案,不存在明显的缺点。
二、DataSource 扩展
我们推荐通过控制台设置规则后将规则推送到统一的规则中心,客户端实现 ReadableDataSource 接口端监听规则中心实时获取变更,流程如下:
1. 引入依赖
<!-- https://mvnrepository.com/artifact/com.alibaba.csp/sentinel-datasource-nacos -->
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
<version>1.8.8</version>
</dependency>
2. 规则文件
我们在Nacos新建配置文件
provider-service-flow-rules.json
,这里分组定义为SENTINEL_GROUP
,和服务配置区分开
[
{
"resource": "/sentinel/flow",
"controlBehavior": 0,
"count": 5,
"grade": 1,
"limitApp": "default",
"strategy": 0
}
]
注意我们这里的resource
定义不包含应用上下文路径,要和簇点链路中资源名称保持一致
3. 定义数据源信息
Sentinel starter 整合了目前存在的几类 ReadableDataSource。只需要在配置文件中进行相关配置,即可在 Spring 容器中自动注册 DataSource。
spring:
cloud:
sentinel:
transport:
port: 8719
dashboard: 192.168.137.192:8080
datasource:
ds1:
nacos:
server-addr: ${NACOS_SERVER_ADDR}
namespace: ${NACOS_NAMESPACE}
username: ${NACOS_USERNAME}
password: ${NACOS_PASSWORD}
dataId: ${spring.application.name}-flow-rules.json
groupId: SENTINEL_GROUP
data-type: json
rule-type: flow
我们可以定义多个数据源,和ds1:
保持同级定义ds2:
,ds3:
即可
当 ReadableDataSource
加载规则数据成功的时候,控制台会打印出相应的日志信息:
2024-08-31T16:53:36.153+08:00 INFO 13708 --- [provider-service] [ main] c.a.n.client.config.impl.ClientWorker : [fixed-dev-192.168.137.192_8848] [subscribe] provider-service-flow-rules.json+SENTINEL_GROUP+dev
2024-08-31T16:53:36.161+08:00 INFO 13708 --- [provider-service] [ main] c.a.nacos.client.config.impl.CacheData : [fixed-dev-192.168.137.192_8848] [add-listener] ok, tenant=dev, dataId=provider-service-flow-rules.json, group=SENTINEL_GROUP, cnt=1
三、服务定义和测试
1. 服务定义
package org.example.nacos.provider.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
/**
* Create by zjg on 2024/8/31
*/
@RestController
public class SentinelController {
@GetMapping(value = "/sentinel/flow")
public String flow(@RequestParam("name") String name) {
return "hello"+name;
}
}
2. 并发测试
我们定义的流控规则已经生效了,限流阈值5,导致了第6个请求失败,符合预期。
3. 控制台查看规则
我们通过Nacos定义的provider-service-flow-rules.json
流控配置文件已经生效,并且我们可以通过Nacos动态调整流控和熔断等各种各样的规则,推送到Sentinel 控制台。
总结
回到顶部
上图的①到③环节已经打通,但是到这里,还有些问题,我们通过Sentinel 控制台修改规则,却无法保存到我们的Nacos配置中心,重启还是会丢失,下一章我们让Sentinel 控制台修改规则推送到配置文件中去,完成持久化存储的功能。