由于爆炸性的流量冲击，对一些服务进行有策略的放弃，以此缓解系统压力，保证目前主要业务的正常运行。它主要是针对非正常情况下的应急服务措施：当此时一些业务服务无法执行时，给出一个统一的返回结果。

　　1、降级服务的特征

　　原因：整体负荷超出整体负载承受能力。

　　目的：保证重要或基本服务正常运行，非重要服务延迟使用或暂停使用。

　　大小：降低服务粒度，要考虑整体模块粒度的大小，将粒度控制在合适的范围内。

　　可控性：在服务粒度大小的基础上增加服务的可控性，后台服务开关的功能是一项必要配置(单机可配置文件，其他可领用数据库和缓存)，可分为手动控制和自动控制。

　　次序：一般从外围延伸服务开始降级，需要有一定的配置项，重要性低的优先降级，比如可以分组设置等级1-10，当服务需要降级到某一个级别时，进行相关配置。

　　2、降级方式

　　延迟服务：比如发表了评论，重要服务，比如在文章中显示正常，但是延迟给用户增加积分，只是放到一个缓存中，等服务平稳之后再执行。

　　在粒度范围内关闭服务(片段降级或服务功能降级)：比如关闭相关文章的推荐，直接关闭推荐区。

　　页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级。

　　页面跳转(页面降级)：比如可以有相关文章推荐，但是更多的页面则直接跳转到某一个地址。

　　写降级：比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

　　读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景。

　　3、降级预案

　　在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅;从而梳理出哪些必须誓死保护，哪些可降级;比如可以参考日志级别设置预案。

　　一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级。

　　警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警。

　　错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级。

　　严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

　　4、服务降级分类

　　降级按照是否自动化可分为：自动开关降级(超时、失败次数、故障、限流)和人工开关降级(秒杀、电商大促等)。

　　降级按照功能可分为：读服务降级、写服务降级。

　　降级按照处于的系统层次可分为：多级降级。

　　5、自动降级分类

　　超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况。

　　失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况。

　　故障降级：比如要调用的远程服务挂掉了(网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常)，则可以直接降级。降级后的处理方案有：默认值(比如库存服务挂了，返回默认现货)、兜底数据(比如广告挂了，返回提前准备好的一些静态页面)、缓存(之前暂存的一些缓存数据)。

　　限流降级：当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级;降级后的处理方案可以是：排队页面(将用户导流到排队页面等一会重试)、无货(直接告知用户没货了)、错误页(如活动太火爆了，稍后重试)。