简介
目的
保证不管依赖的其他系统如何,自己的系统都会稳定运行。
Sentinel与Hystrix的对比
-
Hystrix和Sentinel的关注点不同
-
Hystrix的关注点在于以隔离和熔断为主的容错机制,提供fallback机制。
-
Sentinel在于多样化的流量控制,熔断降级,系统负载保护,实时监控和控制台
-
-
Hystrix的资源模型设计上采用了命令模式,将对外部资源的调用和 fallback 逻辑封装成一个命令对象(
HystrixCommand
/HystrixObservableCommand
),其底层的执行是基于 RxJava 实现的;Sentinel 的原则非常简单:根据对应资源配置的规则来为资源执行相应的限流/降级/负载保护策略。 Sentinel 并不指定执行模型,也不关注应用是如何执行的。 -
隔离设计上的区别
-
Hystrix支持线程池隔离和信号量隔离。线程池隔离存在问题,在组件实现超时熔断和流量控制的能力时,线程池隔离就没有必要。所以Sentinel只采用了信号量隔离。
-
-
熔断降级
-
Sentinel和Hystrix的熔断降级本质上都是基于熔断器模式。
-
都支持异常比率的熔断降级,但Sentinel还支持基于平均响应时间的熔断降级。
-
-
Sentinel具有轻量级、高性能的特点
-
核心sentinel-core打包后只有不到200KB
-
引入Sentinel带来的性能损耗非常小
-
-
Sentinel具有流量控制的功能
-
Sentinel 可以针对不同的调用关系,以不同的运行指标(如 QPS、并发调用数、系统负载等)为基准,对资源调用进行流量控制
-
Sentinel功能和设计理念
流量控制
-
Sentinel 作为一个调配器,可以根据需要把随机的请求调整成合适的形状
-
流量控制有以下几个维度
-
QPS
-
线程池
-
系统负载
-
-
控制的效果
-
直接限流
-
冷启动
-
排队
-
熔断降级
-
由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,可能会导致请求发生堆积,进而导致级联错误。
-
Sentinel和Hystrix的原则是一致的:当检测到调用链路中某个资源出现不稳定的表现,例如请求响应时间长或异常比例升高的时候,则对这个资源的调用进行限制,让请求快速失败,避免影响到其他的资源而导致级连故障。
-
Hystrix和Sentinel的熔断降级设计不相同
-
Hystrix使用了线程池隔离,对每一个要降级的服务都会有一个线程池,这样的问题就在于线程数量可能会过大
-
Sentinel支持两种方式的降级
-
限制一个资源的并发线程数
-
限制一个资源的响应时间
-
-
Sentinel的简单实践
public static void main(String[] args) { //配置规则 initFlowRules(); while (true) { //1.5.0可以直接利用try-with-resource特性 try (Entry entry = SphU.entry("hello world")) { //被保护的逻辑 System.out.println("hello world"); } catch (Exception e) { //处理被流控的逻辑 System.out.println("blocked"); } } } private static void initFlowRules() { List<FlowRule> rules = new ArrayList<>(); FlowRule rule = new FlowRule(); rule.setResource("hello world"); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); // Set limit QPS to 20. rule.setCount(20); rules.add(rule); FlowRuleManager.loadRules(rules); }
其他
系统负载
-
其实简单的衡量方式就是CPU的使用程度
-
按我理解,还可以按照QPS来衡量,比如一个资源的QPS是500,某个时刻并发线程数是1000,那么系统负载就达到1000/500=2.0,超载了
信号量隔离
-
信号量其实就是并发线程数
-
按我理解,就是对一个资源的并发线程数
冷启动
-
简单来说,就是没有数据或数据量过少,很可能无法实现非常好的效果。