从线程模型上看sentinel使用的是tomcat/jetty/other本身的线程池。hystrix使用的是自己创建的线程池
Items | Sentinel | Hystrix | remark |
---|---|---|---|
隔离策略 | 信号量隔离(并发线程数限流)(模拟信号量) | 线程池隔离/信号量隔离 | Sentinel不创建线程依赖tomcat或jetty容器的线程池,存在的问题就是运行容器的线程数量限制了sentinel设置值的上限可能设置不准。 比如tomcat线程池为10,sentinel设置100是没有意义的,同时隔离性不好 hystrix使用自己创建的线程池,隔离性会更好 |
熔断降级策略 | 基于响应时间、异常比率、异常数 | 基于异常比率 | 快速失败的本质功能 |
实时统计实现 | 滑动窗口(LeapArray) | 滑动窗口(基于 RxJava) | |
动态规则配置 | 支持多种数据源 | 支持多种数据源 | |
扩展性 | 多个扩展点 | 插件的形式 | |
基于注解的支持 | 支持 | 支持 | |
限流 | 基于 QPS,支持基于调用关系的限流 | 有限的支持(并发线程数或信号量大小) | 快速失败的本质功能 |
流量整形 | 支持预热模式、匀速器模式、预热排队模式 | 不支持(排队) | 支持排队好吧 |
系统自适应保护 | 支持(仅对linux生效) | 不支持 | 所谓的自适应就是设置一个服务器最大允许处理量的阈值。(有比没有强,但是要知道最大负载量是多少。) |
控制台 | 提供开箱即用的控制台,可配置规则、查看秒级监控、机器发现等 |
简单的监控查看接近实时数据 |
控制台是非常有竞争力的功能,因为能集中配置限制数据更方便,但是展示数据和实时性没有hystrix直观。 |
配置持久化 | ZooKeeper, Apollo, Nacos |
Git/svn/本地文件 | Sentinel客户端采用直接链接持久化存储,应用客户端引用了更多的依赖,同样的存储链接可能有多个配置 |
动态配置 | 支持 | 支持 | hystrix可能需要手动触发,sentinel增加了额外的端口进行配置文件控制,应该也支持spring boot动态配置 |
黑白名单 | 支持 | 不支持 | 个人觉得这个功能用的不是很多 |
springcloud集成 | 高 | 非常高 | Spring boot使用hystrix会更方便 |
整体优势 | 集中配置设置及监控+更细的控制规则 |
漂亮的界面+接近实时的统计结果 | 集中配置可能更有吸引力,但是配置值是多少以及让谁控制依然是很头疼的事情。运维控制可能不知道哪个应该优先哪个不优先,应该调整到多大。什么时候更适合使用sentinel?个人认为docker容器化部署之后sentinel可能更会发挥作用,但是会有另外的竞品出现做选型。 |