## :-: Sentinel使用Nacos存储规则及同步 ## 一、使用Nacos存储限流规则 ### 1、Sentinel 动态规则扩展 Sentinel 的理念是开发者只需要关注资源的定义，当资源定义成功后可以动态增加各种流控降级规则。Sentinel 提供两种方式修改规则： * 通过 API 直接修改 (`loadRules`) * 通过 `DataSource` 适配不同数据源修改 手动通过 API 修改比较直观，可以通过以下几个 API 修改不同的规则： ~~~html FlowRuleManager.loadRules(List<FlowRule> rules); // 修改流控规则 DegradeRuleManager.loadRules(List<DegradeRule> rules); // 修改降级规则 ~~~ 手动修改规则（硬编码方式）一般仅用于测试和演示，生产上一般通过动态规则源的方式来动态管理规则。 ### 2、规则管理及推送 一般来说，规则的推送有下面三种模式: | 推送模式 | 说明 | 优点 | 缺点 | | --- | --- | --- | --- | | [原始模式](https://github.com/alibaba/Sentinel/wiki/%E5%9C%A8%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B8%AD%E4%BD%BF%E7%94%A8-Sentinel#%E5%8E%9F%E5%A7%8B%E6%A8%A1%E5%BC%8F) | API 将规则推送至客户端并直接更新到内存中，扩展写数据源（[`WritableDataSource`](https://github.com/alibaba/Sentinel/wiki/%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%99%E6%89%A9%E5%B1%95)） | 简单，无任何依赖 | 不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境 | | [Pull 模式](https://github.com/alibaba/Sentinel/wiki/%E5%9C%A8%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B8%AD%E4%BD%BF%E7%94%A8-Sentinel#Pull%E6%A8%A1%E5%BC%8F) | 扩展写数据源（[`WritableDataSource`](https://github.com/alibaba/Sentinel/wiki/%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%99%E6%89%A9%E5%B1%95)）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等 | 简单，无任何依赖；规则持久化 | 不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。 | | [**Push 模式**](https://github.com/alibaba/Sentinel/wiki/%E5%9C%A8%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B8%AD%E4%BD%BF%E7%94%A8-Sentinel#Push%E6%A8%A1%E5%BC%8F) | 扩展读数据源（[`ReadableDataSource`](https://github.com/alibaba/Sentinel/wiki/%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%99%E6%89%A9%E5%B1%95)），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。**生产环境下一般采用 push 模式的数据源。** | 规则持久化；一致性；快速 | 引入第三方依赖 | ### 3、DataSource 扩展 上述 `loadRules()` 方法只接受内存态的规则对象，但更多时候规则存储在文件、数据库或者配置中心当中。`DataSource` 接口给我们提供了对接任意配置源的能力。相比直接通过 API 修改规则，实现 `DataSource` 接口是更加可靠的做法。 生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 **配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel**，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：  `DataSource` 扩展常见的实现方式有: * **拉模式**：客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件，甚至是 VCS 等。这样做的方式是简单，缺点是无法及时获取变更； * **推模式**：规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 [Nacos](https://github.com/alibaba/nacos)、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。 Sentinel 目前支持以下数据源扩展： * Pull-based: 文件、Consul * Push-based: ZooKeeper, Redis, Nacos, Apollo, etcd 详细说明，可参考官网： [https://github.com/alibaba/Sentinel/wiki/%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%99%E6%89%A9%E5%B1%95](https://github.com/alibaba/Sentinel/wiki/%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%99%E6%89%A9%E5%B1%95) ### 4、Nacos 我们已经将Sentinel整合进SpringCloud应用及网关。 下面我们将同时使用到\*\*`Nacos**`和`**Sentinel Dashboard`\*\*，所以可以先把`Nacos`和`Sentinel Dashboard`启动起来。 默认配置下启动后，它们的访问地址（后续会用到）为： * Nacos：[http://localhost:8848/](http://localhost:8848/) * Sentinel Dashboard：[http://localhost:8080/](http://localhost:8080/) ### **5、依赖** 在上一节的hmall-market、hmall-gateway-jwt的Spring Cloud应用的`pom.xml`中引入Spring Cloud Alibaba的Sentinel模块和Nacos存储扩展： ``` <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency> ``` ### 6、配置  注：如果你的Nacos配置了不同的隔离环境 **namespace**，则需要指定具体哪一个namespace，否则会加载不到规则配置 * `spring.cloud.sentinel.transport.dashboard`：sentinel dashboard的访问地址，根据上面准备工作中启动的实例配置 * `spring.cloud.sentinel.datasource.ds.nacos.server-addr`：nacos的访问地址，，根据上面准备工作中启动的实例配置 * `spring.cloud.sentinel.datasource.ds.nacos.groupId`：nacos中存储规则的groupId * `spring.cloud.sentinel.datasource.ds.nacos.dataId`：nacos中存储规则的dataId * `spring.cloud.sentinel.datasource.ds.nacos.rule-type`：该参数是spring cloud alibaba升级到0.2.2之后增加的配置，用来定义存储的规则类型。所有的规则类型可查看枚举类：`org.springframework.cloud.alibaba.sentinel.datasource.RuleType`，每种规则的定义格式可以通过各枚举值中定义的规则对象来查看，比如限流规则可查看：`com.alibaba.csp.sentinel.slots.block.flow.FlowRule` 这里对于dataId使用了`${spring.application.name}`变量，这样可以根据应用名来区分不同的规则配置。 ### 7、Nacos中创建限流规则的配置 在Nacos控制台，对应的namespace ,新建一个**json**配置文件：market\*\*-flow-rules\*\*，如下：  可以看到上面配置规则是一个**数组类型**，数组中的每个对象是针对每一个保护资源的配置对象，每个对象中的属性解释如下： * resource：资源名，即限流规则的作用对象 * limitApp：流控针对的调用来源，若为 default 则不区分调用来源 * grade：限流阈值类型（QPS 或并发线程数）；`0`代表根据并发数量来限流，`1`代表根据QPS来进行流量控制 * count：限流阈值 * strategy：调用关系限流策略 * controlBehavior：流量控制效果（直接拒绝、Warm Up、匀速排队） * clusterMode：是否为集群模式 启动hmall-market 应用，注册到nacos到，打开Sentinel控制台，可以看到上面nacos新建的限流规则，如下： **注意：** 在完成了上面的整合之后，对于接口流控规则的修改就存在两个地方了：**Sentinel控制台、Nacos控制台**。 这个时候，通过Nacos修改该条规则是可以同步到Sentinel的，但是通过Sentinel控制台修改或新增却不可以同步到Nacos。因为当前版本的Sentinel控制台不具备同步修改Nacos配置的能力，而Nacos由于可以通过在客户端中使用Listener来实现自动更新。所以，在整合了Nacos做规则存储之后，需要知道在下面两个地方修改存在不同的效果： * Sentinel控制台中修改规则：仅存在于服务的**内存**中，不会修改Nacos中的配置值，重启后恢复原来的值。 * Nacos控制台中修改规则：服务的内存中规则会更新，Nacos中持久化规则也会更新，重启后依然保持。 下面我们进通过修改，使得Nacos与Sentinel可以互相同步限流规则： [https://www.cnblogs.com/jian0110/p/14139044.html](https://www.cnblogs.com/jian0110/p/14139044.html)