什么是服务降级
服务降级是当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易的能正常运行。
服务降级主要用于当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
服务降级的预案
在进行降级之前要对系统进行梳理，看看哪些服务是必须誓死保护，哪些系统是能够丢卒保帅；具体可以参考日志级别设置预案：
- 一般：有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
- 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
- 错误：可用率低于90%，或者连接池被占用满了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
- 严重错误：因为特殊原因数据错误了，此时需要紧急人工降级
服务降级分类
降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。
按照页面功能可以分为：页面降级、页面片段降级和页面异步请求降级。具体比如渲染商品详情页时需要调用一些不太重要的服务，如相关分类、热销榜等。
爬虫降级：在大促活动时，可以将爬虫流量导向静态页或者返回空数据，从而保护后端稀缺资源。
分级降级：
自动降级可以进一步分为：
- 超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
- 失败次数降级：当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
- 故障降级：网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常等，则可以直接降级服务。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
- 限流降级： 对前端流量进行限制访问，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。
服务降级的处理策略
- 延迟服务：
对于核心的主要逻辑，需要及时处理；对于非核心的逻辑，等服务平稳后再执行。比如文章发表评论，评论内容需要及时展示，但是用户增加积分可以先放入缓存或者MQ，等等服务平稳之后再执行。
- 关闭/拒绝服务
高峰时段拒绝低优先级应用的服务请求，保证核心应用正常工作，也可以随机拒绝请求，直接返回服务器繁忙，避免同时涌入过多的请求。如淘宝每年双11时候都会关闭如评价、确定收货等一些与下单核心业务无关的服务，以保证用户下单支付正常，当然肯定也会使用拒绝服务，0点高峰期很多用户看到的基本是服务器繁忙。
- 页面降级
可视化界面禁用点击按钮、调整静态页面，或者对于页面上的一些异步加载，进行降级处理，比如加载一些商品详情等。
- 写降级：
比如秒杀抢购，可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。
- 读降级：
比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；
服务熔断和服务降级
很多时候容易把服务熔断和服务降级混为一谈，两者实际上是有所差别的。服务熔断一般是指业务系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，采用的一种保护措施，所以很多时候把熔断亦称为过载保护。而服务降级主要是系统整体资源一定的情况下，为优先保证核心业务正常运行，忍痛将某些服务先关掉，高峰过后再恢复出来。
两者都是维护系统的可用性，防止系统的整体缓慢甚至崩溃采用的技术手段，粒度一般也都在服务级别，最终表现也都差不多。但是，两者的区别也很明显：
- 触发原因不同：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
- 管理的目标层次不一样：熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）。
- 实现方式不同：熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段。
服务降价的核心设计
分布式开关设计：
配置中心需要具备的特性：
- 能主动拉取配置
- 能发布订阅配置
- 定时拉取配置
- 离线文件缓存配置
- 可编辑式配置
- telnet命令更改配置
参考资料：