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

原文出处：https://www.cnblogs.com/springsource/p/10186638.html