优势官网上已经说了很多，本篇主要想分析下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