1、Sentinel 系統自適應概述

從官方了解到 Sentienl 系統自適應限流是一個全局的概念，對應用入口流量統一進行統一控制，結合應用的機器負載、CPU 使用率，總體平均響應時間、入口 QPS 和并發線程數等幾個維度的監控指標從而決定是否調用進行限流操作。為了有一個直觀的感受，我們可以從官方的運維平臺看看其系統自適應限流的操作界面：

 

在詳細分析系統自適應實現原理之前我們先來思考一下 Sentinel 引入該機制的目的。

官方文檔針對這個問題有過仔細闡述，我們先來看看官方文檔對其闡述。

引入系統自適應限流的主要的目的有如下兩個：

• 保證系統不被拖垮

• 在系統穩定的前提下保證系統的吞吐量。

目前我們接觸的限流的防護思路都是設定一個指標（闊值），例如系統的負載 load 超過某個闊值后就阻止或減少流量的繼續進入，當系統負載降低到某一水平后則恢復流量的進入。通常都是被動的，其實際效果取決于闊值設置是否合理，但往往設置合理不是一件容易的事情。

那 Sentinel 提供的系統自適應是可以將設定的規則作為一個保護因子，而允許通過的流量由處理請求的能力來決定，即根據請求的響應時間、當前系統正在處理的請求速率來決定。

那 Sentinel 是如何實現的呢？接下來用源碼的手段來揭曉其實現原理。

2、系統自適應限流原理

Sentinel 執行系統限流的核心入口類為 SystemSlot，該類實現簡單，如下圖所示：

 

2.1 自適應限流檢測流程

系統自適應限流檢測具體由 SystemRuleManager 的 checkSystem 方法實現，接下來詳細剖析其實現細節。

 

• 如果資源名稱為空，則直接跳過，這個是容錯機制。

  如果系統自適應開關為打開，直接放行，該開關初始化時為 false，在加載到一條系統自適應配置規則時該狀態會設置為 true，具體在 loadSystemConf 中。

  如果資源的類型不是入口流量(EntryType.IN),則直接放行。

Step2：從QPS為維度驗證是否需要被限流，其實現關鍵點如下：

• 當前的qps，如果 ENTRY_NODE 為空則返回0，否則返回該統計節點的成功 qps，那 ENTRY_NODE 統計節點是“何許人也”，原來是 Sentinel 特定定義了一個資源，其名稱為total_inbound_traffic，用來采集所有入口調用的信息，當資源進入類型為 ENTRY_TYPE_IN 時，會自動采集信息，其具體統計信息在 StatisticSlot 的 entry 方法中被調用，其截圖如下：
  

     

• 如果當前調用的 QPS 大于設定的QPS，即觸發限流，那這個 qps 又是在什么時候被設置的呢？也是在加載系統限流規則時被設置，如果一個應用同一個限流點（LOAD、QPS)設置了多條規則，最小值生效。

Step3：關于線程數、響應時間限流模式與QPS類似，就不再重復介紹。

 

Step4：如果當前系統的負載超過了設定的闊值的處理邏輯，這里就是自適應的核心所在，并不是超過負載就限流，而是需要根據當前系統的請求處理能力進行綜合判斷，具體邏輯在 checkBbr 方法中實現。關于如何獲得系統負載與 checkBbr 方法稍后會詳細介紹。

 

Step5：如果當前CPU的負載超過了設置的闊值，觸發限流，那在JAVA中是如何獲取CPU的使用率的呢？稍后詳細介紹。

2.2 根據系統負載自適應算法詳解

正如上面的第4步驟，根據系統 Load 的會采用 TCP BBR 算法來評估是否限流，具體實現代碼如下：

 

• maxSuccessQps 的計算取當前采樣窗口的最大值乘以1s內滑動窗口的個數，這里其實并不是十分準確。

• minRt 最小響應時間取自當前采樣窗口中的最小響應時間。
  故得出了上述計算公式，除以1000是因為 minRt 的時間單位是毫秒，統一為秒。從這里可以看出根據系統負載做限流，最終的判斷依據是線程數量。

2.3 JAVA如何獲得操作系統負載情況

在 Sentinel 中獲取操作系統負載情況的類：SystemStatusListener，每秒采集一次。

 

3、實踐思考

經過上面的分析，Sentinel 中的系統自適應其實指的是按照應用所在機器的操作系統負載，再結合應用本身的請求處理能力進行的自適應，操作系統的負載情況可以通過 top 命令輸出，其示例如下：