1.什么是微服务雪崩？微服务雪崩的解决方案？
微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。服务A依赖于服务B，服务A依赖于服务D。现在假设，服务D出现了故障！
它访问这个服务D就必然要等待服务D的结果,那因为服务D出现了故障，那必然不能返回结果，结果就是它会阻塞在这里。
那这就导致了服务A内部的这个业务是不是也会阻塞在这里？阻塞就会导致它不会释放服务器的连接。假如再有其他服务它们依赖于服务A，那么这些依赖于服务A的这些业务是不是也会拖垮？
到最后出现故障的服务越来越多，那么整个微服务群都不可用了，这不就是雪崩了。

微服务雪崩的解决方案：
1.1.超时处理
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。当服务A它的业务，依赖于服务D时，它最多等一秒。如果服务D故障以后，这个等待超过了一秒，
它会立即结束这个请求，不再返回给用户一个提示信息。现在假设新的请求速度是每秒钟两个，释放的速度没有进入的速度快，终有一天服务A的资源也有可能会被耗尽？
所以你设置超时时间也只是起到了一个缓解作用，并没有从根本上解决这个问题。

1.2.舱壁模式
限定每个业务使用的线程数，避免耗尽整个Tomcat的资源，因此也叫线程隔离。
服务A可以看成整艘船，然而我们该怎么避免整个Tomcat挂掉呢？
我们就把Tomcat里面的资源，也就是线程，划分成一个一个的独立的线程池。比方说给服务A中的业务1分配10个线程池，业务2分配10个。
那么现在业务1进来之后，它依赖于服务D。那它最多使用10个线程，访问业务2，它依赖于服务C。
那现在服务C出现故障了，那这个业务就会阻塞，占用我们的线程，但是，它最多占用10个。
那这个时候它能够使用的Tomcat 资源是不是有限呢？是不是就把这个故障隔离到了10个线程内了？
对此这个模式也叫线程隔离模式，它其实啊就避免了整个Tomcat资源耗尽的这种情况。
当然这个模式它确实解决了超时处理方案所遗留的问题，只不过资源可能会有一些浪费。
比如说，服务C宕机挂了，接下来你还是会尝试区请求这个服务C，明知道它已经挂掉了，你还要尝试访问，还要暂用我10个线程，是不是一种浪费？

1.2.3 熔断降级
由断路器统计业务执行的异常比例，如果超出阈值会熔断该业务，拦截访问该业务的一切请求。
在这个业务里面，出现故障的请求和正常的请求之间的一个比例是什么样子的？如果超出了阈值，则会熔断这个业务，什么是熔断，就是拦截访问该业务的一切请求。

1.2.4 流量控制
限制业务访问的QPS，避免服务因流量的突增而故障。
比如说，这里有一个受保护的服务，它能承受的最大QPS是2，也就是每秒钟最多处理两个请求，但是现在有无数的请求涌过来，那你说他能承受得了吗？那肯定是不行的呀，这不被打成筛子了。
而一旦这个服务出现了故障，那依赖于这个服务的其他服务是不是也都跟着会出现故障，那岂不是也会出现雪崩状况，所以，我们一定要尽可能的避免服务因为流量过高而引起故障。
那我们该怎么办呢？这就用到了我们的Sentinel了。
假如真的有无数个请求融入过来，而Sentine