服务雪崩
1. 定义
在微服务之间进行服务调用由于某一个服务故障，导致级联服务故障的现象，称为雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。
2. 图解
某个场景中存在如下调用链路：
已知ServiceA的流量波动很大，流量经常会突然性增加。那么在这种情况下，就算ServiceA能扛得住请求，ServiceB和ServiceC也未必能扛得住这突发的请求。此时，如果ServiceC因为抗不住请求，变得不可用。那么ServiceB的请求也会阻塞，慢慢耗尽ServiceB的线程资源，ServiceB就会变得不可用。紧接着，ServiceA也会不可用。
这一过程如下图所示：
过程解析：
在SpringCloud中，由于每一个微服务都是用SpringBoot构建的，SpringBoot内置Tomcat来处理服务之间的请求与响应。假设ServiceC发生异常，ServiceB发给ServiceC的请求就不会得到响应，则ServiceB对于这个线程就不会释放，处于阻塞状态。当越来越多的ServiceA的请求到来，ServiceB中越来越多的线程会阻塞。Tomcat内置线程池支持的线程和并发数有限，如果ServiceB的请求一直阻塞，会导致ServiceB服务器CPU资源耗尽，从而导致ServiceB不可用。以此类推，ServiceA也会不可用，形成雪崩效应。
注意：在测试某个服务并发量时，可用使用JMeter工具。
服务熔断
“熔断器"本身是一种开关装置。当某个服务单元发生故障之后，通过断路器的故障监控，某个异常条件被触发，直接熔断整个服务。出现异常的调用方法会返回一个符合预期的、可处理的备选响应（Fallack） ，而不是长时间的等待或者抛出调用方法无法处理的异常。保证了服务调用方的线程不会被长时间占用，避免故障在分布式系统中蔓延，乃至雪崩。如果目标服务情况好转则恢复调用。服务熔断保护了调用链路，是解决服务雪崩的重要手段。
图示：
服务降级
服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此缓解服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分客户能得到正确的响应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。通俗来说就是，关闭系统中边缘服务保证系统核心服务的正常运行。
图示：
服务熔断和服务降级总结
1. 相同点
- 目的很一致，都是从可用性和可靠性着想。为防止系统的整体缓慢甚至崩溃，采用的技术手段。
- 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用。
- 粒度一般都是服务级别。当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改)。
- 自治性要求很高，熔断模式一般都是服务基于策略的自动触发。降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能。开关预置、配置中心都是必要手段。
2. 不同点
- 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起。而服务降级一般是从整体负荷考虑。
- 管理目标的层次不太一样。熔断其实是一个框架级的处理，每个微服务都需要（无层级之分)。而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）。
3. 总结
熔断必会触发降级，所以熔断也是降级一种。区别在于熔断是对调用链路的保护，而降级是对系统过载的一种保护处理。
