Sentinel持久化模式

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的配置结合起来看：

重要属性：

同一个资源可以同时有多个限流规则，检查规则时会依次检查。

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