阿里 Sentinel 框架的一些小擴展

隨著微服務(wù)的流行，服務(wù)和服務(wù)之間的穩(wěn)定性變得越來越重要。Sentinel 是面向分布式服務(wù)架構(gòu)的流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統(tǒng)自適應(yīng)保護等多個維度來幫助您保障微服務(wù)的穩(wěn)定性。

今天給大家介紹一些在使用過程中會遇到的一些問題。

SentinelResource 埋點監(jiān)控

@SentinelResource 可以作用于方法上的熔斷降級保護，跟 Hystrix 的@HystrixCommand 注解作用是一樣的。

做監(jiān)控的目的是為了在業(yè)務(wù)方法觸發(fā)了熔斷降級規(guī)則后，在對應(yīng)的監(jiān)控視圖中可以看到這個操作觸發(fā)了對應(yīng)的規(guī)則。

@SentinelResource 的工作依賴于 SentinelResourceAspect 這個切面，需要監(jiān)控的話對 SentinelResourceAspect 這個類進行改造就可以了。

流控熔斷預(yù)警

在流量突然上升的時候，也就意味著隨時都可能迎來請求量的高峰，就會觸發(fā)限流。我們也需要有一定的監(jiān)控手段來提前告警，這種場景可以擴展 Slot 來實現(xiàn)提前告警的方案，具體方式可以查詢這篇文章：https://mp.weixin.qq.com/s/qhep2f9HgK7sZFcdKMAMVg

RestFul API 處理

在 Sentinel 中，以資源的概念來進行對應(yīng)的限流熔斷操作。如果你們的 API 是 RestFul 風格，就會出現(xiàn)同一個接口變成 N 個資源的情況。

可以用@SentinelResource 為每個接口固定好資源名，這樣比較繁瑣。所以需要對這類的 API 進行格式化，變成一個資源。相關(guān)實現(xiàn)參考：https://blog.csdn.net/luanlouis/article/details/91633042還挺全的。

核心原理就是重寫 UrlCleaner 的實現(xiàn)邏輯，利用正則進行匹配處理。

這類操作不僅僅是在 Sentinel 中會遇到，在其他的框架中也經(jīng)常會遇到這種情況。比如在 Cat 中也會有類似場景，對 API 進行監(jiān)控，如果不處理同樣會出現(xiàn) N 個監(jiān)控項。

Origin 來源限制

如果需要對某個調(diào)用方進行限流，我們可以利用 Origin 方式來實現(xiàn)。建議做成動態(tài)配置方式，比如支持 IP, 支持請求頭中的參數(shù)等方式進行限制。

內(nèi)部服務(wù)之間調(diào)用還可以將本服務(wù)的應(yīng)用名存放在請求頭中傳遞過去，這樣就可以在 Sentinel 中基于 Origin 來實現(xiàn)內(nèi)部服務(wù)調(diào)用的流量控制。

熱點參數(shù)動態(tài)流控

對于熱點參數(shù)的流控，也可以做成動態(tài)配置的方式。

比如當前是商品 ID 為熱點參數(shù)，后面是訂單 ID 為熱點參數(shù)。

比如當前是商品接口，后面是訂單接口。

可以從 url 參數(shù)中獲取熱點參數(shù)，可以從 header 中獲取熱點參數(shù)，可以從 path 路徑中獲取熱點參數(shù)。

增加一個配置信息，然后擴展 Sentinel 的 Filter 進行限流控制，根據(jù)配置獲取對應(yīng)的熱點參數(shù)進行限流。

限流規(guī)則持久化

限流規(guī)則持久化是肯定要做的，默認規(guī)則是存儲在內(nèi)存中，這樣一起動規(guī)則就丟失了，所以必須持久化。

持久化分為兩種，首先是客戶端，客戶端持久化意思是說客戶端需要加載對應(yīng)的規(guī)則，這些規(guī)則會從一個地方進行獲取，比如我們用 Apollo 配置中心來存儲的話，客戶端在啟動時就會從 Apollo 中去拉取對應(yīng)的規(guī)則信息。

對應(yīng)的操作步驟和詳細介紹可以查看下面這篇文章，雖然寫了很久了，但是總體思路什么的都沒變化。

Sentinel Client: 整合 Apollo 規(guī)則持久化：https://mp.weixin.qq.com/s/K9JtdGoLD1XALq5D67slPQ

然后是服務(wù)端也就是控制臺的持久化，我們可以在控制臺進行規(guī)則的添加和編輯，然后會把對應(yīng)的配置信息推送給所有的客戶端，這樣規(guī)則就生效了。

同樣存儲重啟即丟失的情況，所以控制臺也需要進行持久化規(guī)則。如果客戶端對接了 Apollo,那么控制也需要對接 Apollo 將規(guī)則信息存儲到 Apollo 中，這樣整個流程就連起來了。

可以參考這篇文章：阿里 Sentinel 控制臺:-整合 Apollo 規(guī)則持久化：https://mp.weixin.qq.com/s/deigVXhEd9HycuLLm-oJzA

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

Sentinel 控制臺的實時監(jiān)控數(shù)據(jù)，默認僅存儲 5 分鐘以內(nèi)的數(shù)據(jù)。如果需要持久化，需要實現(xiàn)框架提供的相關(guān)接口進行改造。

5 分鐘確實很短，最起碼要存儲最近 3 天的數(shù)據(jù)，這樣方便查看流量的趨勢。

關(guān)于相關(guān)實現(xiàn)大家可以去看文檔，比較簡單，主要就是實現(xiàn) MetricsRepository，將監(jiān)控的數(shù)據(jù)存儲到對應(yīng)的數(shù)據(jù)庫中。

相關(guān)改造源碼可以參考：https://github.com/yinjihuan/kitty/tree/master/kitty-distributed/kitty-distributed-sentinel

關(guān)于作者：尹吉歡，簡單的技術(shù)愛好者，《Spring Cloud 微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud 微服務(wù) 入門 實戰(zhàn)與進階》作者, 公眾號猿天地發(fā)起人。

我整理了一份很全的學習資料，感興趣的可以微信搜索「猿天地」，回復(fù)關(guān)鍵字 「學習資料」獲取我整理好了的 Spring Cloud，Spring Cloud Alibaba，Sharding-JDBC 分庫分表，任務(wù)調(diào)度框架 XXL-JOB，MongoDB，爬蟲等相關(guān)資料。