前言
最近在github里比较火的一个新闻就是trending的弃用；确实作为追求技术价值的组织机构，github弃用毫无价值感的trending，是一件好事，一些劣质的项目长期占用着榜单前列，确实对技术有误导的非常大的恶；同样作为国内某号称国内最大的IT技术论坛的网站，也应该认真的看待这个问题了；看看榜单前几篇文章，真够寒酸；今天在榜单里看到一个写springcloud的文章，熔断器停留在springboot2.1.x的版本基础上，这样的文章，还能叫创新吗；所以今天咱们就来好好的看看Springcloud中的几个主流熔断器
熔断器
在微服务体系架构中，业务被拆分成众多的单体微服务单元(Springboot程序)，服务间通过服务发现机制，借用HTTP/TCP进行RPC调用。考虑到可能出现的网络原因或者服务本身原因，在服务或者RPC网络不可使用(访问)时，如果某源头服务出现问题，例如网络延迟，都会对调用服务造成相应的影响，有时甚至由于同时访问目标过多，会导致服务瘫痪，甚至导致服务“雪崩”。熔断器就是一种应对这种灾难风险的策略； 即当服务不可以使用是或者是服务到达某个临界点时， 对该服务进行阻断的处理方式， 通过这种方式，可以容忍这样的灾难服务，而不会使真个大的体系崩溃，有点像家庭用电里的断路保险盒，某个线路负载过重了，只是断掉该线路，而整个家庭线路依然可以提供服务。
几个Springcloud框架中的熔断器
这里注意，熔断器的产品有很多；我们这里特别强调的是，这里的熔断器是Springcloud架构中的， 也就是其是构建在Springcloud架构体系中的， 脱离了Springcloud，这些产品就没有生命了；也就只能是使用在java环境里，你的微服务也必须使用java来进行实现，而且要快速搭建，还必须使用springboot已经这些产品在springcloud里提供的组件（当然，可以自己通过这些产品的API来进行调用）
1147
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
