服务熔断与降级

服务熔断与降级

在开始本篇的话题之前，我们先看两个现实中的真实案例：

• 银行排队办业务

在某个小乡镇的某个银行柜台，只有一个窗口办理业务，后边很多人在排队，业务办理很慢，突然间办理业务的电脑坏了、或者说工作人员午休或下班了，后边排队等待办理业务的并不知道前边什么情况，可能会继续排队。

• 年货礼盒活动

小明家开了两个门店，一个卖衣服，一个卖副食类，都有员工若干，年底了小明进了很多礼盒，并且销售量很可观，这时候小明把卖衣服的门店关掉，并且把里边的工作人员调到副食门店卖礼盒。

背景分析

对于上述两个案例，我们可以结合到软件开发场景中，做一下简要的分析：

1：银行排队办业务

对于案例一中的银行排队办业务场景，我们可以把窗口及工作人员抽象成服务提供者，而后边排队的人是一个个消费者请求，服务突然中断或者崩溃，正在排队等待的请求并没有感知，导致请求继续等待并且不释放资源。

对于这场景下，总结出大概一下几个问题：

• 服务端故障未上报

服务端出现故障后没有及时反馈给监控或者消费端，当然如果机器直接挂掉的话是无法上报给消费端。

• 消费端未做故障熔断和隔离

对于服务端的突然崩溃，消费端没有一种充当监控的角色，对于发现的故障进行服务熔断和隔离以及上报。

• 没有一个全局的监控

排队的人对应是消费端请求，而排队的人各种各样，请求也是五花八门，可能来自多个不同的应用，那么对于服务崩溃需要各个消费端自己做服务熔断和隔离。

2：年货礼盒活动

而对于案例二中的礼盒互动，我们可以理解成电商平台同一个应用下的两个服务，A服务在大促期间有个服务流量会暴涨，另外一个B服务可能没什么量或者非核心业务，那么为了保证A服务的稳定性，大促期间会主动降级B服务，将应用的核心资源都用来支持A服务。

通过案例二场景，我们有几个点需要明确一下：

• 核心链路&非核心链路

在同一时刻，如果核心链路需要大量资源支撑，那么会放弃非核心链路，简单来说就是关停。

• 资源支持

同一个应用中，每个服务是平等的，请求过来后都会创建线程，开辟内存空间，占用带宽，那么高并发场景下，这些资源对核心业务尤其重要。

接下来我们将详细介绍本篇的主题 服务熔断与降级。

概念

服务熔断

这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，

可以暂时切断对下游服务的调用。

一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。

很多时候刚开始可能只是系统出现了局部的、小规模的故障，然而由于种种原因，故障影响的范围越来越大，最终导致了全局性的后果。其实是一种丢车保帅的做法。

服务降级

什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。举个例子，在天猫双十一期间，由于交易量剧增，为了保证系统稳定性，会把一些非核心功能降级，比如统计、绩效等。

服务熔断和服务降级异同

相似性

• 目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
• 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
• 粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
• 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

差异性

• 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
• 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
• 实现方式不太一样

目标

服务熔断和降级的目的都是为了保护应用，使应用不会因为外界突发流量或者下游依赖不稳定导致当前应用崩溃，主要是提供一种优雅的容错隔离机制。

• 平缓应对流量突发
• 放弃非核心业务保全核心链路
• 系统容错与故障隔离

实现原理分析

1：服务熔断

正常情况下的服务：

某一服务出现异常，拖垮整个服务链路，消耗整个线程队列，造成服务不可用，资源耗尽：

形成过程：

服务提供者不可用

• a）硬件故障：硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问
• b）程序Bug:
• c) 缓存击穿：缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用
• d）用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用

重试加大流量压力

• a）用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单
• b）代码逻辑重试: 服务调用端的会存在大量服务异常后的重试逻辑

服务调用者不可用

• a）同步等待造成的资源耗尽：当服务调用者使用同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

实现原理

• 服务调用隔离

消费者不直接调用服务提供方，中间加一层隔离层，隔离层可引入框架也可自己实现。

• 服务熔断及策略

对于超时、崩溃或者报错的服务调用，通过隔离层做频次记录，根据制定的策略进行故障隔离，比如超时超过10次以上就熔断服务，抑或者对于熔断的服务指定时间后尝试再次访问等等。

简单来说，服务熔断的原理就是 调用隔离->监控->熔断。

2：服务降级

而服务降级的实现原理和思想相对熔断要简单一些，只需要在突发流量时间点之前把非核心业务关停。

正常情况下核心服务与非核心服务关系如下：

而流量突发情况下，核心服务与非核心服务关系会变成这样：

会把非核心服务B关停降级，将资源集中到服务A处理业务。

实现原理：

• 降级开关

在服务调用成增加降级开关，如果开关是关闭的，那么就终止本次调用，需要注意的是在集群环境要支持同一控制。

• 预案平台

一般预案平台是大公司才会有，比如阿里集团很多BU会在双十一前通过预案平台降级非核心链路服务。

常见解决方案

1：hystrix

Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现，用于高微服务架构的可用性，是防止服务出现雪崩的利器。目前Hystrix已经停止更新。

2：Sentinel

Sentinel 是阿里巴巴开源的一款断路器实现，目前在Spring Cloud的孵化器项目Spring Cloud Alibaba中，预计Spring Cloud H系列中可以孵化完成。尽管Sentinel尚未在Spring Cloud项目中孵化完成，但Sentinel本身在阿里内部已经被大规模采用，非常稳定。因此可以作为一个较好的替代品。

3：Resilience4J

Resilicence4J 在2018年7月进入大家视野，非常轻量、简单，并且文档非常清晰、丰富。未来发展前景比较好，也是Hystrix官方推荐的替代产品。

不仅如此，Resilicence4j还原生支持Spring Boot 1.x/2.x，而且监控也不像Hystrix一样弄Dashboard/Hystrix等一堆轮子，而是支持和Micrometer（Pivotal开源的监控门面，Spring Boot 2.x中的Actuator就是基于Micrometer的）、prometheus（开源监控系统，来自谷歌的论文）、以及Dropwizard metrics（Spring Boot曾经的模仿对象，类似于Spring Boot）进行整合。

4：自己实现

如果公司或者团队有精力和能力，可以在开源的基础上实现一套对自己业务定制的熔断降级框架。