服务降级和服务熔断的区别_服务熔断和降级

一个分布式应用会依赖多个服务，每个服务可能会存在多个实例，服务依赖的中间件也可能是分布式的，当应用规模足够大，某个节点出现故障的概率也因此增加。在分布式系统中，应把故障当作应用的一部分，我们需要保证当某个节点出现故障时整个应用依然能正常运行，要避免服务雪崩。

服务雪崩：服务雪崩效应是一种因“服务提供者的不可用”(原因)导致“服务调用者不可用”(结果)，并将不可用逐渐放大的现象。为了防止服务雪崩，我们一般采用熔断降级的方式应对。

服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

服务降级：当系统负荷过载或响应慢，舍弃一些非核心业务，缓解系统压力，维持核心业务正常运行，保证整个系统的稳定性和可用性。

咋一看，熔断和降级的到底有啥区别，我个人理解是: 服务降级有很多种降级方式，服务熔断属于降级方式的一种，服务降级是更广泛的方案。

服务降级方式：

• 页面拒绝服务：此服务暂停，页面提示由于服务繁忙。

• 服务接口拒绝服务：只读，对于增删改接口提示服务器繁忙。

• 延迟持久化：页面正常访问，涉及变更将数据记录到异步队列或log，服务恢复后执行。

• 随机拒绝服务：服务接口随机拒绝服务，让用户重试，用户体验不佳。

熔断降级的开源方案：Neflix的Hystrix、阿里巴巴的Sentinel。

Hystrix

Hystrix具备对延迟和故障的容错能力，可以在秒级进行故障降级和熔断，可以对请求自动批处理，以及提供了对应的配置和监控平台。Hystrix通过控制分布式系统中各个服务之间的交互过程来提高分布式系统对错误和延迟的容忍度，让分布式系统更加可靠和稳定。

Hystrix主要功能：断路器(熔断降级)、隔离机制、请求聚合和请求缓存。

• 断路器：提供熔断降级的功能，并收集当前服务对依赖服务的请求结果做统计和计算。

• 隔离机制：Hystrix利用线程池或信号量机制提供依赖服务的隔离。线程池方式每个依赖服务都使用独立的线程池，这样的好处是某一个依赖服务发生故障时，对当前服务的影响会限制在这个线程池内部，不会影响对其他依赖服务的请求，这样的代价是在当前服务中创建了很多线程，需要不小的线程上下文切换的开销，特别是对低延时的调用有比较大的影响。Hystrix使用信号量机制去控制对某个依赖服务的并发访问情况，这样的隔离非常轻量级，不需要显示创建线程池，但是信号量机制无法处理依赖服务的请求响应时间变长的情况。

• 请求聚合：使用HystrixCollapser将前端的多个请求聚合成一个请求发送到后端。

• 请求缓存：Hystrix支持将一个请求结果缓存起来，下一个具有相同key的请求将直接从缓存中取出结果，减少请求开销。利用缓存可以极大的提升性能，但是Hystrix的缓存比较鸡肋。

Hystrix的工作流程：

1. 构建HystrixCommand或HystrixObservableCommand对象，这两个对象用来表示对依赖服务的请求。如果只需要单个返回值，则构建HystrixCommand对象；如果需要多个返回值，则需要构建HystrixObservableCommand对象

2. 有四个方法(execute、queue、observe、toObservable)可以用来执行命令，其中前两个方法只有HystrixCommand提供，HystrixObservableCommand没有这两个方法

3. 检查当前请求是否有缓存，如果有，则直接返回缓存的响应值，如果没有，则执行步骤4

4. 检查断路器状态，如果断路器打开，则尝试执行fallback逻辑，即步骤8；如果断路器未打开，则执行步骤5

5. 检查线程池是否满，或者信号量是否用完，如果用完，则拒绝服务，尝试fallback逻辑，即步骤8；如果线程池或信号量可用，则执行步骤6

6. 通过construce()或run()方法发起对依赖服务的调用。如果执行失败或超时，则执行步骤8，如果没有失败，也没有超时，则可以在执行时间内返回结果

7. 每次发起对依赖服务的调用，Hystrix都会对执行结果进行收集和统计，用来改变断路器或线程池(信号量)的状态

8. fallback逻辑是我们预先设置好的备用服务或默认值，如果fallback逻辑执行失败，则本次请求失败，否则成功返回结果

Sentinel

Sentinel是面向分布式服务架构的轻量级流量控制框架、主要以流量为切入点。从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。

Sentinel主要概念：

• 资源：资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

• 规则：围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

Sentinel主要功能：流量控制、熔断降级、系统负载保护。

• 流量控制:流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

• 熔断降级：Sentinel的熔断降级功能和Hystrix要解决的问题及设计原则是一致的，就是在分布式系统中某个依赖服务出现问题的时候，不要让问题蔓延到整个系统。但是Sentinel的设计思路和Hystrix不同，它采取了两种手段来实现这个目标——限制并发线程；通过响应时间对资源访问进行降级。

• 系统过载保护：当系统负载过高的时候，如果还持续让请求进入。则可能导致系统崩溃、无法响应。Sentinel提供了对应的保护机制，把系统处理请求的过程想象为一个水管，让系统的入口流量和系统的负载达到平衡，保证系统在能力范围之内处理更多请求。

Hystrix和Sentinel的对比

Hystrix和Sentinel的设计目标、要解决的问题是一致的：按照系统性、工程化思路来管理分布式系统有的可靠性，通过管理分布式系统中服务中间的调用关系来提升分布式系统的可靠性。

共同特性

• 隔离机制:二者都提供了隔离机制，Hystrix通过线程池或信号量来实现隔离机制，针对某个依赖服务的请求，全部会在一个线程池内部管理，信号量更轻量级些:Sentinel的隔离机制更轻量级，支持通过不同的运行指标进行限流，例如通过控制OPS、 系统负载、调用关系。

• 熔断降级: Sentinel 与Hystrix都支持基于失败比率(异常比率)的熔断降级，在调用达到一定量级并且失败比率达到设定的阈值时自动进行熔断，此时所有对该资源的调用都会被阻塞，直到过了指定的时间窗口后才启发性地恢复。Sentinel 还支持基于平均响应时间的熔断降级，可以在服务响应时间持续飙高的时候自动熔断，拒绝更多的请求，直到一段时间后才恢复。Hystrix除了会统计请求的失败比例，还会统计请求的超时次数，从这个角度看，Hystrix 也提供了基于响应时间的隔断机制。

• 实时指标: Hstitx的实时指标计算使用RxJava的事件响应机制来实现。Sentinel的实时指标计算是通过LeapArray来实现的，不过，二者使用的算法都是滑动窗口算法。

Hystrix的特性

• 请求聚合和缓存: Hystrix提供了请求聚合和请求缓存功能，从一定程度上实现了整形的功能。

Sentinel的特性

• 流量控制: Sentinel 可以针对不同的调用关系，以不同的运行指标(如QPS、并发调用数、系统负载等)为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。从对流量控制的角度说，Sentinel 是优于Hystrix的。

• 系统负载保护: Sentinel 还提供了集群维度的系统负载保护功能，在系统的入口处对流量进行管理，如果系统的服务能力降低，则相应地限制能够提供的服务，从而保护系统不被流量“打挂”。

此外服务降级最常用的方式是配置降级，主要分为：直觉管理和分级管理。

• 直觉管理：运维人员可以指定哪些模块降级，当服务器检测到压力增大，服务器监测自动发送通知给运维人员，运维人员根据自己或相关人员判断后通过配置平台设置当前运行等级来降级。

• 分级管理：运维人员无需关心业务细节，直接按级别降低即可。当服务器检测到压力增大，服务检测自动发送通知给运维人员。运维人员根据情况选择运行等级1~10。各个应用根据自己的级别自动判断是否工作，如何拒绝。