Sentinel限流、整形、熔斷降級介紹

文章目錄

• • 名詞解釋
  • • 叢集模式
    • 規則種類
  • 功能介紹
  • • • • 流量控制
        • 熔斷降級
        • 系統保護
        • 通路控制
        • 熱點規則
        • 網關流控
        • 叢集流控
        • • 名詞介紹
          • 獨立模式
          • 嵌入模式
  • 動态規則架構
  • • • • API模式
        • DataSource模式
        • • **DataSource 擴充常見的實作方式有:**
          • Sentinel 目前支援以下資料源擴充：
• gateway 動态路由配置參考文檔

名詞解釋

叢集模式

叢集流控中共有兩種身份：

• Token Client：叢集流控用戶端，用于向所屬 Token Server 通信請求 token。叢集限流服務端會傳回給用戶端結果，決定是否限流。
• Token Server：即叢集流控服務端，處理來自 Token Client 的請求，根據配置的叢集規則判斷是否應該發放 token（是否允許通過）。

Sentinel 叢集限流服務端有兩種啟動方式：

• 獨立模式（Alone），即作為獨立的 token server 程序啟動，獨立部署，隔離性好，但是需要額外的部署操作。獨立模式适合作為 Global Rate Limiter 給叢集提供流控服務。

  [外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-M2RA9DGL-1597613153374)(https://user-images.githubusercontent.com/9434884/50463606-c3d26c00-09c7-11e9-8373-1c27e2408f8b.png)]

• 嵌入模式（Embedded），即作為内置的 token server 與服務在同一程序中啟動。在此模式下，叢集中各個執行個體都是對等的，token server 和 client 可以随時進行轉變，是以無需單獨部署，靈活性比較好。但是隔離性不佳，需要限制 token server 的總 QPS，防止影響應用本身。嵌入模式适合某個應用叢集内部的流控。

  [外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-GfoKFliu-1597613153376)(https://user-images.githubusercontent.com/9434884/50463600-b7e6aa00-09c7-11e9-9580-6919f0d0a8a4.png)]

規則種類

• 流量控制規則
• 熔斷降級規則
• 系統保護規則
• 通路控制規則
• 熱點規則
• 網關流控
• 叢集流控

功能介紹

流量控制

（flow control），其原理是監控應用流量的 QPS 或并發線程數等名額，當達到指定的門檻值時對流量進行控制，以避免被瞬時的流量高峰沖垮，進而保障應用的高可用性。

流量控制

• resource

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

• count

  : 限流門檻值
• grade: 限流門檻值類型（QPS 或并發線程數(ThreadDemo)）

• limitApp

  : 流控針對的調用來源，若為

  default

  則不區分調用來源

• strategy

  : 調用關系限流政策

• controlBehavior

  : 流量控制效果（直接拒絕、Warm Up、勻速排隊）
  • 直接拒絕（

    RuleConstant.CONTROL_BEHAVIOR_DEFAULT

    ）方式是預設的流量控制方式，當QPS超過任意規則的門檻值後，新的請求就會被立即拒絕，拒絕方式為抛出

    FlowException

    。這種方式适用于對系統處理能力确切已知的情況下，比如通過壓測确定了系統的準确水位時。具體的例子參見 FlowQpsDemo。 令牌原理
  • Warm Up（

    RuleConstant.CONTROL_BEHAVIOR_WARM_UP

    ）方式，即預熱/冷啟動方式。當系統長期處于低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間内逐漸增加到門檻值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。詳細文檔可以參考 流量控制 - Warm Up 文檔，具體的例子可以參見 WarmUpFlowDemo。 低水位流量緩慢增加
  • 勻速排隊（

    RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER

    ）方式會嚴格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應的是漏桶算法。詳細文檔可以參考 流量控制 - 勻速器模式，具體的例子可以參見 PaceFlowDemo。 漏桶原理

熔斷降級

除了流量控制以外，對調用鍊路中不穩定的資源進行熔斷降級也是保障高可用的重要措施之一。由于調用關系的複雜性，如果調用鍊路中的某個資源不穩定，最終會導緻請求發生堆積。Sentinel 熔斷降級會在調用鍊路中某個資源出現不穩定狀态時（例如調用逾時或異常比例升高），對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導緻級聯錯誤。當資源被降級後，在接下來的降級時間視窗之内，對該資源的調用都自動熔斷（預設行為是抛出

DegradeException

）。

RT Degrade demo

熔斷降級

• 平均響應時間 (

  DEGRADE_GRADE_RT

  )：當 1s 内持續進入 N 個請求，對應時刻的平均響應時間（秒級）均超過門檻值（

  count

  ，以 ms 為機關），那麼在接下的時間視窗（

  DegradeRule

  中的

  timeWindow

  ，以 s 為機關）之内，對這個方法的調用都會自動地熔斷（抛出

  DegradeException

  ）。注意 Sentinel 預設統計的 RT 上限是 4900 ms，超出此門檻值的都會算作 4900 ms，若需要變更此上限可以通過啟動配置項

  -Dcsp.sentinel.statistic.max.rt=xxx

  來配置。
• 異常比例 (

  DEGRADE_GRADE_EXCEPTION_RATIO

  )：當資源的每秒請求量 >= N（可配置），并且每秒異常總數占通過量的比值超過門檻值（

  DegradeRule

  中的

  count

  ）之後，資源進入降級狀态，即在接下的時間視窗（

  DegradeRule

  中的

  timeWindow

  ，以 s 為機關）之内，對這個方法的調用都會自動地傳回。異常比率的門檻值範圍是

  [0.0, 1.0]

  ，代表 0% - 100%。
• 異常數 (

  DEGRADE_GRADE_EXCEPTION_COUNT

  )：當資源近 1 分鐘的異常數目超過門檻值之後會進行熔斷。注意由于統計時間視窗是分鐘級别的，若

  timeWindow

  小于 60s，則結束熔斷狀态後仍可能再進入熔斷狀态。

系統保護

系統保護規則是從應用級别的入口流量進行控制，從單台機器的 load、CPU 使用率、平均 RT、入口 QPS 和并發線程數等幾個次元監控應用名額，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。

系統保護規則是應用整體次元的，而不是資源次元的，并且僅對入口流量生效。入口流量指的是進入應用的流量（

EntryType.IN

），比如 Web 服務或 Dubbo 服務端接收的請求，都屬于入口流量。

SystemGuardDemo

系統自适應限流

• Load 自适應（僅對 Linux/Unix-like 機器生效）：系統的 load1 作為啟發名額，進行自适應系統保護。當系統 load1 超過設定的啟發值，且系統目前的并發線程數超過估算的系統容量時才會觸發系統保護（BBR 階段）。系統容量由系統的

  maxQps * minRt

  估算得出。設定參考值一般是

  CPU cores * 2.5

  。
• CPU usage（1.5.0+ 版本）：當系統 CPU 使用率超過門檻值即觸發系統保護（取值範圍 0.0-1.0），比較靈敏。
• 平均 RT：當單台機器上所有入口流量的平均 RT 達到門檻值即觸發系統保護，機關是毫秒。
• 并發線程數：當單台機器上所有入口流量的并發線程數達到門檻值即觸發系統保護。
• 入口 QPS：當單台機器上所有入口流量的 QPS 達到門檻值即觸發系統保護。

通路控制

很多時候，我們需要根據調用來源來判斷該次請求是否允許放行，這時候可以使用 Sentinel 的來源通路控制（黑白名單控制）的功能。來源通路控制根據資源的請求來源（

origin

）限制資源是否通過，若配置白名單則隻有請求來源位于白名單内時才可通過；若配置黑名單則請求來源位于黑名單時不通過，其餘的請求通過。

調用方資訊通過

ContextUtil.enter(resourceName, origin)

方法中的

origin

參數傳入。

AuthorityDemo

黑白名單控制

• resource

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

• limitApp

  ：對應的黑名單/白名單，不同 origin 用

  ,

  分隔，如

  appA,appB

  。

• strategy

  ：限制模式，

  AUTHORITY_WHITE

  為白名單模式，

  AUTHORITY_BLACK

  為黑名單模式，預設為白名單模式。

熱點規則

熱點即經常通路的資料。很多時候我們希望統計某個熱點資料中通路頻次最高的 Top K 資料，并對其通路進行限制。比如：

• 商品 ID 為參數，統計一段時間内最常購買的商品 ID 并進行限制
• 使用者 ID 為參數，針對一段時間内頻繁通路的使用者 ID 進行限制

sentinel-demo-parameter-flow-control

熱點參數限流

熱點參數規則（

ParamFlowRule

）類似于流量控制規則（

FlowRule

）：

屬性	說明	預設值
resource	資源名，必填
count	限流門檻值，必填
grade	限流模式	QPS 模式
durationInSec	統計視窗時間長度（機關為秒），1.6.0 版本開始支援	1s
controlBehavior	流控效果（支援快速失敗和勻速排隊模式），1.6.0 版本開始支援	快速失敗
maxQueueingTimeMs	最大排隊等待時長（僅在勻速排隊模式生效），1.6.0 版本開始支援	0ms
paramIdx	熱點參數的索引，必填，對應 SphU.entry(xxx, args) 中的參數索引位置
paramFlowItemList	參數例外項，可以針對指定的參數值單獨設定限流門檻值，不受前面 count 門檻值的限制。僅支援基本類型和字元串類型
clusterMode	是否是叢集參數流控規則	false
clusterConfig	叢集流控相關配置

網關流控

使用者可以通過

GatewayRuleManager.loadRules(rules)

手動加載網關規則，或通過

GatewayRuleManager.register2Property(property)

注冊動态規則源動态推送（推薦方式）。

網關流控

叢集流控

叢集流控

名詞介紹

• Token Client：叢集流控用戶端，用于向所屬 Token Server 通信請求 token。叢集限流服務端會傳回給用戶端結果，決定是否限流。
• Token Server：即叢集流控服務端，處理來自 Token Client 的請求，根據配置的叢集規則判斷是否應該發放 token（是否允許通過）。

獨立模式

獨立模式（Alone），即作為獨立的 token server 程序啟動，獨立部署，隔離性好，但是需要額外的部署操作。獨立模式适合作為 Global Rate Limiter 給叢集提供流控服務。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-6tcemr0Y-1597613153377)(https://user-images.githubusercontent.com/9434884/50463606-c3d26c00-09c7-11e9-8373-1c27e2408f8b.png)]

嵌入模式

嵌入模式（Embedded），即作為内置的 token server 與服務在同一程序中啟動。在此模式下，叢集中各個執行個體都是對等的，token server 和 client 可以随時進行轉變，是以無需單獨部署，靈活性比較好。但是隔離性不佳，需要限制 token server 的總 QPS，防止影響應用本身。嵌入模式适合某個應用叢集内部的流控。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-g5DOlI8D-1597613153378)(https://user-images.githubusercontent.com/9434884/50463600-b7e6aa00-09c7-11e9-9580-6919f0d0a8a4.png)]

動态規則架構

動态規則

API模式

Sentinel Dashboard 通過用戶端自帶的規則 API來實時查詢和更改記憶體中的規則。

DataSource模式

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-9ELBNJYL-1597613153379)(https://user-images.githubusercontent.com/9434884/45406233-645e8380-b698-11e8-8199-0c917403238f.png)]

DataSource 擴充常見的實作方式有:

• 拉模式：用戶端主動向某個規則管理中心定期輪詢拉取規則，這個規則中心可以是 RDBMS、檔案，甚至是 VCS 等。這樣做的方式是簡單，缺點是無法及時擷取變更；
• 推模式：規則中心統一推送，用戶端通過注冊監聽器的方式時刻監聽變化，比如使用 Nacos、Zookeeper 等配置中心。這種方式有更好的實時性和一緻性保證。

Sentinel 目前支援以下資料源擴充：

• Pull-based: 檔案、Consul
• Push-based: ZooKeeper, Redis, Nacos, Apollo, etcd

gateway 動态路由配置參考文檔

• 待補充！