熔断的意义和适用场景，你真的清楚吗？

关于熔断，网上的文章很多，但是真正讲明白的文章寥寥无几。很多作者互相抄袭，缺乏自己的认知和理解。

分享熔断之前，咱们先说说大家更熟悉的Timeout。Timeout和熔断有关系吗？别急，往下看就清楚啦！

我们在跨系统调用、跨服务调用以及调用第三方接口时，一般会设置超时时间。有两个作用：其一，出于用户体验考虑，啥结果也不返回，一直让人等下去，确实受不了。其二，出于系统性能问题的考虑，并发不高时timeout可以避免线程阻塞带来的性能问题，但是并发高时timeout就不能解决问题啦。

现在轮到熔断大显身手了。

熔断是什么？
一种降级手段。当服务不可用时，用来避免连锁故障，雪崩效应。发生在服务调用的时候，在调用方做熔断处理。

熔断的意义是什么？
我们使用熔断前要先弄清楚熔断的真正意义，避免用错给系统带来麻烦。实际上，用一句话就可以描述熔断的意义：上游服务快速失败（Fail Fast），并保护下游服务。

详细解释一下，假设上游服务是A，下游服务是B，A调用B，B发生故障，开启熔断：
对于上游服务A：请求到A后直接快速返回（返回值可以是默认值，或者通过一种后背（Fallback）方案获取的值），快速失败，不再发送到B。 避免因为B故障，导致请求线程持续等待，进而导致线程池线程和CPU资源耗尽，进而导致A无响应甚至整条调用链故障。

对于下游服务B：熔断后，请求被A拦截，不再发送到B，B压力得到缓解，避免了仍旧存活的B被压垮，B得到了保护。

熔断状态流转过程：
假设上游服务是A，下游服务是B，A调用B。
熔断生命周期包括三个状态：关闭，半开启，开启。
关闭状态->开启状态，A调用B请求失败次数在设定时间内达到阈值，开启熔断
开启状态->半开启状态，熔断开启后，熔断器根据设定时间间隔定期自动进入半开启状态
半开启状态->关闭状态（或开启状态），半开启状态下会从A发送少量请求到B来试探B服务是否能正常提供服务，如果请求成功率达到阈值就关闭熔断，否则就回到熔断开启状态

熔断适用场景
出于系统性能问题的考虑，并发不高时timeout可以避免线程阻塞带来的性能问题，但是并发高时timeout就不能解决问题啦。这时可以用熔断。

只要是服务之间的调用，并且能设计合理的获取返回值的方案（返回值可以是默认值，或者通过一种后备（Fallback）方案获取的值），一般业务场景都可以做熔断处理。比如电商行业，在sku不是很多的场景下，我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，开启熔断后，我们可以直接从订单服务取库存，订单服务取不到库存，按扣减库存失败处理。这个可以做为后备（Fallback）方案。

有哪些开源实现
Hystrix，Resilience4j等