降级
降级
上面的熔断，是为了在系统过载时不发生雪崩，限流是为了流量较大时，系统不发生过载。但是这两者都不会区分该服务是核心业务还是非核心业务。而降级，则是为了减少或者停掉一些非核心业务，来确保核心业务收到的影响最小。
为什么需要降级
- 降级机制能从全局角度对资源进行调配，通过牺牲非核心服务来保障核心服务的稳定性。降级是主动停掉一些非核心业务，而限流则是被动的将一些请求拒绝。
- 降级可以提高系统的用户体验性和可用性。在一些场景中，如果正常调用出现了非业务层错误后，我们可以不返回错误，而是执行接口的B计划，进行降级，虽然可能和正常流程不太一样，但是比直接返回错误要好。
如何实现降级
手动降级
手动降级是指在分布式系统中提前设置好降级开关，然后通过类似配置中心的集中式降级平 台，来管理降级开关的配置信息，在系统需要降级的时候，通过降级平台手动启动降级开关， 对系统进行降级处理。
该方案需要注意的是，往往服务有成千上百个，如果全部手动操作，则很麻烦。一个解决办法是：通过对降级分级，利用服务的等级信息和业务信息进行批量降级，比如一次直接把p1,p2,p3的服务全部降级。
自动降级
自动降级是指在分布式系统中，当系统的某些指标或者接口调用出现错误时，直接启动降级逻辑。一个降级的例子如下：
我们在网关中调用鉴权服务进行鉴权，每一 个调用鉴权服务的鉴权接口，需要执行如下的两个校验逻辑，不论哪一个失败，都会导致鉴权失败。
- 校验 Token 是否合法。
- 校验 UID 是否被管理员封禁。
在这个情况下，我们可以将 Token 设计为可以自校验的，在鉴权服务出现故障的时候，则启动降级逻辑，直接在网关中校验 Token 是否合法，如果合法就返回鉴权成功。
降级机制的关键问题
一般来 说，我们使用降级都是在系统已经出现过载的场景下，这时我们需要考虑，降级的配置信息是 否能正常下发。并且，降级通常会与熔断和限流一起出现，我们应该如何处理它们三者之间的关系。
配置信息下发的问题
对于熔断和限流来说，其阈值相关的配置信息在系统正常运行的时候，就已经下发到实例上了，所以在系统出现故障的时候，这些配置信息会直接生效。但是对于手动降级，我们需要在系统出问题时，通过降级平台下发配置来启动降级。
针对于配置无法正常下发的情况，我们可以考虑，由服务直接暴露出修改降级配置的 HTTP 接口，在必要的时候，可以手动通过 HTTP 接口，来启动服务的降级逻辑。
熔断、限流和降级之间的关系
首先，因为熔断机制是系统稳定性保障的最后一道防线，并且它是自适应的，所以我们应该在系统全局默认启用；
其次，限流是用来保障被限流服务稳定性的，一般在系统的核心链路和核心服务上，默认启用限流机制；
最后，降级是通过牺牲被降级的接口或者服务，来保障其他的接口和服务正常运行的，可以通过降级直接停用非核心服务，然后对于核心接口和服务，在必要的时候，可以提供一个“ B 计划”。
参考
《深入浅出分布式技术原理》