本文作者主要跟大家分享熔断的作用以及做法,sb767.com:并且总结了一些自己的最佳实践。


这就是一个完整的熔断机制的面貌。了解了这些核心思想,用什么框架去实施就变得不是那么重要了,因为大部分都是换汤不换药。


上面聊到的这些可以说是主干部分,还有一些最佳实践可以让你在实施熔断的时候拿捏的更到位。


做熔断的最佳实践


什么场景最适合做熔断


一个事物在不同的场景里会发挥出不同的效果。以下是我能想到最适合熔断发挥更大优势的几个场景:

  • 所依赖的系统本身是一个共享系统,当前客户端只是其中的一个客户端。这是因为,如果其他客户端进行胡乱调用也会影响到你的调用。

  • 所有依赖的系统被部署在一个共享环境中(资源未做隔离),并不独占使用。比如,和某个高负荷的数据库在同一台服务器上。

  • 所依赖的系统是一个经常会迭代更新的服务。这点也意味着,越“敏捷”的系统越需要“熔断”。

  • 当前所在的系统流量大小是不确定的。比如,一个电商网站的流量波动会很大,你能抗住突增的流量不代表所依赖的后端系统也能抗住。这点也反映出了我们在软件设计中带着“面向怀疑”的心态的重要性。


做熔断时还要注意的一些地方


与所有事物一样,熔断也不是一个完美的事物,我们特别需要注意两个问题。


首先,如果所依赖的系统是多副本或者做了分区的,那么要注意其中个别节点的异常并不等于所有节点都存在异常,需要区别对待。


其次,熔断往往应作为最后的选择,我们应优先使用一些「降级」或者「限流」方案。


因为“部分胜于无”,虽然无法提供完整的服务,但尽可能的降低影响是要持续去努力的。


比如,抛弃非核心业务、给出友好提示等等,这部分内容我们会在后续的文章中展开。


总结


本文主要聊了熔断的作用以及做法,并且总结了一些我自己的最佳实践。


从上面的这些代码示例中也可以看到,熔断代码所在的位置要么在实际方法之前,要么在实际方法之后。


它非常适合 AOP 编程思想的发挥,所以我们平常用到的熔断框架都会基于 AOP 去做。


熔断只是一个保护壳,在周围出现异常的时候保全自身。但是从长远来看平时定期做好压力测试才能更好的防范于未然,降低触发熔断的次数。


如果清楚的知道每个系统有几斤几两,在这个基础上再把「限流」和「降级」做好,这基本就将“高压”下触发熔断的概率降到最低了。