概述
对于在外工作的小伙伴，或多或少都经历过12306抢票，高峰时候明明还有票可是查询列表为空,等高峰一过列表又正常了。后台可能采用了服务降级处理,在高峰时候并没有将错误信息返回给用户,而是返回了一个空的列表。
服务降级
当服务器压力剧增的时候,根据当前业务情况以及流量，对一些服务和页面有策略的降级，以此缓解服务器资源的压力以保障核心任务的正常运行，同时也保证了大部分客户能得到正常的响应。
- 服务接口拒绝服务：页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
- 页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
- 延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
-
随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。
降级与熔断.png
在一般稍微大一点的互联网公司基本上都会有一个配置中心的角色,通常由配置服务和代理和应用程序组成，Agent会定期的或者实时的接受配置中心的变更，将配置信息写入本地文件。此时SDK会同步代理的配置以达到同步配置中心的数据。当然也可以没有Agent这一角色，SDK直接监听配置中心的变更。
拥有了这一架构之后,对于每个应用程序的请求或者数据库都可以通过配置中心来进行降级与切换。当然了如果目前所处环境没有这一条件也可以使用单纯的DB来保存 key-value来简易实现这一功能。
服务熔断(过载保护)
对于炒股的同学，熔断这个词可能并不陌生，它是指当某一股值波浮达到某一个点后交易所为了控制风险，采取一些暂停交易的措施。响应的如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
三个模块：熔断请求判断算法、熔断恢复机制、熔断报警
（1）熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
（2）熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
（3）熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警
降级与熔断对比
共性
- 目的: 目的一致，都是从系统的可用性、可靠性着想。放了防止系统的整体缓慢甚至奔溃而采用的技术手段。
- 最终表现: 表现类似,最终都是给用户一种当前服务不可用或者不可达的感觉
- 粒度: 大多都是在服务级别，当然也有一些在持久层层面的应用
- 自治: 基本都是靠系统达到某一临界条件时，实现自动的降级与熔断，人工降级并不是那么稳妥。
区别
- 触发原因: 服务熔断一般指某个服务的下游服务出现问题时采用的手段,而服务降级一般是从整体层面考虑的。
- 管理目标层次: 熔断是一种框架级的处理，每一个微服务都需要。而降级一般需要对业务有层级之分，降级一般都是从外围服务开始的。
- 实现方式: 代码级别实现有差异
服务降级需要考虑的问题
- 核心服务、非核心服务
- 是否支持降级，降级策略
- 业务放通场景、策略
