雙 11 的狂歡，幹了這份「流量防控」

阿新 • • 發佈：2020-11-04

臨近雙十一，從 2009 年第一屆雙十一開始，成交量只有 5000 萬，到去年 2019 年，成交量達到了 2684 億。今年迎來了第十二屆雙十一，想想都挺激動。

阿里人喜歡將雙十一視為 Team Building（團隊建設），廣為流傳的一句話：打仗是最好的團建，沒有參加過雙十一的叫同事，參加過雙十一的叫戰友。

上一篇我通過三國故事講解了服務雪崩和熔斷的機制，而且自己造了一個輪子：熔斷器。而這一篇會講解被一線大廠使用的兩款流量防控元件：Sentinel 和 Hystrix，以及對它們的橫向對比。

本篇主要內容如下：

本文已收錄到我的 Github:
https://github.com/Jackson0714/PassJava-Learning

點我 Github 連結

一、熔斷&降級&限流&隔離

面對高併發的流量，我們通常會使用四種方式（熔斷&降級&限流&隔離）來防止瞬時大流量對系統的衝擊。而今天要介紹的這兩款流量防衛兵，是專門用在這方面的。下面我先給同學掃個小盲。

什麼是熔斷？

關鍵字：斷路保護。比如 A 服務呼叫 B 服務，由於網路問題或 B 服務宕機了或 B 服務的處理時間長，導致請求的時間超長，如果在一定時間內多次出現這種情況，就可以直接將 B 斷路了（A 不再請求B）。而呼叫 B 服務的請求直接返回降級資料，不必等待 B 服務的執行。因此 B 服務的問題，不會級聯影響到 A 服務。

什麼是降級？

關鍵字：返回降級資料。網站處於流量高峰期，伺服器壓力劇增，根據當前業務情況及流量，對一些服務和頁面進行有策略的降級（停止服務，所有的呼叫直接返回降級資料）。以此緩解伺服器資源的壓力，保證核心業務的正常執行，保持了客戶和大部分客戶得到正確的響應。降級資料可以簡單理解為快速返回了一個 false，前端頁面告訴使用者“伺服器當前正忙，請稍後再試。”

什麼是限流？

對請求的流量進行控制，只放行部分請求，使服務能夠承擔不超過自己能力的流量壓力。
熔斷和降級的相同點？
- 熔斷和限流都是為了保證叢集大部分服務的可用性和可靠性。防止核心服務崩潰。
- 給終端使用者的感受就是某個功能不可用。
熔斷和降級的不同點？
- 熔斷是被呼叫放出現了故障，主動觸發的操作。
- 降級是基於全域性考慮，停止某些正常服務，釋放資源。
什麼是隔離？
- 每個服務看作一個獨立執行的系統，即使某一個系統有問題，也不會影響其他服務。

二、Hystrix

Hystrix 是什麼

Hystrix：高可用性保障的一個框架。由 Netflix 出品（Netflix可以理解為國內的愛奇藝等視訊網站）。

Hystrix 的歷史

2011 年，其中的 API 團隊為了提升系統的可用性和穩定性，發展出了 Hystrix 框架。
2012 年，Hystrix 區域比較成熟穩定。其他團隊也開始使用 Hystrix。
2018 年 11 月，Hystrix在其 Github 主頁宣佈，不再開放新功能，推薦開發者使用其他仍然活躍的開源專案。但是 Hystrix 價值依舊很大，功能強大，國內很多一線網際網路公司在使用。

Hystrix 設計理念

阻止服務的雪崩效應。
快速失敗和快速恢復。
優雅降級。
使用資源隔離技術，如 bulkhead（艙壁隔離技術）、swimlane（泳道技術）、circuit breaker（斷路技術）。
近實時的監控、報警及運維操作。

Hystrix 執行緒池隔離技術

使用執行緒池隔離，比如說有 3 個服務 A、B、C，每個服務的執行緒池分配 10，20，30個執行緒，當 A 服務執行緒池中的 10 個執行緒都拿出來使用後，如果呼叫服務 A 的請求量增加，還想再增加執行緒是不行的，因為 A 服務分配的執行緒已經用完了，不會拿其他的服務的執行緒，這樣就不會影響其他服務了。Hystrix 預設使用執行緒池隔離模式。

執行緒池隔離技術優點

依賴的服務都有隔離的執行緒池，即使自己的此案成池滿了，也不會影響任何其他其他的服務呼叫。
執行緒池的健康狀態會上報，可以近實時修改依賴服務的呼叫配置。
執行緒池具有非同步特性，可以構建一層非同步呼叫層。
具有超時檢測的機制，尤其在服務間呼叫特別有用。

執行緒池隔離技術缺點

執行緒池本身就會帶來一些問題，比如執行緒切換，執行緒管理，無疑增加了 CPU 的開銷。
如果執行緒池中的執行緒利用率很低，則無疑是一種浪費。

Hystrix 訊號量隔離技術

如下圖所示：簡單來說就是一個池子裡面放著一定數量的訊號量，服務 A 每次呼叫服務 B 之前，需要從池子裡面申請訊號量，申請到了，才能去呼叫 B 服務。

執行緒池隔離和訊號量的場景對比

執行緒池隔離技術 ，適合大部分場景，但需要設定服務的超時時間。
訊號量隔離技術 ，適合內部比較複雜的業務，不涉及網路請求問題。

三、Sentinel

3.1、Sentinel 是什麼

Sentinel：面向分散式服務架構的流量控制組件，主要以流量為切入點，從限流、流量整形、熔斷降級、系統負載保護、熱點防護等多個維度來幫助開發者保障微服務的穩定性。

3.2、Sentinel 的歷史

2012 年，Sentinel 誕生，主要功能為入口流量控制。
2013-2017 年，Sentinel 在阿里巴巴集團內部迅速發展，成為基礎技術模組，覆蓋了所有的核心場景。Sentinel 也因此積累了大量的流量歸整場景以及生產實踐。
2018 年，Sentinel 開源，並持續演進。
2019 年，Sentinel 朝著多語言擴充套件的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh 場景也推出了 Envoy 叢集流量控制支援，以解決 Service Mesh 架構下多語言限流的問題。
2020 年，推出 Sentinel Go 版本，繼續朝著雲原生方向演進。

3.3、Sentinel 的特徵

豐富的應用場景。 支撐阿里的雙十一核心場景，如秒殺、訊息削峰填谷、叢集流量控制、實時熔斷下游不可用。
完備的實時監控。 可以看到接入應用的單臺機器秒級資料，以及叢集的彙總情況。
廣泛的開源生態。 Spring Cloud、Dubbo、gRPC 都可以接入 Sentinel。
完善的 SPI 擴充套件點。 實現擴充套件介面來快速定製邏輯。

用一張圖來總結：

3.4、Sentinel 的組成

核心庫（Java 客戶端）不依賴任何框架/庫，能在所有的 Java 執行時環境執行，且對 Spring Cloud、Dubbo 等框架有較好的支援。
控制檯（Dashboard）基於 Spring Boot 開發，打包後可以直接執行，不需要額外的 Tomcat 等應用容器。

3.5、Sentinel 的資源

Sentinel 中的資源是核心概念，可以是 Java 應用程式中的任何內容，可以是提供的服務，甚至是一段程式碼。

可以通過 Sentinel API 定義的程式碼，就是資源，能夠被 Sentinel保護起來。可以如下幾種方式來標識資源：

方法簽名。
URL。
服務名稱等。

3.6、Sentinel 的設計理念

Sentinel 作為一個流量控制器，可以根據需要把隨機的請求調整成合適的形狀，如下圖所示：

四、對比

4.1、隔離設計上對比

Hystrix

Hystrix 提供兩種隔離策略，執行緒池隔離和訊號量隔離。

Hystrix 中最推薦的也是最常用的是執行緒池隔離。執行緒池隔離的好處是隔離度很高，不會影響其他資源，但是執行緒本身也有自己的問題，執行緒上下文切換時比較耗 CPU 資源的，如果對低延時要求比較高，影響還是挺大的，而且建立執行緒是需要分配記憶體的，建立的執行緒越多，需要分配的記憶體也會更多。而且如果對每個資源都建立一個執行緒池，那執行緒切換會帶來更大的損耗。

而 Hystrix 的訊號量隔離，可以對某個資源呼叫的併發數進行限制，輕量級的，不用顯式建立執行緒池，但缺點是不能對慢呼叫進行自動降級，只能等客戶端那邊超時，還是有可能出現級聯阻塞的情形。

Sentinel

Sentinel 可以通過併發執行緒數模式的流量控制來提供訊號量隔離的功能，而且它還具備響應時間的熔斷降級模式，防止過多的慢呼叫佔滿併發數而影響整個系統。

4.2、熔斷降級的對比

Sentinel 和 Hystrix 都是基於熔斷器模式。都支援基於異常比率來進行熔斷，但 Sentinel 更強大，可以基於響應時間、異常比率和異常數來進行熔斷降級。

4.3、實時統計的對比

Sentinel 和 Hystrix 都是基於滑動視窗進行實時統計，但 Hystrix 是基於 RxJava 的事件驅動模型，在服務呼叫成功/失敗/超時的時候釋出響應的事件，通過一系列的變換和聚合最終得到實時的指標統計資料流，可以被熔斷器或 Dashboard 消費。而 Sentinel 是基於 LeapArray 的滑動視窗。

五、Sentinel 的突出特性

除了上面提到的三大對比外，Sentinel 還有一些 Hystrix 不具備的功能。

5.1、流量控制

流量控制： 其原理是監控應用流量的 QPS 或併發執行緒數等指標，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應用的高可用性。

Sentinel 可以基於QPS/併發數進行流量控制，也可以基於呼叫關係進行流量控制。

基於 QPS 進行流量控制有以下幾種方式：

直接拒絕： 當QPS 超過一定閾值時，直接拒絕。適用於對系統處理能力確切已知的情況。
慢啟動預熱： 當系統長期處於低水位的情況下，當流量突然增加時，直接把系統拉昇到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

勻速排隊： 請求以均勻的速度通過，對應的是漏桶演算法。

基於呼叫關係的流量控制：

根據呼叫方限流。
根據呼叫鏈路入口限流：鏈路限流。
根據具有關係的資源流量限流：關聯流量限流。

5.2、系統自適應限流

Sentinel 系統自適應限流從整體維度對應用入口流量進行控制，藉助 TCP BBR 思想，結合應用的 Load、CPU 使用率、總體平均 RT、入口 QPS 和併發執行緒數等幾個維度的監控指標，通過自適應的流控策略，讓系統的入口流量和系統的負載達到一個平衡，讓系統儘可能跑在最大吞吐量的同時保證系統整體的穩定性。

我們把系統處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當系統處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的；反之，當請求堆積的時候，那麼處理請求的時間則會變為：排隊時間 + 最短處理時間。

推論一: 如果我們能夠保證水管裡的水量，能夠讓水順暢的流動，則不會增加排隊的請求；也就是說，這個時候的系統負載不會進一步惡化。
推論二:　當保持入口的流量是水管出來的流量的最大的值的時候，可以最大利用水管的處理能力。

5.3、實時監控和控制面板

Sentinel 提供一個輕量級的開源控制檯，它提供機器發現以及健康情況管理、監控（單機和叢集），規則管理和推送的功能。

5.4、發展及生態

Sentinel 針對 Spring Cloud、Dubbo、gRPC 都進行了適配，引入依賴和簡單的配置即可快速接入 Sentinel，相信 Sentinel 將是未來流量防控的一大利器。我比較看好 Sentinel。

5.5、 Sentinel 和 Hystrix 對比總結

寫在最後

有讀者問我秒殺系統該怎麼設計，在之前的文章中，我已經揭祕了秒殺系統的架構設計，下面我還是總結下秒殺系統的關注的八大點：

服務單一職責、獨立部署
庫存預熱、快速扣減
秒殺連結加密
動靜分離
惡意請求攔截
流量錯峰
限流&熔斷&降級
佇列削峰

我是悟空，努力變強成為超級賽亞人。

我們下期見！