阿里流控中间件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