這是圍繞 Sentinel 的使用場景、技術(shù)對比和實現(xiàn)、開發(fā)者實踐等維度推出的系列文章的第四篇。

• 第一篇回顧：

Dubbo 的流量防衛(wèi)兵 | Sentinel如何通過限流實現(xiàn)服務(wù)的高可用性 -?傳送門

• 第二篇回顧：

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

• 第三篇回顧：

技術(shù)選型：Sentinel vs Hystrix -?傳送門

Sentinel 是阿里中間件團隊研發(fā)的面向分布式服務(wù)架構(gòu)的輕量級高可用流量控制組件，于今年7月正式開源。Sentinel 主要以流量為切入點，從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度來幫助用戶提升服務(wù)的穩(wěn)定性。

Sentinel 項目地址：

https://github.com/alibaba/Sentinel

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

在生產(chǎn)環(huán)境中使用 Sentinel 控制臺只需要兩步改造：

改造推送邏輯，支持向規(guī)則數(shù)據(jù)源進行推送

改造監(jiān)控邏輯，支持監(jiān)控數(shù)據(jù)持久化

動態(tài)規(guī)則數(shù)據(jù)源

Sentinel 的動態(tài)規(guī)則數(shù)據(jù)源用于從中讀取及寫入規(guī)則。從 0.2.0 版本開始，Sentinel 將動態(tài)規(guī)則數(shù)據(jù)源分為兩種類型：讀數(shù)據(jù)源（ReadableDataSource）和寫數(shù)據(jù)源（WritableDataSource）：

• 讀數(shù)據(jù)源僅負責(zé)監(jiān)聽或輪詢讀取遠程存儲的變更。
• 寫數(shù)據(jù)源僅負責(zé)將規(guī)則變更寫入到規(guī)則源中。

其中讀數(shù)據(jù)源常見的實現(xiàn)方式有:

• pull 模式：客戶端主動向某個規(guī)則管理中心定期輪詢拉取規(guī)則，這個規(guī)則中心可以是 RDBMS、文件 等。這樣做的方式是簡單，缺點是可能無法及時獲取變更，拉取過于頻繁也可能會有性能問題。
• push 模式：規(guī)則中心統(tǒng)一推送，客戶端通過注冊監(jiān)聽器的方式時刻監(jiān)聽變化，比如使用 Nacos、Zookeeper 等配置中心。這種方式有更好的實時性和一致性保證。

在實際的場景中，不同的存儲類型對應(yīng)的數(shù)據(jù)源類型也不同。對于 push 模式的數(shù)據(jù)源，一般不支持寫入；而 pull 模式的數(shù)據(jù)源則是可寫的。

下面我們分別來分析一下它們結(jié)合 Sentinel 控制臺的使用場景，以及相應(yīng)的需要改造的點。

| 原始情況

若應(yīng)用未注冊任何數(shù)據(jù)源，直接從 Sentinel 控制臺推送規(guī)則的過程非常簡單：

Sentinel 控制臺通過 API 將規(guī)則推送至客戶端并直接更新到內(nèi)存中。這種情況下應(yīng)用重啟規(guī)則就會消失，僅用于簡單測試，不能用于生產(chǎn)環(huán)境。一般在生產(chǎn)環(huán)境中，我們需要在應(yīng)用端配置規(guī)則數(shù)據(jù)源。

| pull 模式的數(shù)據(jù)源

pull 模式的數(shù)據(jù)源（如本地文件、RDBMS 等）一般是可寫入的。使用時需要在客戶端注冊數(shù)據(jù)源：將對應(yīng)的讀數(shù)據(jù)源注冊至對應(yīng)的 RuleManager，將寫數(shù)據(jù)源注冊至 transport 的?WritableDataSourceRegistry?中。以本地文件數(shù)據(jù)源為例：

public class FileDataSourceInit implements InitFunc {@Overridepublic void init() throws Exception {String flowRulePath = "xxx";ReadableDataSource<String, List<FlowRule>> ds = new FileRefreshableDataSource<>(flowRulePath, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));// 將可讀數(shù)據(jù)源注冊至 FlowRuleManager.FlowRuleManager.register2Property(ds.getProperty());WritableDataSource<List<FlowRule>> wds = new FileWritableDataSource<>(flowRulePath, this::encodeJson);// 將可寫數(shù)據(jù)源注冊至 transport 模塊的 WritableDataSourceRegistry 中.// 這樣收到控制臺推送的規(guī)則時，Sentinel 會先更新到內(nèi)存，然后將規(guī)則寫入到文件中.WritableDataSourceRegistry.registerFlowDataSource(wds);}private <T> String encodeJson(T t) {return JSON.toJSONString(t);} }

本地文件數(shù)據(jù)源會定時輪詢文件的變更，讀取規(guī)則。這樣我們既可以在應(yīng)用本地直接修改文件來更新規(guī)則，也可以通過 Sentinel 控制臺推送規(guī)則。以本地文件數(shù)據(jù)源為例，推送過程如下圖所示：

首先 Sentinel 控制臺通過 API 將規(guī)則推送至客戶端并更新到內(nèi)存中，接著注冊的寫數(shù)據(jù)源會將新的規(guī)則保存到本地的文件中。使用 pull 模式的數(shù)據(jù)源時一般不需要對 Sentinel 控制臺進行改造。

| push 模式的數(shù)據(jù)源

對于 push 模式的數(shù)據(jù)源（如遠程配置中心），推送的操作不應(yīng)由 Sentinel 數(shù)據(jù)源進行，而應(yīng)該經(jīng)控制臺進行推送，數(shù)據(jù)源僅負責(zé)獲取配置中心推送的配置并更新到本地。

假設(shè)寫入的操作也由數(shù)據(jù)源進行，那么 Sentinel 客戶端收到控制臺推送的規(guī)則后，將新的規(guī)則更新到內(nèi)存中，同時將規(guī)則推送至遠程的配置中心。此時，數(shù)據(jù)源監(jiān)聽到配置中心推送過來的新規(guī)則，又一次更新到內(nèi)存中。也就是說應(yīng)用在本地更新完規(guī)則并推送到遠程后，又要接收變更并更新一次，這樣顯然是不合理的。因此推送規(guī)則正確做法應(yīng)該是?配置中心控制臺/Sentinel 控制臺 → 配置中心 → Sentinel 數(shù)據(jù)源 → Sentinel，而不是經(jīng) Sentinel 數(shù)據(jù)源推送至配置中心。這樣的流程就非常清晰了：

注意由于不同的生產(chǎn)環(huán)境可能使用不同的數(shù)據(jù)源，從 Sentinel 控制臺推送至配置中心的實現(xiàn)需要用戶自行改造。以 ZooKeeper 為例，我們可以按照如下步驟進行改造（假設(shè)推送維度為應(yīng)用維度）：

實現(xiàn)一個公共的 ZooKeeper 客戶端用于推送規(guī)則，在 Sentinel 控制臺配置項中需要指定 ZooKeeper 的地址，啟動時即創(chuàng)建 ZooKeeper Client。

我們需要針對每個應(yīng)用（appName），每種規(guī)則設(shè)置不同的 path（可隨時修改）；或者約定大于配置（如 path 的模式統(tǒng)一為?/sentinel_rules/{appName}/{ruleType}，e.g.?sentinel_rules/appA/flowRule）。

規(guī)則配置頁需要進行相應(yīng)的改造，直接針對應(yīng)用維度進行規(guī)則配置；修改同個應(yīng)用多個資源的規(guī)則時可以批量進行推送，也可以分別推送。Sentinel 控制臺將規(guī)則緩存在內(nèi)存中（如?InMemFlowRuleStore），可以對其進行改造使其支持應(yīng)用維度的規(guī)則緩存（key 為 appName），每次添加/修改/刪除規(guī)則都先更新內(nèi)存中的規(guī)則緩存，然后需要推送的時候從規(guī)則緩存中獲取全量規(guī)則，然后通過上面實現(xiàn)的 Client 將規(guī)則推送到 ZooKeeper 即可。

應(yīng)用客戶端需要注冊對應(yīng)的讀數(shù)據(jù)源以監(jiān)聽變更，可以參考?相關(guān)文檔。

監(jiān)控數(shù)據(jù)持久化

Sentinel 會記錄資源訪問的秒級數(shù)據(jù)（若沒有訪問則不進行記錄）并保存在本地日志中，具體格式請見?秒級監(jiān)控日志文檔。Sentinel 控制臺通過?Sentinel 客戶端預(yù)留的 API?從秒級監(jiān)控日志中拉取監(jiān)控數(shù)據(jù)，并進行聚合。目前 Sentinel 控制臺中監(jiān)控數(shù)據(jù)聚合后直接存在內(nèi)存中，未進行持久化，且僅保留最近 5 分鐘的監(jiān)控數(shù)據(jù)。若需要監(jiān)控數(shù)據(jù)持久化的功能，可以自行擴展實現(xiàn)?MetricsRepository?接口（0.2.0 版本），然后注冊成 Spring Bean 并在相應(yīng)位置通過?@Qualifier?注解指定對應(yīng)的 bean name 即可。MetricsRepository?接口定義了以下功能：

• save?與?saveAll：存儲對應(yīng)的監(jiān)控數(shù)據(jù)
• queryByAppAndResourceBetween：查詢某段時間內(nèi)的某個應(yīng)用的某個資源的監(jiān)控數(shù)據(jù)
• listResourcesOfApp：查詢某個應(yīng)用下的所有資源

其中默認的監(jiān)控數(shù)據(jù)類型為?MetricEntity，包含應(yīng)用名稱、時間戳、資源名稱、異常數(shù)、請求通過數(shù)、請求 block 數(shù)、平均響應(yīng)時間等信息。

同時用戶可以自行進行擴展，適配 Grafana 等可視化平臺，以便將監(jiān)控數(shù)據(jù)更好地進行可視化。

其它

在生產(chǎn)環(huán)境中使用 Sentinel 控制臺還需要考慮以下問題：

• 權(quán)限控制：生產(chǎn)環(huán)境下的權(quán)限控制是非常重要的，理論上只有 AppOps 或管理員才有權(quán)限去修改對應(yīng)應(yīng)用的規(guī)則。Sentinel 控制臺不提供權(quán)限控制功能，需要開發(fā)者自行進行改造。

同時也可以到?Awesome Sentinel?去參考社區(qū)用戶的一些擴展和解決方案，也歡迎大家將一些比較好的擴展實現(xiàn)添加進來。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的你只差这两步 | 将Sentinel 控制台应用于生产环境的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。