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

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

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

本篇主要內容如下：

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

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

• 什么是熔斷 ？

關鍵字：斷路保護。比如 A 服務調用 B 服務，由于網(wǎng)絡問題或 B 服務宕機了或 B 服務的處理時間長，導致請求的時間超長，如果在一定時間內多次出現(xiàn)這種情況，就可以直接將 B 斷路了（A 不再請求B）。而調用 B 服務的請求直接返回降級數(shù)據(jù)，不必等待 B 服務的執(zhí)行。因此 B 服務的問題，不會級聯(lián)影響到 A 服務。

• 什么是降級 ？

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

• 什么是限流？

  

  對請求的流量進行控制， 只放行部分請求，使服務能夠承擔不超過自己能力的流量壓力。

• 熔斷和降級的相同點？

• 熔斷和限流都是為了保證集群大部分服務的 可用性和 可靠性。 防止核心服務崩潰。
• 給終端用戶的感受就是某個功能不可用。

• 熔斷和降級的不同點？

• 熔斷是被調用方出現(xiàn)了故障， 主動觸發(fā)的操作。
• 降級是基于全局考慮，停止某些正常服務，釋放資源。

• 什么是隔離？

• 每個服務看作一個 獨立運行的系統(tǒng)，即使某一個系統(tǒng)有問題，也不會影響其他服務。

二、Hystrix

Hystrix 是什么

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

Hystrix 的歷史

• 2011 年，其中的 API 團隊為了提升系統(tǒng)的可用性和穩(wěn)定性，發(fā)展出了 Hystrix 框架。

• 2012 年，Hystrix 區(qū)域比較成熟穩(wěn)定。其他團隊也開始使用 Hystrix。

• 2018 年 11 月，Hystrix在其 Github 主頁宣布，不再開放新功能，推薦開發(fā)者使用其他仍然活躍的開源項目。但是 Hystrix 價值依舊很大，功能強大，國內很多一線互聯(lián)網(wǎng)公司在使用。

Hystrix 設計理念

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

Hystrix 線程池隔離技術

使用線程池隔離，比如說有 3 個服務 A、B、C，每個服務的線程池分配 10，20，30個線程，當 A 服務線程池中的 10 個線程都拿出來使用后，如果調用服務 A 的請求量增加，還想再增加線程是不行的，因為 A 服務分配的線程已經(jīng)用完了，不會拿其他的服務的線程，這樣就不會影響其他服務了。Hystrix 默認使用線程池隔離模式。

線程池隔離技術優(yōu)點

• 依賴的服務都有隔離的線程池，即使自己的線程池滿了，也不會影響任何其他其他的服務調用。
• 線程池的健康狀態(tài)會上報，可以近實時修改依賴服務的調用配置。
• 線程池具有異步特性，可以構建一層異步調用層。
• 具有超時檢測的機制，尤其在服務間調用特別有用。

線程池隔離技術缺點

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

Hystrix 信號量隔離技術

如下圖所示：簡單來說就是一個池子里面放著一定數(shù)量的信號量，服務 A 每次調用服務 B 之前，需要從池子里面申請信號量，申請到了，才能去調用 B 服務。

線程池隔離和信號量的場景對比

• 線程池隔離技術 ，適合大部分場景，但需要設置服務的超時時間。
• 信號量隔離技術 ，適合內部比較復雜的業(yè)務，不涉及網(wǎng)絡請求問題。

三、Sentinel

3.1、Sentinel 是什么

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

3.2、Sentinel 的歷史

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

3.3、Sentinel 的特征

• 豐富的應用場景。 支撐阿里的雙十一核心場景，如秒殺、消息削峰填谷、集群流量控制、實時熔斷下游不可用。
• 完備的實時監(jiān)控。 可以看到接入應用的單臺機器秒級數(shù)據(jù)，以及集群的匯總情況。
• 廣泛的開源生態(tài)。 Spring Cloud、Dubbo、gRPC 都可以接入 Sentinel。
• 完善的 SPI 擴展點。 實現(xiàn)擴展接口來快速定制邏輯。

用一張圖來總結：

3.4、Sentinel 的組成

• 核心庫（Java 客戶端）不依賴任何框架/庫，能在所有的 Java 運行時環(huán)境運行，且對 Spring Cloud、Dubbo 等框架有較好的支持。
• 控制臺（Dashboard）基于 Spring Boot 開發(fā)，打包后可以直接運行，不需要額外的 Tomcat 等應用容器。

3.5、Sentinel 的資源

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

可以通過 Sentinel API 定義的代碼，就是資源，能夠被 Sentinel保護起來?？梢匀缦聨追N方式來標識資源：

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

3.6、Sentinel 的設計理念

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

四、對比

4.1、隔離設計上對比

• Hystrix

Hystrix 提供兩種隔離策略，線程池隔離和信號量隔離。

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

而 Hystrix 的信號量隔離，可以對某個資源調用的并發(fā)數(shù)進行限制，輕量級的，不用顯式創(chuàng)建線程池，但缺點是不能對慢調用進行自動降級，只能等客戶端那邊超時，還是有可能出現(xiàn)級聯(lián)阻塞的情形。

• Sentinel

Sentinel 可以通過并發(fā)線程數(shù)模式的流量控制來提供信號量隔離的功能，而且它還具備響應時間的熔斷降級模式，防止過多的慢調用占滿并發(fā)數(shù)而影響整個系統(tǒng)。

4.2、熔斷降級的對比

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

4.3、實時統(tǒng)計的對比

Sentinel 和 Hystrix 都是基于滑動窗口進行實時統(tǒng)計，但 Hystrix 是基于 RxJava 的事件驅動模型，在服務調用成功/失敗/超時的時候發(fā)布響應的事件，通過一系列的變換和聚合最終得到實時的指標統(tǒng)計數(shù)據(jù)流，可以被熔斷器或 Dashboard 消費。而 Sentinel 是基于 LeapArray 的滑動窗口。

五、Sentinel 的突出特性

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

5.1、流量控制

流量控制： 其原理是監(jiān)控應用流量的 QPS 或并發(fā)線程數(shù)等指標，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應用的高可用性。

Sentinel 可以基于QPS/并發(fā)數(shù)進行流量控制，也可以基于調用關系進行流量控制。

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

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

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

基于調用關系的流量控制：

• 根據(jù)調用方限流。
• 根據(jù)調用鏈路入口限流：鏈路限流。
• 根據(jù)具有關系的資源流量限流：關聯(lián)流量限流。

Sentinel 系統(tǒng)自適應限流從整體維度對應用入口流量進行控制，借助 TCP BBR 思想，結合應用的 Load、CPU 使用率、總體平均 RT、入口 QPS 和并發(fā)線程數(shù)等幾個維度的監(jiān)控指標，通過自適應的流控策略，讓系統(tǒng)的入口流量和系統(tǒng)的負載達到一個平衡，讓系統(tǒng)盡可能跑在最大吞吐量的同時保證系統(tǒng)整體的穩(wěn)定性。

我們把系統(tǒng)處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當系統(tǒng)處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的；反之，當請求堆積的時候，那么處理請求的時間則會變?yōu)椋号抨爼r間 + 最短處理時間。

• 推論一: 如果我們能夠保證水管里的水量，能夠讓水順暢的流動，則不會增加排隊的請求；也就是說，這個時候的系統(tǒng)負載不會進一步惡化。

• 推論二:?當保持入口的流量是水管出來的流量的最大的值的時候，可以最大利用水管的處理能力。

5.3、 實時監(jiān)控和控制面板

Sentinel 提供一個輕量級的開源控制臺，它提供機器發(fā)現(xiàn)以及健康情況管理、監(jiān)控（單機和集群），規(guī)則管理和推送的功能。

5.4、 發(fā)展及生態(tài)

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

5.5、 Sentinel 和 Hystrix 對比總結

寫在最后

有讀者問我秒殺系統(tǒng)該怎么設計，在之前的文章中，我已經(jīng)揭秘了秒殺系統(tǒng)的架構設計，下面我還是總結下秒殺系統(tǒng)關注的八大點：

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