降级设计Degradation

降级设计，本质是为了解决资源不足和访问量过大的问题。当资源和访问量出现矛盾的时候，在有限的资源下，为了能够抗住大量的请求，我们就需要对系统进行降级操作。也就是说，暂时牺牲掉一些东西，以保障整个系统的平稳运行。

一般来说，我们降级需要牺牲掉的东西有：
降低一致性。从强一致性变成最终一致性。
停止次要功能。停止访问不重要的功能，从而释放出更多的资源。
简化功能。把一些功能简化掉，比如，简化业务流程，或是不再返回全量数据，只返回部分数据。

降级熔断：如何屏蔽非核心系统故障的影响

雪崩是如何发生的
局部故障最终导致全局故障，叫做雪崩。那么，为什么会发生雪崩呢？我们知道，系统在运行的时候是需要一些资源的，包括CPU、内存等资源，也包括执行业务逻辑的时候，需要的线程资源。

举个例子，一般在业务执行的容器内，都会定义一些线程池来分配执行任务的线程，比如在Tomcat这种Web容器的内部，定义了线程池来处理HTTP请求；RPC框架也给服务端初始化了线程池来处理RPC请求。（异步调用RPC和RPC自己的异步？）

这些线程池中的线程资源是有限的，如果这些线程资源被耗尽，那么服务自然也就无法处理新的请求，服务提供方也就宕机了。比如，你的电商系统有四个服务A、B、C、D，A调用B，B调用C和D。其中，A、B、D服务是系统的核心服务（像是电商系统中的订单服务、支付服务等等），C是非核心服务（像反垃圾服务、审核服务）。

所以，一旦作为入口的A流量增加，那么需要把A、B和D服务扩容，忽略C。那么C就有可能因为无法承担这么大的流量，导致请求处理缓慢，进一步会让B在调用C的时候，B中的请求被阻塞，等待C返回响应结果，这样一来，B服务中被占用的线程资源就不能释放。

久而久之，B就会因为线程资源被占满，无法处理后续的请求。那么从A发往B的请求，就会被放入B服务线程池的队列中，然后A调用B响应时间变长，进而拖垮A服务。你看，仅仅是因为非核心服务C的响应时间变长，就可以导致整体服务宕机，这就是我们经常遇到的一种服务雪崩情况。

https://zhuanlan.zhihu.com/p/341939685

http://icyfenix.cn/distribution/traffic-management/failure.html