限流熔斷技術選型：從Hystrix到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