## :-: 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)