1.雪崩问题及解决方案
1.1 什么是雪崩问题
在微服务医疗系统中，当医生给患者开立药品医嘱时，需要完成对药品库存的扣减、新医嘱信息的创建、医疗费用的预扣等多个业务活动。假设此时费用中心服务宕机，此时医嘱创建请求会持续等待下游服务的响应，在系统未做任何保护时，请求会在响应之前持续等待，随着更多的请求过来直至医嘱中心服务资源耗尽。费用中心不可用的现象转移到其上游医嘱中心，医嘱中心的不可用随着更多的请求继续向上转移到医生站，最终导致所有服务不可用。
这种在微服务调用链路中，因为某个服务不可用导致上游服务调用者不可用，最终扩大至整个服务集群产生不可用的问题称之为雪崩效应（一个不可用导致全部不可用）。
1.2 造成雪崩问题的原因
造成服务不可用的原因有很多，从硬件、软件的角度都可以大致给出一些故障现场，如硬件：机房故障、网线断开等，软件：流量过载、缓存击穿等。当服务提供者不可用，往往都会出现大量重试的情况：用户重试、代码逻辑重试、MQ重试，这些重试会进一步导致流量增加，加剧了服务雪崩的最终产生。
所以导致雪崩效应的根本原因是：大量同步请求等待造成的资源耗尽，一旦资源耗尽服务调用者提供的服务也处于不可能用砖，于是服务雪崩效应产生。既然有问题肯定也有解决方案，目前通用的解决方案具体如下：
1.3 雪崩问题的解决方案
1 超时处理
针对服务调用增加超时机制(一般dubbo默认30s)，一旦超时自动释放资源，因释放资源较快一定程度可抑制资源耗尽问题。但如果在超时释放的时间内陡增大量请求，依然会导致服务宕机不可用。
2 舱壁模式
限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。它可以避免因部分服务不可用导致整个服务不可用的问题，但是也会存在线程资源浪费的问题了。
3 熔断降级
由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。断路器会统计指定服务的请求数异常比例、异常数：
当发现异常比例、异常数超过配置的阈值时，断路器开始生效，拦截访问下游服务D的一切请求，形成熔断。
4 流量控制
相较于上述的针对已发生情况的自下而上的处理，实际更推荐自上而下的处理方案，这种方案将借助于Sentinel的流控功能去处理，拦截所有的请求，只释放服务能处理的粒度，从而保证服务的稳定性。
1.4 总结
截止此我们学到了两个重要的知识点：
保护：流量控制
解决：超时处理、舱壁模式、熔断降级
