Sentinel持久化模式
Sentinel规则的推送有下面三种模式:
原始模式:
如果不做任何修改,Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中:
这种做法的好处是简单,无依赖;坏处是应用重启,规则就会消失,仅用于简单测试,不能用于生产环境。
拉模式
pull 模式的数据源(如本地文件、RDBMS 等)一般是可写入的。使用时需要在客户端注册数据源:将对应的读数据源注册至对应的 RuleManager,将写数据源注册至 transport 的WritableDataSourceRegistry 中。从文件中拉过来,这种模式需要阅读一定的源码,在源码的基础上进行扩展。
推模式
生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心(ZooKeeper, Nacos, Apollo等等),推送的操作不应由 Sentinel 客户端进行,而应该经控制台统一进行管理,直接进行推送,数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制/Sentinel 控制台 → 配置中心 →Sentinel 数据源 → Sentinel,而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了:
基于Nacos配置中心控制台实现推送
依赖
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
nacos配置中心中配置流控规则
[{
"resource": "/order/flow", #资源
"controlBehavior": 0, #流控效果
"count": 2, #限流阈值
"grade": 1, #限流阈值类型
"limitApp": "default", #流控针对的调用来源
"strategy": 0 #调用关系策略:直接,链路,关联
}]
这段配置表达的意思:对/order/flow
资源进行限流,QPS限流模式,当阈值大于2时,直接拒绝(快速失败)
流量规则的定义
nacos与sentinel的配置的比较(下图对应的是上面的nacos配置)
从nacos与sentinel的配置结合起来看:
重要属性:
Field | 说明 | 默认值 |
---|---|---|
resource | 资源名,资源名是限流规则的作用对象 | |
count | 限流阈值 | |
grade | 限流阈值类型,QPS 模式(1)或并发线程数模式(0) | QPS 模式 |
limitApp | 流控针对的调用来源 | default ,代表不区分调用来源 |
strategy | 调用关系限流策略:直接、链路、关联 | 根据资源本身(直接) |
controlBehavior | 流控效果(直接拒绝/WarmUp/匀速+排队等待),不支持按调用关系限流 | 直接拒绝 |
clusterMode | 是否集群限流 | 否 |
同一个资源可以同时有多个限流规则,检查规则时会依次检查。
application.yml
server:
port: 8070
spring:
application:
name: order-sentinel
cloud:
sentinel:
transport:
dashboard: 127.0.0.1:8080
web-context-unify: false # 默认将调用链路收敛, 导致链路流控效果无效
datasource:
flow-rule: #可以自定义
nacos:
server-addr: 127.0.0.1:8848
username: nacos
password: nacos
dataId: order-sentinel-flow-rule
rule-type: flow
注意:在sentinel控制台修改的配置不会nacos配置文件中存在。如果想在sentinel控制台中修改后能够保存在nacos配置中心中,。。。。。
代码:https://gitee.com/qijianyeah/springcloudalibaba
官方文档:
https://sentinelguard.io/zh-cn/docs/basic-implementation.html
https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D