限流熔斷技術選型：從Hystrix到Sentinel

子矜，阿里巴巴高可用架構組高級技術專家，參與阿里巴巴多年雙十一大促，對流量的管控、高可用架構有著豐富的經驗，目前負責流量管控軟體Sentinel的開發和維護工作。

宿何，阿里巴巴高可用架構組開發工程師，目前主要負責高可用流控組件Sentinel 開源相關工作。

高可用架構：Hystrix作為大家熟知的容錯組件，最近宣布停止開發，很多人對其背景可能了解不多。作為Spring Cloud官方默認的熔斷組件，您覺得Hystrix是出於哪些原因停止開發呢？

子衿/宿何：這個事情，我也是之前看媒體報道才了解到的。Hystrix是Netflix的一款開源限流組件，官方宣布停止在開源版本上提供新功能，作為開發者，覺得有點可惜，但仍要感謝Netflix之前以及現在正在為開源做的貢獻。

關於Netflix為什麼會宣布停止在開源版本上提供新功能，目前官方並沒有給出原因，只是提供了一些解決方案。但我看到Netflix官方博客的一篇文章，也許能找到技術層面的考量：Netflix 現在正在探索更自動化的熔斷方式。所以我們猜測Netflix內部會逐步不再使用Hystrix ，沒有繼續更新的動力；再加上 Hystrix 作為一個熔斷降級組件已經非常穩定了，因此停止開發是可以理解的。另一個是非技術層面，技術的開源是需要業務的增長和完整的技術團隊來支撐的，無論是國內還是國外，開源項目能否持續，依賴於企業在技術上是否能長期投入。博客原文地址[1]。

高可用架構：Hystrix官方推薦使用Resilience4j，你們是怎麼看這個項目？

子衿/宿何：resilience4j 是一個比較輕量的熔斷降級庫。首先 resilience4j 的模塊化做的比較好，將每個功能點（如熔斷、限速器、自動重試）都拆成了單獨的模塊，這樣整體結構很清晰，用戶也只需要引入相應功能的依賴即可；另外resilience4j 是針對 Java 8 和函數式編程設計的，API 比較簡潔優雅。同時與 Hystrix 相比，Resilience4j 增加了簡單的限速器和自動重試特性，使用場景更加豐富。Resilience4j 屬於一個新興項目，社區也在蓬勃發展。總的來說，Resilience4j 是比較輕量的庫，在較小較新的項目中使用還是比較方便的，但是 Resilience4j 只包含限流降級的基本場景，對於非常複雜的企業級服務架構可能無法很好地 cover 住；同時 Resilience4j 缺乏生產級別的配套設施（如提供規則管理和實時監控能力的控制台）。

高可用架構：Sentinel今年7月份開源，Github上已經有將近4K的Star，目前發布的最新版本是1.3，能否給高可用架構讀者簡單介紹一下Sentinel，比如相比於同類項目的優勢，設計思想，主要模塊以及如何快速接入等。

子衿/宿何：Sentinel 一款面向分散式服務架構的輕量級流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統自適應保護等多個維度來幫助用戶保障服務的穩定性。

Sentinel 的核心思想：根據對應資源配置的規則來為資源執行相應的流控/降級/系統保護策略。在 Sentinel 中資源定義和規則配置是分離的。用戶先通過 Sentinel API 給對應的業務邏輯定義資源，然後可以在需要的時候動態配置規則。

Sentinel 的優勢和特性：

1. 輕量級，核心庫無多餘依賴，性能損耗小。

2. 方便接入，開源生態廣泛。Sentinel 對 Dubbo、Spring Cloud、Web Servlet、gRPC 等常用框架提供適配模塊，只需引入相應依賴並簡單配置即可快速接入；同時針對自定義的場景 Sentinel 還提供低侵入性的註解資源定義方式，方便自定義接入。

3. 豐富的流量控制場景。Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，流控維度包括流控指標、流控效果（塑形）、調用關係、熱點、集群等各種維度，針對系統維度也提供自適應的保護機制。

4. 易用的控制台，提供實時監控、機器發現、規則管理等能力。

5. 完善的擴展性設計，提供多樣化的 SPI 介面，方便用戶根據需求給 Sentinel 添加自定義的邏輯。

Sentinel 與 Hystrix、resilience4j 的對比：（這個對比已經展示在Sentinel的Wiki頁面[2]，任何疑問，歡迎發起issue一起討論）

高可用架構：作為流控的重要一環，能否簡單介紹一下Sentinel內部是如何實現熔斷的？能否給個簡單的熔斷器使用實例？

子衿/宿何：Sentinel 內部熔斷的實現其實就是熔斷器的思想。Sentinel 底層會通過優化的滑動窗口數據結構來實時統計所有資源的調用數據（通過 QPS、限流 QPS、異常數、RT 等）。若資源配置了熔斷降級規則，那麼調用時就會取出當前時刻的統計數據進行判斷。當達到熔斷閾值時會將熔斷器置為開啟狀態，切斷所有的請求，直到過了降級時間窗口後再重置熔斷器，繼續允許請求通過。

Sentinel 熔斷降級支持以下幾種指標：平均響應時間、秒級異常比率、分鐘級異常數。在 Sentinel 中，我們一般將熔斷降級與並發線程數限流相結合來對不穩定的服務調用進行熔斷，防止出現級聯錯誤。

由於Sentinel 的資源定義和規則配置是相分離的，因此只需要對資源配置熔斷降級規則即可。比如我們定義了如下資源：

那麼只需要配置如下規則：

如果接入了Sentinel 控制台，那麼可以直接在 Sentinel 控制台上進行配置，更加方便：

高可用架構：限流相對比較麻煩，尤其是彈性伸縮的架構中，首先得知道系統的承載量，其次，如果橫向伸縮了伺服器，原有的限流策略未必適用。Sentinel的限流是怎麼做的？有沒有可能無需配置，自動感知，動態限流？Sentinel支持自定義限流策略，能否給個簡單的使用實例？

子衿/宿何：一般來說，我們需要通過全鏈路壓測來了解系統的容量，從而可以為限流規則的配置提供參考。Sentinel 支持多個維度的流量控制策略，可以覆蓋不同的流量場景：

• 根據不同指標：QPS, 並發線程數等

• 根據調用關係：按調用來源限流、按調用鏈路限流、關聯限流等

• 流量塑形控制效果：直接拒絕、冷啟動模式、勻速器模式、預熱排隊模式等

• 不同的資源維度：服務介面、服務方法、熱點參數、自定義資源

• 集群維度的分散式流量控制（即將發布）

流量具有實時性和不確定性，很難準確地進行預測。如何根據實時流量和系統指標來自適應地限流一直是Sentinel 在不斷研究的方向。Sentinel 從 2016 年開始就在不斷的探索智能化、自適應限流的可能性，目前開放出來的演算法有基於 TCP BBR 的系統保護演算法。系統自適應保護可以結合 load 等實時指標，自動探測當前系統水位是否超過系統的最大容量，只有在超出系統處理能力的時候才會發生限流。未來 Sentinel 還會推出更加智能化的自適應限流策略。

限流的使用同上面的降級一樣簡單，只需配置限流規則即可。以下是一個簡單的示例，限制資源每秒的調用QPS 為 20：

高可用架構：Sentinel有基於Spring Boot實現的監控系統，支持哪些metric呢？監控數據是Sentinel主動上報嗎？採樣率是多少？上報時間間隔是多少？metric數據如何存儲？時序資料庫嗎？能否把監控數據快速集成到現有的監控系統上，比如Zabbix或者Prometheus等等？是否支持自定義metric？能否給個簡單的例子？

子衿/宿何：Sentinel 目前的監控支持 QPS、響應時間、限流數、異常數等幾種指標。Sentinel 客戶端每秒會把秒級的監控數據存儲至本地日誌，Sentinel 控制台進行拉取和聚合。在生產環境中，由於秒級監控數據的量非常大，我們一般將 metric 數據存儲於列資料庫或時序資料庫中，並通過一些策略進行優化來保證監控存儲和聚合的性能。

Sentinel 正在進行指標與監控標準化的相關工作，在完成標準化，抽出通用的 metric 介面後，即可快速對接 Zabbix 和 Prometheus 等監控系統，同時用戶也可以方便地對接其它監控系統。

高可用架構：除了上面提到的功能外，Sentinel還有哪些有意思的特性值得讀者了解？

子衿/宿何：Sentinel 的 專業流量控制[3] 相關的特性都值得大家關注，包括流量塑形[3]、系統自適應保護[4]、調用鏈路統計[5]、熱點限流[6]。關於這些特性，我們也給出了鏈接，大家感興趣的話去可以去對應的頁面了解。

高可用架構：Sentinel目前有哪些案例，他們使用場景及效果能否簡單介紹一下？

子衿/宿何：Sentinel源於阿里巴巴自身的生產實踐，適用場景非常豐富，包括：

• 雙十一零點持續峰值：限流、慢調用降級

• 秒殺（脈衝流量）：限流、慢調用降級

• 消息隊列削峰填谷：MQ 消費端可能會出現大批量的消息同時到達，若瞬時請求所有消息會導致系統負載過高。我們利用勻速器模式將消息突刺均攤到一段時間內，讓系統負載保持在處理能力水位的同時儘可能地處理更多消息，從而起到「削峰填谷」的效果。

• 冷啟動：當流量突然增大的時候，我們希望系統從空閑狀態到繁忙狀態的切換的時間長一些，即如果系統在此之前長期處於空閑的狀態，我們希望處理請求的速率緩慢增加，經過預期的時間以後，到達系統處理請求速率的設定值；

• 熱點商品自動探測、防護：自動統計訪問頻次最高的熱點參數並進行流量控制；

• 集群流量不均勻：通過集群限流來解決集群各個機器的流量不均導致整體限流效果不精確的問題；

我們在10月30日上線了GA版本，目前已有不少企業用戶在使用開源版本和雲上版本的Sentinel，包括順豐、vivo、每日優鮮、拼多多、易企秀等，我們也在社區發起了「who is using Sentinel」[7]的issue，可以去這個頁面了解各家企業的使用場景。

高可用架構：Sentinel作為Spring Cloud Alibaba重要的開源組件，前後大概投入了多少人力成本呢？是否有專門的團隊進行長期維護？未來有什麼樣的規劃？

子衿/宿何：Sentinel 之所以能開源，並且提供穩定的限流降級功能，是因為站在了巨人的肩膀上，離不開阿里歷屆高可用架構團隊的共同努力。2014年，高可用架構團隊因實現了全鏈路壓測，獲得了當年的集團CTO大獎。

2014年獲獎照片

Sentinel在開源過程中，對原有代碼進行大量的重構、規範化，對模塊結構進行了優化，增強了擴展性。目前，我們有專門的開源團隊，對開源項目進行長期的維護和演進。

近期，Sentinel 推出了集群限流版本 1.4.0，提供了獨有的靈活、高性能的集群限流模塊。集群限流主要針對需要限制整個集群流量總量，但是由於單機流量不均勻而無法精確地限制總體流量的問題。用戶可以利用 Sentinel 集群限流模塊，結合自動化的管控策略來保障集群流量的穩定。自適應動態限流也是保障穩定性的重要一環。Sentinel 目前提供了基於 BBR 演算法的系統自適應保護策略。

未來Sentinel 會繼續在無規則容量保護的路上探索，提供更多自適應限流策略，更好地結合系統容量來進行流量控制。另外，Sentinel 也會支持更廣泛的開源生態，適配 RxJava、Spring WebFlux 等 reactive 的組件；同時會抽出標準的指標和監控介面，方便對接 Prometheus 等常用的監控系統。最後，Sentinel 也會朝著 Cloud Native 的方向演進，引入多語言集群限流客戶端支持，同時提供對 Service Mesh 的支持。

文中鏈接：

[1] https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581

[2] https://github.com/alibaba/Sentinel/wiki/Guideline:-從-Hystrix-遷移到-Sentinel

[3] https://github.com/alibaba/Sentinel/wiki/流量控制

[4] https://github.com/alibaba/Sentinel/wiki/系統自適應限流

[5] https://github.com/alibaba/Sentinel/wiki/Sentinel工作主流程

[6] https://github.com/alibaba/Sentinel/wiki/熱點參數限流

[7] https://github.com/alibaba/Sentinel/issues/18

參考閱讀：

技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。轉載請註明來自高可用架構「ArchNotes」微信公眾號及包含以下二維碼。

高可用架構

改變互聯網的構建方式

長按二維碼 關注「高可用架構」公眾號

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！