参考
熔断机制
https://www.cnblogs.com/huangjuncong/p/9026949.html
https://blog.csdn.net/aa1215018028/article/details/81700796
https://www.jianshu.com/p/7c0a3723e2e4
概述
熔断机制的实现方法： 熔断+重试， 超时和异常会出发熔断。
如何避免雪崩效应：
- 超时机制，超过设定时间没有返回结果则直接返回结果，避免长时间阻塞等待
- 服务限流：利用线程池或者信号量来限制最大并发线程数，从而降低节点的负载过高
- 服务熔断:当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源，比如我们设置了超时时间为1s，如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个服务了，这个时候就应该使用熔断器避免资源浪费
- 服务降级:所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback（回退）回调，返回一个缺省值。 例如：(备用接口/缓存/mock数据)，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景
熔断机制的好处：
- 避免雪崩效应（一个服务不可用，导致多个关联的的服务都不可用，虽然这个异常的微服务可能不是核心的服务）
- 缓解堆积效应：避免了消费端的线程等待的时间和等待的消费端的数量（快速返回异常结果 + 一段时间内不会接收请求)
雪崩效应
微服务之间的相互调用，如果某个服务出现异常（阻塞 超时 或者报错了），就导致所有的服务都阻塞和报错。
因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程，就叫服务雪崩效应
雪崩的原因：
- 程序异常
- 负载过高
熔断机制
当服务链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后，恢复调用链路。
在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
在Nginx里面也是这样的，集群
Nginx的熔断机制
当失败的调用（操作超时）次数超过max_fails时，fail_timeout时间内不会再转发请求到这个Node，然后又重试该节点。这就是一种熔断，避免大量的请求在异常的节点上面堆积。
- fail_timeout默认为10s，当判断某一个节点需要熔断时，10s内不会又请求转发到这个节点。
- max_fails默认为1。就是说，只要某个server失效一次，则在接下来的10s内，就不会分发请求到该server上
- proxy_read_timeout 读请求的响应事件，如果超过了这个时间还未返回，就触发一次超时
Dubbo的熔断机制
- 默认的Failover策略就是熔断机制，默认同步调用1s仍然没有返回结果，就会轮询下一个节点发起调用，最终调用retry_times 次数
