服务降级是指当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理，或者以简单的方式处理，从而释放服务器资源保障核心业务正常运作或高效运作，简而言之:就是尽可能的把系统资源让给优先级高的服务。使用场景:当服务器压力剧增时，根据实际业务情况及流量，对一些不重要的、不紧要的服务进行有策略地不处理或者简单处理，从而释放服务器资源以保障核心业务正常运作。当某些服务不可用时，为了避免长时间服务卡顿或者引起雪崩效应，而主动执性备用的降级逻辑立刻返回一个有好多提示，以保证主体业务不受影响。实现:通过重写HystrixCommand的getFallBack()方法或HystrixObservableCommand的resumeWithFallback()方法，使服务支持服务降级。某一时间段内服务A的访问量保证，而B和C的访问量较少或者访问量几乎没有，为了缓解A服务的压力，这时候把B和C的服务功能暂时关闭，释放服务资源去承担A的部分服务，重而分担了A的压力，提高了性能，叫做服务降级。

1.服务熔断–>服务端：某个服务超时或异常，引起熔断。2.服务降级–>服务端:从整体网站考虑，当某个服务熔断或关闭之后，服务不再调用，此时客户端实现了FallBackFactory的类，返回一个用户指示信息，但会导致整体服务水平下降，但提高了可靠性。3.触发原因不同。服务熔断一般是某个服务故障引起的，而服务降级是从整体负荷考虑，管理目标层次不太一样，熔断起始是一个框架处理，每个微服务都需要，而降级一般需要对业务有层级之分。4.实现方式不一样。服务降级具有代码入侵性(由控制器完成/或自动降级)，熔断一般称为自我熔断。 

服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

从微服务架构全局的视角来看，我们通常有以下是几种常用的降级处理方案：页面降级——可视化界面禁用点击按钮、调整静态页面延迟服务——如定时任务延迟处理、消息入MQ后延迟处理写降级——直接禁止相关写操作的服务请求读降级——直接禁止相关度的服务请求缓存降级——使用缓存方式来降级部分读频繁的服务接口针对后端代码层面的降级处理策略，则我们通常使用以下几种处理措施进行降级处理：抛异常返回NULL调用Mock数据调用Fallback处理逻辑

在分布式系统中不可避免的会出现服务之间调用异常，一个接口的异常可能导致整个链路异常，服务熔断就是防止这种级联故障的发生，是异常服务快速返回备用数据，顺利完成调用。