Spring Cloud Alibaba(11)---Sentinel+Nacos持久化

雨點的名字發表於2021-05-20
SpringCloud持久化

Sentinel+Nacos持久化

有關Sentinel之前有寫過兩篇

Spring Cloud Alibaba(9)---Sentinel概述

Spring Cloud Alibaba(10)---Sentinel控制檯搭建+整合SpringCloudAlibaba

這篇部落格主要講 Sentinel+Nacos持久化 有關Sentinel其它的知識點我這邊就不在講了 自己去官網詳細看。

一、Sentinel+持久化原理

1、為什麼需要持久化

前面我們搭建過Nacos + Mysql持久化,因為Nacos預設是將配置資料寫在記憶體中的,所以當Nacos一重啟,所有配置資訊都會丟失。同樣的原因。Sentinel預設也是將規則推送至

客戶端並直接更新到記憶體中，所以客戶端一重啟，規則即消失。在生產環境肯定是需要持久化配置它。

2、官方配置持久化的方式

官方文件 在生產環境中使用 Sentinel

官方給出了兩種方式: Pull模式 和 Push模式

1)、Pull模式

說明

pull 模式的資料來源（如本地檔案、RDBMS 等）一般是可寫入的。 客戶端主動向某個規則管理中心(如本地檔案、RDBMS 等)定期輪詢拉取規則。我們既可以在應用本地直接

修改檔案來更新規則，也可以通過 Sentinel 控制檯推送規則。以本地檔案資料來源為例，推送過程如下圖所示：

Spring Cloud Alibaba(11)---Sentinel+Nacos持久化

首先 Sentinel 控制檯通過 API 將規則推送至客戶端並更新到記憶體中，接著註冊的寫資料來源會將新的規則儲存到本地的檔案中。使用 pull 模式的資料來源時一般不需要對 Sentinel

控制檯進行改造。

優點：簡單，無任何依賴；規則持久化

缺點：不保證一致性(無法保證同步)；實時性不保證(畢竟是輪詢)，拉取過於頻繁也可能會有效能問題。

2)、Push模式

規則中心統一推送，客戶端通過註冊監聽器的方式時刻監聽變化，比如使用 Nacos、Zookeeper 等配置中心。這種方式有更好的實時性和一致性保證。

生產環境下一般採用 push 模式的資料來源。

同時官方也建議，推送的操作不應由 Sentinel 客戶端進行，而應該經控制檯統一進行管理，直接進行推送，資料來源僅負責獲取配置中心推送的配置並更新到本地。因此推送規則正確

做法應該是 配置中心控制檯/Sentinel 控制檯 → 配置中心 → Sentinel 資料來源 → Sentinel，而不是經 Sentinel 資料來源推送至配置中心。這樣的流程就非常清晰了：

Spring Cloud Alibaba(11)---Sentinel+Nacos持久化

優點：規則持久化；一致性；快速

缺點：引入第三方依賴


二、Sentinel+Nacos持久化配置

1、pom.xml

之前有關Sentinel和Nacos相關jar包已經新增過 ，所以只新增需要Sentinel和Nacos整合的包。

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2、bootstrap.yml

# Spring
spring:
  application: # 應用名稱
    name: mall-goods

  profiles: # 環境配置
    active: dev

  cloud:
    nacos:
      discovery:
        # 服務註冊地址
        server-addr: 127.0.0.1:8848
      config:
        # 配置中心地址
        server-addr: 127.0.0.1:8848
        # 配置檔案格式
        file-extension: yml
    sentinel:
      # 取消控制檯懶載入
      eager: true
      transport:
        # 控制檯地址
        dashboard: 127.0.0.1:8282
      # nacos配置持久化
      datasource:
        ds1:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: ${spring.application.name}-SENTINEL.json
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow

3、Naocs控制檯新增配置

因為上面配置的 dataId: ${spring.application.name}-SENTINEL.json，所以這裡在Nacos建立該 mall-goods-SENTINEL.json 配置集

Spring Cloud Alibaba(11)---Sentinel+Nacos持久化

然後在配置集中新增配置

[
    {
        "resource": "/api/v1/sentinel/test-sentinel",
        "limitApp": "default",
        "grade": "1",
        "count": "5",
        "strategy": "0",
        "controlBehavior": "0",
        "clusterMode": false
    }
]

相關屬性說明

resource：資源名稱
limitApp：來源應用
grade：閥值型別，0：執行緒數，1：QPS
count：單機閥值
strategy：流控模式，0：直接，1：關聯，2：鏈路
controlBehavior：流控效果，0：快速失敗，1：warmUp，2：排隊等待
clusterMode：是否叢集

4、檢視Sentinel控制檯

Spring Cloud Alibaba(11)---Sentinel+Nacos持久化

以上都配置好後，我們啟動Sentinel就可以看到 ，上面的這個限流規則已經在Sentinel控制檯了，所以我們在Nacos配置的限流規則，已經推送到了Sentinel控制檯。因為我們

Naocs已經通過Mysql進行持久化所以配置的這個限流規則，會永遠存在，不會因為重啟而丟失,這樣就保證了規則的持久化。

5、補充

1)、其實如果以上都配置好後，我們發現如果我們在Sentinel控制檯配置一條限流規則，這個限流規則不會主動推送到Nacos。所以我們每次需要在Nacos配置規則然後會推送到

Sentinel。但是Nacos中的規則需要我們手動新增，這樣很不方便。我們希望做到當然是我們是在Sentinel控制檯新增熔斷規則,自動將熔斷規則推送到Nacos資料來源。這樣當然也是

可以的。這樣的話改動的會多點，這裡就不做演示了 具體可以網上找找。

2)、這裡只演示了一個限流規則，如果你要新增熔斷規則等等其它規則，一樣也是可以的。


github地址 nacos-feign-sentinel



少說多做,句句都會得到別人的重視；多說少做,句句都會受到別人的忽視。(10)

相關文章