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

　　前言
　　最近在github里比较火的一个新闻就是trending的弃用；确实作为追求技术价值的组织机构，github弃用毫无价值感的trending，是一件好事，一些劣质的项目长期占用着榜单前列，确实对技术有误导的非常大的恶；同样作为国内某号称国内最大的IT技术论坛的网站，也应该认真的看待这个问题了；看看榜单前几篇文章，真够寒酸；今天在榜单里看到一个写springcloud的文章，熔断器停留在springboot2。1。x的版本基础上，这样的文章，还能叫创新吗；所以今天咱们就来好好的看看Springcloud中的几个主流熔断器
　　熔断器
　　在微服务体系架构中，业务被拆分成众多的单体微服务单元（Springboot程序），服务间通过服务发现机制，借用HTTPTCP进行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相对于另两个而言，是较全面的，还提供了一个Sentineldashboard，可以图形化地进行查看，通过和nacos的集成，可以把只读的配置，实现成可读写的配置；但是整个项目封装性太强，给你扩展和应用的空间不够开放；对于要求不高的技术人员和项目，推荐使用Sentinel；但是如果有一定要求的，还是推荐使用Resilience4j。