阿里流控中介軟體sentinel的思考，主要分析下hytrix的優勢
優勢官網上已經說了很多，本篇主要想分析下hytrix的一些優勢
先說sentinel, 簡單說下，個人感覺比較有用的功能
sentinel的優勢：
- 友好的控制面板，支援實時監控
- 多種限流。支援QPS限流，執行緒數限流，多種限流策略，如：直接拒絕，勻速模式（漏斗），冷啟動（如設定限制1000，延遲10秒，那第一秒pass100, 第二秒200，遞增，適應於快取保護）
- 多種降級模式，支援按平均返回時間降級，按多種異常數降級，按異常比率降級
- 方便擴充套件開發，支援SPI模式對chain進行擴充套件
- 支援鏈路的關聯，按鏈路統計限流，系統保護，熱門資源保護等等
如果遠見點，看到阿里後面也開始弄全家桶了
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