一篇学习笔记，做一点简单的记录。
雪崩问题
我这里展示了一个微服务中服务调用的一个简单示例，在这个例子上来说一下雪崩问题
在上图中，现在的调用关系都还是正常的，也是我们所期望的样子，但是如果有服务出现故障无法返回结果，就可能发生雪崩问题。
那什么是雪崩问题呢？
微服务调用链中某个服务故障，引起整个链路中所有微服务都不可用，这就是雪崩。
我们来分析一下雪崩出现的原因：
在上图中，我们的所有调用关系都是正常的，服务发起的调用很快就能响应回来，但是如果上图中的服务B发生故障，无法向依赖它的服务D和服务C响应结果 ，那服务D和服务C发起这个调用的线程就会阻塞住（无法释放连接） ，这样的请求肯定不止一个，每次请求都会发生线程的阻塞，这样的线程会越来越多，他们占用着服务器的资源无法释放 ，最后就会导致服务D和服务C无法接受请求（连接资源被耗尽），这样的问题也会影响到依赖于D和服务C的其他服务。
总结一下：
一个服务故障导致依赖于它的服务也出现故障，而在微服务中，这样的依赖关系可能会很复杂，受到影响的服务会非常多，这就是雪崩
解决雪崩问题的常见方法
- 超时处理
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无止休的等待。
样的方式可以缓解雪崩问题，但也会有一种情况，也就是请求发起的速度远高于它释放的时间，它可能还没来得急释放连接就资源就被占满了
2.舱壁模式
限定每个业务所能使用的线程数，避免耗尽整个服务器的资源，因此也叫线程隔离。
控制并发调用数，这样就算业务B的调用发生了故障也不会影响到整个服务，
虽然解决了雪崩问题，但是也会有资源的浪费，服务C已经故障了，但还是一直有请求访问
- 熔断降级
有断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
断路器会统计服务A发生异常的请求（以请求服务D为例），如果异常的比例超过了阈值，这个时候就会出现熔断，这个时候服务A又来请求访问服务D，就会拦截这个请求，然后快速失败。
- 流量控制
限制业务访问的QPS，避免服务因流浪的突增而故障。
预防雪崩问题，避免服务出现故障，这样就不会出现故障传递，进而引起雪崩问题