小谈Springcloud中的几个主流熔断器

前言

最近在github里比较火的一个新闻就是trending的弃用；确实作为追求技术价值的组织机构，github弃用毫无价值感的trending，是一件好事，一些劣质的项目长期占用着榜单前列，确实对技术有误导的非常大的恶；同样作为国内某号称国内最大的IT技术论坛的网站，也应该认真的看待这个问题了；看看榜单前几篇文章，真够寒酸；今天在榜单里看到一个写springcloud的文章，熔断器停留在springboot2.1.x的版本基础上，这样的文章，还能叫创新吗；所以今天咱们就来好好的看看Springcloud中的几个主流熔断器

熔断器

在微服务体系架构中，业务被拆分成众多的单体微服务单元(Springboot程序)，服务间通过服务发现机制，借用HTTP/TCP进行RPC调用。考虑到可能出现的网络原因或者服务本身原因，在服务或者RPC网络不可使用(访问)时，如果某源头服务出现问题，例如网络延迟，都会对调用服务造成相应的影响，有时甚至由于同时访问目标过多，会导致服务瘫痪，甚至导致服务“雪崩”。熔断器就是一种应对这种灾难风险的策略； 即当服务不可以使用是或者是服务到达某个临界点时， 对该服务进行阻断的处理方式， 通过这种方式，可以容忍这样的灾难服务，而不会使真个大的体系崩溃，有点像家庭用电里的断路保险盒，某个线路负载过重了，只是断掉该线路，而整个家庭线路依然可以提供服务。

几个Springcloud框架中的熔断器

这里注意，熔断器的产品有很多；我们这里特别强调的是，这里的熔断器是Springcloud架构中的， 也就是其是构建在Springcloud架构体系中的， 脱离了Springcloud，这些产品就没有生命了；也就只能是使用在java环境里，你的微服务也必须使用java来进行实现，而且要快速搭建，还必须使用springboot已经这些产品在springcloud里提供的组件（当然，可以自己通过这些产品的API来进行调用）

隔离级别

信号量模式

　　在该模式下，接收请求和执行下游依赖在同一个线程内完成，实现也很简单，一个简单的计数器，当请求进入熔断器时，执行tryAcquire(),计数器加1，结果大于阈值的话，就返回false，发生信号量拒绝事件，执行降级逻辑。当请求离开熔断器时，执行release()，计数器减1。

信号量模式由于都是在一个线程上下文中；不存在线程上下文切换所带来的性能开销，所以大部分场景应该选择信号量模式，但是在下面这种情况下，信号量模式并非是一个好的选择。　　

　　比如一个接口中依赖了3个下游：serviceA、serviceB、serviceC，且这3个服务返回的数据互相不依赖，这种情况下如果针对A、B、C的熔断降级使用信号量模式，那么接口耗时就等于请求A、B、C服务耗时的总和，无疑这不是好的方案。

线程池模式

　　在该模式下，用户请求会被提交到各自的线程池中执行，把执行每个下游服务的线程分离，从而达到资源隔离的作用。当线程池来不及处理并且请求队列塞满时，新进来的请求将快速失败，可以避免依赖问题扩散。线程池模式由于是线程资源分割的；减少所依赖服务发生故障时的影响面，比如ServiceA服务发生异常，导致请求大量超时，对应的线程池被打满，这时并不影响ServiceB、ServiceC的调用。

但是线程池模式的最大缺点： 请求在线程池中执行，肯定会带来任务调度、排队和上下文切换带来的开销。因为涉及到跨线程，那么就存在ThreadLocal数据的传递问题，比如在主线程初始化的ThreadLocal变量，在线程池线程中无法获取； 这里笔者在早期的微服务项目中使用Hystrix的线程池隔离方式，就遇到过类似的坑，当然知道了底层的原因有也相应的对策；这里可以单独写一个文章来讲讲这个坑。

三种主流熔断器的现况

Hystrix

Netfix已经停更了Hystrix项目，从SpringCloud版本2020.0.x项目开始，诸多的Netfix的组件都已经从springcloud的支持里移除，其中就包括Eureka，Hystrix， Ribbon； 所以Hystrix熔断器已经从Springcloud解决方案里废除掉了，如果你的项目里已经使用了Hystrix，那么请在你的SpringCloud下次升级的时候，找到替换产品；如果你的项目还没有开始的话，那就请不要再使用Hystrix，使用Springcloud官方推荐的Resilience；

Resilience4j

在Hystrix从SpringCloud家族中被删除后，SpringCloud官方推荐的是另一款目前来说还比较小众的项目的Resilience4j，可以在github上找到这个开源的项目；在上图的三种产品的比较中，我们就可以看到在三种产品中，resilience4j是一个适中的定位；在功能上没有sentinel支持的多，但是功能也一样可以覆盖到对熔断器的大多数要求； 就笔者个人使用而言，目前resilience的文档相对来说还不够丰富，使用的不多，文档就相对来说比较难找了，但是resilience4j非常的轻量级，作为开发中需要对熔断器有一些自己的定制化的话，比较推荐使用这个产品； 目前resilience对feign的支持，只能说是支持，但是还不是支持的特别方便，如果要比较方便的支持到feign的应用，只能在resilience4j的基础上进一步进行封装。总体来说，优于Hystrix， 可灵活进行扩展和应用。

Sentinel

首先来说这是Alibaba出品的一个产品；所有他有着alibaba产品共有的特点； 脏，乱，但不差！ 在上面的图中三个产品的比较中，可以看到大部分比较的方面，Sentinel都是胜出的，确实，从功能上而言，Sentinel相对于另两个而言，是较全面的，还提供了一个Sentinel dashboard，可以图形化的进行查看，通过和nacos的集成，可以把只读的配置，实现成可读写的配置；但是整个项目封装性太强， 给你扩展和应用的空间不够开放； 对于要求不高的技术人员和项目，推荐使用Sentinel；但是如果有一定要求的，还是推荐使用Resilience4j。