流量防控該如何選型？

臨近雙十一，從 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 對比總結

寫在最後

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

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

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

我們下期見！