摘要： 這是圍繞 Sentinel 的使用場景、技術對比和實現、開發者實踐等維度推出的系列文章的第四篇。 第一篇回顧：Dubbo 的流量防衛兵 | Sentinel如何通過限流實現服務的高可用性 - 傳送門 第二篇回顧：RocketMQ 的保險絲| Sentinel 如何通過勻速請求和冷啟動來保障服務的穩定性 - 傳送門 第三篇回顧：技術選型：Sentinel vs Hystrix - 傳送門 Sentinel 是阿里中介軟體團隊研發的面向分散式服務架構的輕量級高可用式開源。

這是圍繞 Sentinel 的使用場景、技術對比和實現、開發者實踐等維度推出的系列文章的第四篇。

• 第一篇回顧：

Dubbo 的流量防衛兵 | Sentinel如何通過限流實現服務的高可用性 - 傳送門

• 第二篇回顧：

RocketMQ 的保險絲| Sentinel 如何通過勻速請求和冷啟動來保障服務的穩定性 - 傳送門

• 第三篇回顧：

技術選型：Sentinel vs Hystrix - 傳送門

Sentinel 是阿里中介軟體團隊研發的面向分散式服務架構的輕量級高可用流量控制組件，於今年7月正式開源。Sentinel 主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助使用者提升服務的穩定性。

Sentinel 控制檯作為 Sentinel 的一大利器，提供了多個維度的監控和規則配置功能。Sentinel 客戶端目前已可用於生產環境，但若希望在生產環境中使用 Sentinel 控制檯還需要進行一些改造。本文將介紹如何對 Sentinel 控制檯進行改造以便在生產環境中使用。

在生產環境中使用 Sentinel 控制檯只需要兩步改造：

1. 改造推送邏輯，支援向規則資料來源進行推送
2. 改造監控邏輯，支援監控資料持久化

動態規則資料來源

Sentinel 的動態規則資料來源用於從中讀取及寫入規則。從 0.2.0 版本開始，Sentinel 將動態規則資料來源分為兩種型別：讀資料來源（ReadableDataSource）和寫資料來源（WritableDataSource）：

• 讀資料來源僅負責監聽或輪詢讀取遠端儲存的變更。

• 寫資料來源僅負責將規則變更寫入到規則源中。

其中讀資料來源常見的實現方式有:

• pull 模式：客戶端主動向某個規則管理中心定期輪詢拉取規則，這個規則中心可以是 RDBMS、檔案 等。這樣做的方式是簡單，缺點是可能無法及時獲取變更，拉取過於頻繁也可能會有效能問題。

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

在實際的場景中，不同的儲存型別對應的資料來源型別也不同。對於 push 模式的資料來源，一般不支援寫入；而 pull 模式的資料來源則是可寫的。

下面我們分別來分析一下它們結合 Sentinel 控制檯的使用場景，以及相應的需要改造的點。

原始情況

若應用未註冊任何資料來源，直接從 Sentinel 控制檯推送規則的過程非常簡單：

Sentinel 控制檯通過 API 將規則推送至客戶端並直接更新到記憶體中。這種情況下應用重啟規則就會消失，僅用於簡單測試，不能用於生產環境。一般在生產環境中，我們需要在應用端配置規則資料來源。

pull 模式的資料來源

pull 模式的資料來源（如本地檔案、RDBMS 等）一般是可寫入的。使用時需要在客戶端註冊資料來源：將對應的讀資料來源註冊至對應的 RuleManager，將寫資料來源註冊至 transport 的 WritableDataSourceRegistry 中。以本地檔案資料來源為例：

本地檔案資料來源會定時輪詢檔案的變更，讀取規則。這樣我們既可以在應用本地直接修改檔案來更新規則，也可以通過 Sentinel 控制檯推送規則。以本地檔案資料來源為例，推送過程如下圖所示：

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

push 模式的資料來源

對於 push 模式的資料來源（如遠端配置中心），推送的操作不應由 Sentinel 資料來源進行，而應該經控制檯進行推送，資料來源僅負責獲取配置中心推送的配置並更新到本地。

假設寫入的操作也由資料來源進行，那麼 Sentinel 客戶端收到控制檯推送的規則後，將新的規則更新到記憶體中，同時將規則推送至遠端的配置中心。此時，資料來源監聽到配置中心推送過來的新規則，又一次更新到記憶體中。也就是說應用在本地更新完規則並推送到遠端後，又要接收變更並更新一次，這樣顯然是不合理的。因此推送規則正確做法應該是 配置中心控制檯/Sentinel 控制檯 → 配置中心 → Sentinel 資料來源 → Sentinel，而不是經 Sentinel 資料來源推送至配置中心。這樣的流程就非常清晰了：

注意由於不同的生產環境可能使用不同的資料來源，從 Sentinel 控制檯推送至配置中心的實現需要使用者自行改造。以 ZooKeeper 為例，我們可以按照如下步驟進行改造（假設推送維度為應用維度）：

1. 實現一個公共的 ZooKeeper 客戶端用於推送規則，在 Sentinel 控制檯配置項中需要指定 ZooKeeper 的地址，啟動時即建立 ZooKeeper Client。
2. 我們需要針對每個應用（appName），每種規則設定不同的 path（可隨時修改）；或者約定大於配置（如 path 的模式統一為 /sentinel_rules/{appName}/{ruleType}，e.g. sentinel_rules/appA/flowRule）。
3. 規則配置頁需要進行相應的改造，直接針對應用維度進行規則配置；修改同個應用多個資源的規則時可以批量進行推送，也可以分別推送。Sentinel 控制檯將規則快取在記憶體中（如 InMemFlowRuleStore），可以對其進行改造使其支援應用維度的規則快取（key 為 appName），每次新增/修改/刪除規則都先更新記憶體中的規則快取，然後需要推送的時候從規則快取中獲取全量規則，然後通過上面實現的 Client 將規則推送到 ZooKeeper 即可。
4. 應用客戶端需要註冊對應的讀資料來源以監聽變更，可以參考 相關文件。

監控資料持久化

Sentinel 會記錄資源訪問的秒級資料（若沒有訪問則不進行記錄）並儲存在本地日誌中，具體格式請見 秒級監控日誌文件。Sentinel 控制檯通過 Sentinel 客戶端預留的 API 從秒級監控日誌中拉取監控資料，並進行聚合。目前 Sentinel 控制檯中監控資料聚合後直接存在記憶體中，未進行持久化，且僅保留最近 5 分鐘的監控資料。若需要監控資料持久化的功能，可以自行擴充套件實現 MetricsRepository 介面（0.2.0 版本），然後註冊成 Spring Bean 並在相應位置通過 @Qualifier 註解指定對應的 bean name 即可。MetricsRepository 介面定義了以下功能：

• save 與 saveAll：儲存對應的監控資料

• queryByAppAndResourceBetween：查詢某段時間內的某個應用的某個資源的監控資料

• listResourcesOfApp：查詢某個應用下的所有資源

其中預設的監控資料型別為 MetricEntity，包含應用名稱、時間戳、資源名稱、異常數、請求通過數、請求 block 數、平均響應時間等資訊。

同時使用者可以自行進行擴充套件，適配 Grafana 等視覺化平臺，以便將監控資料更好地進行視覺化。

其它

在生產環境中使用 Sentinel 控制檯還需要考慮以下問題：

• 許可權控制：生產環境下的許可權控制是非常重要的，理論上只有 AppOps 或管理員才有許可權去修改對應應用的規則。Sentinel 控制檯不提供許可權控制功能，需要開發者自行進行改造。

同時也可以到 Awesome Sentinel 去參考社群使用者的一些擴充套件和解決方案，也歡迎大家將一些比較好的擴充套件實現新增進來。

本文作者：中介軟體小哥

閱讀原文