spring-cloud-alibaba-3.2-Sentinel-控制規則

概覽

流控規則

sentinel流控規則

資源名-resource

資源名，即限流規則的作用對象。

默認爲RESTful請求的url地址， 也可以通過@SentinelResource指定。

針對來源-limitApp

• default：表示不區分調用者，來自任何調用者的請求都將進行限流統計。

• {some_origin_name}：表示針對特定的調用者，只有來自這個調用者的請求才會進行流量控制。

• other：表示針對除 {some_origin_name} 以外的其餘調用方的流量進行流量控制。

  例如，

  資源NodeA配置了一條針對調用者 caller1 的限流規則，

  同時又配置了一條調用者爲 other的規則，

  那麼任意來自非 caller1 對 NodeA 的調用，都不能超過 other 這條規則定義的閾值。

同一個資源名可以配置多條規則，規則的生效順序爲：{some_origin_name} > other > default

閾值類型

• 併發線程數流量控制(RuleConstant.FLOW_GRADE_THREAD = 0)：線程數限流用於保護業務線程數不被耗盡。

  例如，當應用所依賴的下游應用由於某種原因導致服務不穩定、響應延遲增加，對於調用者來說，意味着吞吐量下降和更多的線程數佔用，極端情況下甚至導致線程池耗盡。爲應對高線程佔用的情況，業內有使用隔離的方案，比如通過不同業務邏輯使用不同線程池來隔離業務自身之間的資源爭搶（線程池隔離），或者使用信號量來控制同時請求的個數（信號量隔離）。這種隔離方案雖然能夠控制線程數量，但無法控制請求排隊時間。當請求過多時排隊也是無益的，直接拒絕能夠迅速降低系統壓力。

  Sentinel線程數限流不負責創建和管理線程池，而是簡單統計當前請求上下文的線程個數，如果超出閾值，新的請求會被立即拒絕。

• QPS流量控制(RuleConstant.FLOW_GRADE_QPS = 1): 當 QPS 超過某個閾值的時候，則採取措施進行流量控制。

• 單機閾值count

流控模式-strategy

• 直接(RuleConstant.STRATEGY_DIRECT = 0): 默認,根據調用方限流。

• 關聯(RuleConstant.STRATEGY_RELATE = 1)： 當兩個資源之間具有資源爭搶或者依賴關係的時候，這兩個資源便具有了關聯。

  比如訂單/order接口處理會依賴 支付/pay，當支付接口卡單時，需要限制訂單接口的流量。

• 鏈路(RuleConstant.STRATEGY_CHAIN = 2)： 只統計某些入口的流量。

  NodeSelectorSlot 中記錄了資源之間的調用鏈路，這些資源通過調用關係，相互之間構成一棵調用樹。

  				   machine-root
                      /       \
                     /         \
               Entrance1     Entrance2
                  /             \
                 /               \
        DefaultNode(nodeA)   DefaultNode(nodeA)
  

  通過如下配置，只統計Entrance1流入到nodeA的流量。
  

流控效果-controlBehavior

流控效果，必須在閾值類型設置爲QPS時有效，否則無效。

• 直接拒絕（RuleConstant.CONTROL_BEHAVIOR_DEFAULT = 0）

• 預熱（RuleConstant.CONTROL_BEHAVIOR_WARM_UP = 1）: 即預熱/冷啓動方式。當系統長期處於低水位的情況下，當流量突然增加時，直接把系統拉昇到高水位可能瞬間把系統壓垮。通過"冷啓動"，讓通過的流量緩慢增加，在一定時間內逐漸增加至閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

  公式： 冷加載因子（codeFactor 默認值爲3）,請求閾值從count/3開始，經過預熱時長主鍵升到設定的QPS閾值

  如，秒殺系統，剛開始時大批量的請求過來，會將系統擠垮，通過預熱時長後，才慢慢提升到設定的QPS.

• 勻速器（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER =2）: 嚴格控制請求通過的間隔時間漏斗算法,

  這種方式主要用於處理間隔性突發的流量，例如消息隊列。想象一下這樣的場景，在某一秒有大量的請求到來，而接下來的幾秒則處於空閒狀態，我們希望系統能夠在接下來的空閒期間逐漸處理這些請求，而不是在第一秒直接拒絕多餘的請求。

熔斷降級

熔斷降級

降級策略

• 平均響應時間 (DEGRADE_GRADE_RT)：當資源的平均響應時間超過閾值之後，資源進入準降級狀態。接下來如果持續進入5個請求，它們的 RT 都持續超過這個閾值，那麼在接下的時間窗口（之內，對這個方法的調用都會自動地返回（拋出 DegradeException）,即熔斷。

  • 超出此閾值的都會算作 4900 ms，若需要變更此上限可以通過啓動配置項 -Dcsp.sentinel.statistic.max.rt=xxx來配置。

  • sentinel斷路器沒有半開狀態`，只有在時間窗口期結束後，關閉降級。

• 異常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：當資源的每秒異常總數佔通過量的比值超過閾值之後，資源進入降級狀態。

  • 異常比率的閾值範圍是 [0.0, 1.0]，代表 0% - 100%。

• 異常數 (DEGRADE_GRADE_EXCEPTION_COUNT)：當資源近 1 分鐘的異常數目超過閾值之後會進行熔斷。

熱點規則

熱點key

何爲熱點？熱點即經常訪問的數據。很多時候我們希望統計某個熱點數據中訪問頻次最高的 Top K 數據，並對其訪問進行限制.

• 商品 ID 爲參數，統計一段時間內最常購買的商品 ID 並進行限制
• 用戶 ID 爲參數，針對一段時間內頻繁訪問的用戶 ID 進行限制

熱點參數限流會統計傳入參數中的熱點參數，並根據配置的限流閾值與模式，對包含熱點參數的資源調用進行限流。熱點參數限流可以看做是一種特殊的流量控制，僅對包含熱點參數的資源調用生效。

測試代碼

@RequestMapping("/testHotKey")
@SentinelResource(value = "testHotKey" ,blockHandler = "deal_testHotKey")
public String testHotKey(@RequestParam(required = false) String p1,@RequestParam(required = false)  String p2) {
    return "---- testHotKey";
}

public String deal_testHotKey(String p1, String p2, BlockException blockException) {
    return "deal_testHotKey";
}

配置

系統規則

系統自適應保護

系統保護規則是從應用級別的入口流量進行控制，從單臺機器的總體 Load、RT、入口 QPS 和線程數四個維度監控應用數據，讓系統儘可能跑在最大吞吐量的同時保證系統整體的穩定性。

系統保護規則是應用整體維度的，而不是資源維度的，並且僅對入口流量生效。入口流量指的是進入應用的流量（EntryType.IN），比如 Web 服務或 Dubbo 服務端接收的請求，都屬於入口流量。

• Load（僅對 Linux/Unix-like 機器生效）：當系統 load1 超過閾值，且系統當前的併發線程數超過系統容量時纔會觸發系統保護。系統容量由系統的 maxQps * minRt 計算得出。設定參考值一般是 CPU cores * 2.5。
• CPU usage（1.5.0+ 版本）：當系統 CPU 使用率超過閾值即觸發系統保護（取值範圍 0.0-1.0）。
• RT：當單臺機器上所有入口流量的平均 RT 達到閾值即觸發系統保護，單位是毫秒。
• 線程數：當單臺機器上所有入口流量的併發線程數達到閾值即觸發系統保護。
• 入口 QPS：當單臺機器上所有入口流量的 QPS 達到閾值即觸發系統保護。

授權規則

來源訪問控制(黑白名單)

很多時候，我們需要根據調用方來限制資源是否通過，這時候可以使用 Sentinel 的黑白名單控制的功能。黑白名單根據資源的請求來源（origin）限制資源是否通過，若配置白名單則只有請求來源位於白名單內時纔可通過；若配置黑名單則請求來源位於黑名單時不通過，其餘的請求通過。

集羣流量控制

爲什麼要使用集羣流控呢？假設我們希望給某個用戶限制調用某個 API 的總 QPS 爲 50，但機器數可能很多（比如有 100 臺）。這時候我們很自然地就想到，找一個 server 來專門來統計總的調用量，其它的實例都與這臺 server 通信來判斷是否可以調用。這就是最基礎的集羣流控的方式。

集羣流量控制

Sentinel-控制檯（集羣流控管理）