我们知道,在目前微服务中,众多的微服务调用关系错综负责,为了维护系统的稳定,引入了限流、降级、熔断等概念,这其中比较出名的是Hystrix和Sentinel,来聊聊这二者的异同。
Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 具有以下特征:
Hystrix介绍描述如下
Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency.
Hystrix主要功能如下:
Hystrix主要以隔离和熔断为容错机制,超时或被熔断的请求将快速失败,能够failback以及降级
Sentinel则主要在多样化的流量控制、熔断降级、系统负载保护等。
Hystrix采用了Command命令模式
,会将对外部的调用以及相关的failback逻辑封装成一个HystrixCommand命令对象,底层基于RxJava实现了异步调用,创建Command的时候需要指定commandKey和groupKey( groupKey用来区分不同资源),还要设置隔离策略(线程池或信号量)
而对于Sentinel来说,其底层实际执行通过不同的ProcessSlot
来执行,采用了类似职责链默认,所有的ProcessSlot组合成一个链表,从头到尾执行,在新的版本中可以通过SentinelResource
注解定义一个资源,每个资源都会对应一个ProcessSlot链
Hystrix提供了信号量和线程池两种隔离方式,默认是线程池,这种情况下,方法实际执行都是在Hystrix的线程池中,这就涉及到了线程切换,需要从当前线程切换到Hystrix的线程池中。
线程池带来的好处是比较明显的,同一个资源采用的是同一个线程池不会影响其他资源的线程池,当某个资源调用出现问题的时候,只会影响该资源不会影响其他资源
当然了Hystrix也提供了信号量模式,这种是比较轻量的
Sentinel并没有自己独立的线程池,都是基于用户线程执行的。Sentinel 可以通过并发线程数模式的流量控制来提供信号量隔离的功能。并且结合基于响应时间的熔断降级模式,可以在不稳定资源的平均响应时间比较高的时候自动降级,防止过多的慢调用占满并发数,影响整个系统
看过分析Hystrix和Sentinel熔断降级的实现会发现,这两者代码原来基本上是一样的,除了基于异常比例熔断降级,Sentinel还提供了慢调用比例( 基于平均响应时间)当响应时间超过阈值的时候,进行熔断降级
Hystrix和Sentinel都提供了统计指标,都是基于滑动窗口,Sentinel的dashboard从我个人感觉上来说比Hystrix要好,并且Sentinel的很多配置都能够通过Dashboard动态推送到Sentinel客户端进行更新无需重启,而Hystrix部分配置需要重才能更新
二者都是开源,但是目前Hystrix的Netflix团队已经不在维护了,而Sentinel阿里团队一直在迭代更新,社区也在不断发展
Sentinel比Hystrix更加轻量级,性能也更好一点,并且经过了双十一阿里的超大流量考验。
目前来说,个人比较推荐Sentinel