服务降级：
服务压力剧增的时候根据当前的业务状况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行。
同时保证部分甚至大部分任务客户能获得正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。
服务熔断：在股票市场，熔断这个词你们都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采起的暂停交易措施。相应的，服务熔断通常是指软件系统中，因为某些缘由使得服务出现了过载现象，为防止形成整个系统故障，从而采用的一种保护措施，因此不少地方把熔断亦称为过载保护。
降级分类
降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。
自动降级分类
（1）、超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复状况
（2）、失败次数降级：主要是一些不稳定的api，当失败调用次数达到必定阀值自动降级，一样要使用异步机制探测回复状况
（3）、故障降级：好比要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则能够直接降级。降级后的处理方案有：默认值（好比库存服务挂了，返回默认现货）、兜底数据（好比广告挂了，返回提早准备好的一些静态页面）、缓存（以前暂存的一些缓存数据）
（4）、限流降级
当咱们去秒杀或者抢购一些限购商品时，此时可能会由于访问量太大而致使系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案能够是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。
服务熔断和服务降级比较：
二者其实从有些角度看是有必定的相似性的：
- 目的很一致，都是从可用性可靠性着想，为防止系统的总体缓慢甚至崩溃，采用的技术手段；
- 最终表现相似，对于二者来讲，最终让用户体验到的是某些功能暂时不可达或不可用；
- 粒度通常都是服务级别，固然，业界也有很多更细粒度的作法，好比作到数据持久层（容许查询，不容许增删改）；
- 自治性要求很高，熔断模式通常都是服务基于策略的自动触发，降级虽然说可人工干预，但在微服务架构下，彻底靠人显然不可能，开关预置、配置中心都是必要手段；
而二者的区别也是明显的：
- 触发缘由不太同样，服务熔断通常是某个服务（下游服务）故障引发，而服务降级通常是从总体负荷考虑；
- 管理目标的层次不太同样，熔断实际上是一个框架级的处理，每一个微服务都须要（无层级之分），而降级通常须要对业务有层级之分（好比降级通常是从最外围服务开始）
- 实现方式不太同样
服务降级要考虑的问题：
1.核心和非核心服务
2.是否支持降级，降级策略
3.业务放通的场景，策略
Hystrix，该库旨在经过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具有拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包（request collapsing，即自动批处理，译者注），以及监控和配置等功能。
