关于熔断器Hystrix替代方案的调研报告

关于熔断器Hystrix替代方案的调研报告
一、背景
Netflix宣布停止Hystrix熔断器的开发，目前进入了维护模式。同时，也指出了Hystrix 1.5.18版本足够满足现阶段的应用（详细请参看:Hystrix Status）。

  虽然Hystrix 1.5.18版本目前能满足公司应用的要求，但随着公司技术栈的更新，势必很大可能导致此版本的Hystrix与相关技术不兼容。这样就需要提前

调研好可用的替代方案，以应变将要发生的由于版本不兼容或其他原因导致的问题。

二、Hystrix与可替代熔断器大体介绍
1.Hystrix
Hystrix是一个用来隔离远程系统、服务或第三方库访问时延迟与故障容错的库，用来阻止级联的服务失败及弹性化控制不可避免发生失败的复杂的分布式系统。

  它是通过这些方式来解决问题的：

        ---隔离(线程池隔离和信号量隔离)。限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用；

        ---优雅的降级机制。超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据；

        ---熔断。当失败率达到阀值自动触发降级(如因网络故障或超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复；

        ---缓存。提供了请求缓存、请求合并实现；

        ---支持实时监控、报警、控制(修改配置)。

2.可替代熔断器：

Sentinel
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

    Sentinel具有以下特征：

        1.丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、

           集群流量控制、实时熔断下游不可用应用等。

        2.完美的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

        3.广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简

          单的配置即可快速地接入 Sentinel。

        4.完善的SPI扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

    Sentinel的主要特性：

    Sentinel的开源生态：

Sentinel分为两个部分：
1.核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
2.控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

哪些公司在用呢？
以下是部分使用 Sentinel 的企业列表

示例代码地址：https://github.com/alibaba/Sentinel/tree/master/sentinel-demo
交流群：

Resilience4j
Resilience4j是一个灵感来自Netflix Hystrix而开发的轻量级的容错库，特意为Java 8和函数式编程而设计。

    轻量级是因为

          ---这个库使用了Vavr(formerly Javaslang)，这个不会依赖外部的库。相对而言，Netflix Hystrix，编译时依赖Archaius，而Archaius会依赖大量的外部库，如Guava、

              Apache Commons Configuration等等；

          ---同时，使用时你不必引入所有的Resilience4j库文件，你只需引入你需要的那部分即可。

    大致有如下功能

          ---CircuitBreaker，Retry and Fallback：CircuitBreaker可以用来当服务调用失败达到阀值时进行熔断；当调用下级服务失败时，Retry可以配置进行重试的次数及重试

              间隔的时间等等；Fallback可以用在发生异常时，进行服务降级处理。

          ---RateLimiter：用于方法的流量限制，比如限制方法A每秒不超过一次调用

          ---Bulkhead：Bulkhead(术语：舱壁)可以用来限制并发调用的次数。Bulkhead可以跨各种线程和IO时运行良好。它是基于信号量运作的，与Hystrix不同的是，它不提供

              线程池运作方式。

          ---Cache：Cache可以用来缓存上次的结果。 之后调用时会直接查询缓存获取结果，如果没有获取到，会接着调用服务进行获取结果。

          —Metrics：关于服务的一些度量，如总的调用次数、成功调用次数、失败调用次数、流量速度、成功调用时的响应时间等等。

          ---Consume emitted events：CircuitBreaker，RateLimiter，Cache，Retry等组件可以发送大量可以被消费的事件，即你可以自定义消费者消费这些事件。

    哪些公司在用呢？

          Deutsche Telekom(每天超过4亿请求的应用)

          AOL(低延迟请求的应用)

          Netpulse(在系统中有40+的集成)

          wescale.de(一个B2B集成平台)

          Topia(一个用微服务架构的HR应用)

          Auto Trader Group plc(英国最大的数字汽车市场)

          PlayStation Network(平台后端)

    示例代码地址：https://github.com/RobWin/resilience4j-spring-boot-demo

Failsafe
Failsafe是一个轻量级、零依赖的库，用于在Java 8+处理错误。其使用简明的API去处理每天的事务，同时还可以弹性的处理这些事务。它通过使用一个或更多的弹性策略去包裹执行

逻辑来运行，即这些策略可以根据需要进行组合。

    这些策略如下：

        ---Retries：重试策略

        ---Circuit breakers：熔断

        ---Fallbacks：降级

    贡献

        Failsafe是Halterman作者本人及一些志愿者努力的成果。

    示例代码地址：https://github.com/jhalterman/failsafe

三、对比说明
上述几种熔断器中目前最为流行的是以下三种，功能对比如下

   就目前调研发现这几种技术大体类似：

       ---都能满足生产上的一些基本要求；

       ---各种公司也都在使用它们；

       ---都提供了一些示例代码，方便进行参考开发

       ---都在github上可以找到其对应的开源代码

       ---它们的文档都写得挺详细的，便于开发

       ---都可以用控制台进行实时监控

   相比较Hystrix与Resilience4j而言，Sentinel更加有优势(不考虑Hystrix目前是标准配套技术)，理由如下

       ---Sentinel使用了资源与控制规则分离，代码侵入性更小，开发相较容易不少

       ---Sentinel除了可以在控制台进行实时监控，还可以在控制台配置熔断规则

       ---Sentinel官方提供钉钉交流群，开发人员可以进行沟通，提高了解决问题的效率

       ---根据上面对比可以看出，虽然这几种技术的功能大体相同，但Sentinel更为强大

       ---相比较而言，Sentinel的文档更为详细，同时配套功能更为完备

       ---Sentinel官方提供了从Hystrix到Sentinel迁移的具体方案(迁移方案)

   相比较Hystrix而言，Sentinel与Resilience4j这两种技术目前并未被大量使用，而使用它们的公司并未对它们的使用情况进行一些评价，从而无从得知是否如它们描述的那样强大。

四、结论
正如Netflix说的那样，目前Hystrix 1.5.18版本足以支撑现有应用，建议暂时无需进行Hystrix的替换，可以暂且观察替代技术或其他技术的发展，最后再进行决定选用哪种技术。

   如果现在就需要做Hystrix的替换，建议使用阿里的Sentinel(理由如第三部分的对比说明)。