服务降级
服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此缓解服务器的压力，以保证核心任务的进行。
方案：
服务接口拒绝服务：页面能访问，但是添加删除提示服务器繁忙。页面内容也可在 Varnish 或 CDN 内获取。
页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到 varnish 或 nginx 的一个静态页面。
延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到 异步队列 或 log ，服务恢复后执行。
随机拒绝服务：服务 接口随机 拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。
服务熔断
如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
熔断设计：
熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护 10 个 bucket，每 1 秒一个 bucket，每个 blucket 记录请求的成功、失败、超时、拒绝的状态，默认错误超过 50%且 10 秒内超过 20 个请求进行中断拦截。
熔断恢复：对于被熔断的请求，每隔 5s 允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警
熔断和降级的区别
首先我们总结以下：
- 降级的目的是为了解决整体项目的压力，而牺牲掉某一服务模块而采取的措施。
- 熔断的目的是当 A 服务模块中的某块程序出现故障后为了不影响其他客户端的请求而做出的及时回应。
相同点
目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段 ；
区别
触发原因不太一样， 服务降级一般是从整体负荷考虑，而服务熔断一般是某个服务（下游服务）故障引起 ；
管理目标的层次不太一样， 降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）；熔断 其实是一个框架级的处理，每个微服务都需要（无层级之分）。