Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景

本文介紹阿里開源限流熔斷方案Sentinel功能、原理、架構、快速入門以及相關框架比較

基本介紹

1 名詞解釋

• 服務限流 ：當系統資源不夠，不足以應對大量請求，對系統按照預設的規則進行流量限制或功能限制

• 服務熔斷：當呼叫目標服務的請求和呼叫大量超時或失敗，服務呼叫方為避免造成長時間的阻塞造成影響其他服務，後續對該服務介面的呼叫不再經過進行請求，直接執行本地的預設方法

• 服務降級：為了保證核心業務在大量請求下能正常執行，根據實際業務情況及流量，對部分服務降低優先順序，有策略的不處理或用簡單的方式處理

服務降級的實現可以基於人工開關降級（秒殺、電商大促等）和自動檢測（超時、失敗次數、故障），熔斷可以理解為一種服務故障降級處理

2 為什麼需要限流降級

系統承載的訪問量是有限的，如果不做流量控制，會導致系統資源佔滿，服務超時，從而所有使用者無法使用，通過服務限流控制請求的量，服務降級省掉非核心業務對系統資源的佔用，最大化利用系統資源，儘可能服務更多使用者

3 Sentinel簡介

Sentinel: 分散式系統的流量防衛兵，是阿里中介軟體團隊2018年7月開源的，面向分散式服務架構的輕量級流量控制產品，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來保護系統服務的穩定性

Sentinel 的開源生態：

功能特性

1 總體介紹

Sentinel 具有以下特徵:

豐富的應用場景：秒殺限流，訊息削峰填谷、叢集流量控制、實時熔斷下游不可用應用等

完備的實時監控：Sentinel 同時提供實時的監控功能。可以在控制檯中看到接入應用的單臺機器秒級資料，甚至 500 臺以下規模的叢集的彙總執行情況

廣泛的開源生態：Sentinel 提供開箱即用的與其它開源框架/庫的整合模組，例如與 Spring Cloud、Dubbo、gRPC 的整合。只需要引入相應的依賴並進行簡單的配置即可快速地接入 Sentinel

完善的 SPI 擴充套件點：Sentinel 提供簡單易用、完善的 SPI 擴充套件介面。可以通過實現擴充套件介面來快速地定製邏輯。例如定製規則管理、適配動態資料來源等

Sentinel 分為兩個部分:

控制檯（Dashboard） 基於 Spring Boot 開發，打包後可以直接執行，不需要額外的 Tomcat 等應用容器

核心庫（Java 客戶端） 不依賴任何框架/庫，能夠執行於所有 Java 執行時環境，同時對 Dubbo / Spring Cloud 等框架也有較好的支援

2 控制檯特性

• 實時監控 支援自動發現叢集機器列表、服務健康狀態、服務呼叫通過/拒絕QPS、呼叫耗時、圖表統計

• 規則管理及推送 支援在介面配置流控、降級、熱點規則，並實時推送

• 鑑權 控制檯支援自定義鑑權介面，提供基本登入功能

3 核心庫功能特性

(1) 應用流控

針對指定應用例項的流量控制，監控應用流量QPS或併發執行緒數，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應用的高可用性

流量控制的手段包括：

• 直接拒絕
• Warm Up，即預熱/冷啟動方式，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被瞬間壓垮
• 勻速排隊，嚴格控制請求通過的間隔時間，讓請求以均勻的速度通過

(2) 叢集流控

不同於應用流控根據單個應用例項閾值執行限流檢查，叢集流控只對整個叢集呼叫總量進行限流，例如以下場景：

• 限制某個使用者呼叫某個API的總QPS，提供API的應用在多個機器上部署了多個例項
• 因為多個應用例項流量不均勻，導致叢集呼叫總量沒有到的情況下某些機器就開始限流

僅靠單機維度去限制的話會無法精確地限制總體流量，通過叢集精確地控制整個叢集的呼叫總量，結合單機限流兜底，可以更好地發揮流量控制的效果

(3) 閘道器流控

Sentinel 支援對 Spring Cloud Gateway、Zuul 等主流的 API Gateway 進行限流

閘道器流控針對 API閘道器的場景定製的限流規則，可以針對不同 route 或自定義的 API 分組進行限流，支援針對請求中的路徑、引數、Header、來源 IP 等進行定製化的限流

(4) 熔斷降級

如果呼叫鏈路中的某個資源不穩定，最終會導致請求發生堆積，通過熔斷降級能在呼叫鏈路中某個資源出現不穩定狀態時（包括呼叫超時、異常比例升高、異常數升高），對這個資源的呼叫進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯錯誤

當資源被降級後，在接下來的降級時間視窗之內，對該資源的呼叫都自動熔斷（預設行為是丟擲 DegradeException），經過時間視窗之後，退出熔斷，並在下一次資源出現不穩定狀態再次自動熔斷

(5)

引數限流 熱點即經常訪問的資料，熱點引數限流會統計傳入引數中的熱點引數，並根據配置的限流閾值與模式，對包含熱點引數的資源呼叫進行限流 例如以下場景：

• 使用者ID為引數，限制使用者對介面的範圍QPS
• 商品ID為引數，限制商品下單介面頻率

(6) 系統自適應限流

為瞭解決傳統方案：基於作業系統負載(load1，linux下用uptime檢視)做進行自適應限流，帶來的存在延時、系統效能恢復慢的問題，Sentinel採用新的思路：根據系統能夠處理的請求，和允許進來的請求，來做平衡，而不是根據一個間接的指標（系統 load）來做限流

目標在於：在系統不被拖垮的情況下，儘可能提高系統的吞吐率，而不是 負載 一定要到低於某個閾值

系統保護規則是從應用級別的入口流量進行控制，從單臺機器的總體 Load、RT、入口 QPS 和執行緒數四個維度監控應用資料，當實際執行達到限定閾值進行限流保護，支援的閾值型別：

• Load：當系統 load1 超過閾值，且系統當前的併發執行緒數超過系統容量時才會觸發系統保護。系統容量由系統時間執行監測到的的 maxQps * minRt (最小響應時間)計算得出
• RT：當單臺機器上所有入口流量的平均 RT(響應時間)
• 執行緒數：當單臺機器上所有入口流量的併發執行緒數
• 入口 QPS：當單臺機器上所有入口流量的 QPS

(7) 黑白名單控制

Sentinel黑白名單根據資源的請求來源（origin）限制資源是否通過，若配置白名單則只有請求來源位於白名單內時才可通過；若配置黑名單則請求來源位於黑名單時不通過，其餘的請求通過

快速入門

1 安裝控制檯

從github release頁面(github.com/alibaba/Sen…)下載最新控制檯jar包

命令列啟動控制檯：

java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar
複製程式碼

2 應用接入Sentinel

Sentinel適配了常見主流框架，包括Dubbo、Spring Boot、Spring WebFlux、gRPC、Zuul、Spring Cloud Gateway、RocketMQ、Web Servlet，對於需要限流的資源，支援用原生Java的try-catch 接入或者使用註解

下面以常見的Spring Boot註解的方式作為示例： 引入sentinel適配Spring Cloud的依賴：

<dependency>
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
	<version>2.1.0.RELEASE</version>
</dependency>
複製程式碼

application.yml指定控制檯地址：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: IP:埠號
複製程式碼

定義需要限流的資源：

@RestController
public class TestController {

    @GetMapping(value = "/hello")
    // 定義需要限流的資源名稱為hello
    @SentinelResource("hello")
    public String hello() {
        return "Hello Sentinel";
    }
}
複製程式碼

請求一次上面的http hello介面後，觸發Sentinel客戶端初始化，才能在控制檯看到介面

新增流控規則：

頻繁請求介面，可以看到部分請求被拒絕：

注意：上面的配置方式是沒有做持久化的，生產環境不建議使用

3 規則配置

Sentinel 提供 動態規則資料來源 支援來動態地管理、讀取配置的規則。Sentinel 提供的 ReadableDataSource 和 WritableDataSource 介面簡單易用，非常方便使用。

Sentinel 動態規則源針對常見的配置中心和遠端儲存進行適配，目前已支援 Nacos、ZooKeeper、Apollo、Redis 等多種動態規則源，可以覆蓋到很多的生產場景

實現原理

下面介紹Sentinel客戶端基本原理

1 基本概念

• Resource 資源 Sentinel中，需要被流量保護的方法、程式碼塊都可以稱為資源，每個資源都需要定義一個唯一的資源名詞，用於匹配相關規則

• Entry Sentinel功能入口類，Entry 可以通過對主流框架的適配自動建立，也可以通過註解的方式或呼叫 SphU API 顯式建立，建立後執行資源和規則匹配和校驗

• Slot 功能插槽，由Enty類建立，每個資源對應一系列Slot，Slot實現資源資訊收集、規則匹配、校驗的，多個Slot通過組成Slot Chain，在進入資源和退出資源時分別基於責任鏈模式呼叫entry()和exit()方法

2 工作原理

String resourceName = "resourceName";
Entry entry = null;
try {
	entry = SphU.entry(resourceName);
	System.out.println("resource running");
} catch (BlockException e) {
	// 限流
	throw e;
} catch (Throwable e) {
	e.printStackTrace();
	throw e;
} finally {
	if (entry != null) {
		entry.exit();
	}
}
複製程式碼

主要流程如下：

• 進入資源方法之前，基於SphU建立Entry，Entry獲取查詢資源關聯的Slot Chain資訊，如果找不到則建立，並基於責任鏈模式呼叫Slot的entry()方法
• 資源方法呼叫
• 資源方法呼叫完成後，通過Entry觸發Slot的exit()邏輯

框架比較

值得補充的是：相比Hystrix基於執行緒池隔離進行限流，這種方案雖然隔離性比較好，但是代價就是執行緒數目太多，執行緒上下文切換的 overhead 比較大，特別是對低延時的呼叫有比較大的影響。

Sentinel 併發執行緒數限流不負責建立和管理執行緒池，而是簡單統計當前請求上下文的執行緒數目，如果超出閾值，新的請求會被立即拒絕，效果類似於訊號量隔離

參考

《Sentinel官方檔案》

github.com/alibaba/Sen…

《從 Hystrix 遷移到 Sentinel》

github.com/alibaba/Sen…