阿里流控中間件sentinel的思考，主要分析下hytrix的優點

優點官網上已經說了不少，本篇主要想分析下hytrix的一些優點

 

先說sentinel, 簡單說下，我的感受比較有用的功能

sentinel的優點：

1. 友好的控制面板，支持實時監控
2. 多種限流。支持QPS限流，線程數限流，多種限流策略，如：直接拒絕，勻速模式（漏斗），冷啓動（如設置限制1000，延遲10秒，那第一秒pass100, 第二秒200，遞增，適應於緩存保護）
3. 多種降級模式，支持按平均返回時間降級，按多種異常數降級，按異常比率降級
4. 方便擴展開發，支持SPI模式對chain進行擴展
5. 支持鏈路的關聯，按鏈路統計限流，系統保護，熱門資源保護等等

若是遠見點，看到阿里後面也開始弄全家桶了  

https://github.com/spring-cloud-incubator/spring-cloud-alibaba 

也是能夠持續集成的

固然最終的是hytrix也已經中止維護了。 

 

hytrix的優點

• hytrix支持異步調用，支持線程池級別的隔離

這種方式就是經過rxJava進行調用，等待完成後進行異步通知調用，但在http這種請求中，主線程仍是阻塞在等待中。帶來的收益，無非就是hytrix能對超時進行控制。

但壞處也很明顯，若是是每一個接口建立一個線程池的話，若是接口過多，機器中會建立大量線程，而在java中，線程是屬於輕量級的進程，對應是內核線程，進而形成線程的切換。成本仍是挺高。

再者每一個線程也得須要-Xxs的大小，若是線程數目過多也是一筆不小的花銷。

 

• hytrix支持百分比+連續錯誤比率的條件進行降級

這部分，確實比sentinel單純的統計異常率，或異常數更精細，得看業務去取捨。

 

sentinel的侷限性：

1, CircuitBreakerRequestVolumeThreshold參數在sentinel裏是被關閉了，代碼里加了個默認值是5， 也就是說1s請求超過5次請求就會統計。不然不會

2，sentinel全部的統計都是基於QPS的，也就是1s位單位，包括統計異常率，只適合大併發請求的場景.  而hytrix這個時間窗口是能夠配置的 (metrics.rollingStats.timeInMilliseconds,metrics.rollingStats.numBuckets)

sentinel熔斷的判斷方式：

 

3， 被熔斷後，sentinel沒作半打開的狀態，放1個流量去試探，而是打開一秒時間從新統計5個

來自hytrix官網，也測試過

After some amount of time (HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()), the next single request is let through (this is the HALF-OPEN state). If the request fails, the circuit-breaker returns to the OPEN state for the duration of the sleep window. If the request succeeds, the circuit-breaker transitions to CLOSED and the logic in 1. takes over again.

但sentinel因爲只是進去5個，並非要等返回，故雖然不是放入1個，最多也是放入5個請求就是

 

4，sentinel種所謂融合了dubbo，spring boot/spring cloud，其實只是爲每一個項目作了個適配器，好比  dubbo 只是擴展了dubbo的filter， spring boot只是添加了spring mvc的過濾器代碼添加資源

 

 

總結： 正如阿里本身比較的，sentinel側重於流控， 而熔斷的話hytrix更靈活和專業的，雖然中止開發了。

但通常狀況下用sentinel代替hytrix也是足夠的了的。 看場景了。 

目前選擇了sentinel

 

本想發公司wiki，想一想和工做關係沒那麼大，更可能是研究對比，仍是發博客這

 

附上阿里本身的對比文檔：

https://yq.aliyun.com/articles/623424

 

公衆號：

何錦彬 2018.11.21