服务熔断的具体表现形式是熔断器。那么,熔断器的基本结构是怎么样的?它又是如何实现的呢?
问题背景
熔断(Circuit Breaker)是很实用的一种容错机制。一方面在于熔断机制非常重要,另一方面也可以通过这个问题很好地区分候选人的知识广度和深度。
从面试角度讲,关于熔断机制有很多种具体的问法,面试官往往会采用这样的方式来考查候选人:
- 熔断器的状态有哪些?相互之间是如何转换的?
- 在系统运行时,如何有效地收集和统计运行时数据?
- 你使用过的熔断器有哪些?它的基本原理是怎么样的?
- 如果让你来设计并实现一个简单的熔断机制,你会怎么做?
上述问题虽然各有侧重点,但对于熔断机制而言,考查的重点还是候选人在工程实践的基础上所掌握的技术原理。
问题分析
服务熔断-阈值
通过上述分析,我们可以梳理出如下技术上的要点。
- 状态性:通过合理的状态切换来控制是否对请求进行熔断。
- 运行时数据:收集服务运行时数据并进行统计分析,为阈值判断提供依据。
- 阈值控制:各个状态切换的控制开关。
通过对上述要点的分析,这道题的回答思路就有了,而回答好这道题的关键就是要对上述要点背后的技术原理进行系统的阐述。接下来,让我们来对具体的技术体系展开讨论。
技术体系
基于熔断器的设计理念,我们对熔断过程进行进行抽象和提炼,可以得到如下图所示的熔断器基本结构。
可以看到,该状态机包含三个状态,即 Closed(关闭)、Open(打开)和 Half-Open(半开)。
- Closed。这是熔断器的默认状态。
- 在该状态下,相当于熔断器没有发挥任何效果,所有的请求可以得到正常的响应。
- 但是,在熔断器内部还是会对所有的调用过程进行监控,如果有异常发生则会进行不断累加。
- Open。这是熔断器的打开状态。
- 在该状态下,相当于熔断器对所有的请求进行了隔断,来自服务消费者的请求不会触达到服务的提供者。
- 同时,在熔断器内部也会启动一个计时器,当处于该状态达到一定时间时,熔断器会进入到半开状态。
- Half-Open。这是熔断器的半开状态。
- 所谓半开,指的是熔断器会允许一部分请求通过,然后再对这些请求的响应结果进行统计。
- 如果这些请求的成功比例达到一定的阈值,则会把熔断器设回到关闭状态,反之则进入打开状态。
我们讨论如何自己实现一个包含这三个状态的熔断器。
首先,我们需要定义一个枚举类 State,代码如下:
1 | public enum State { |
然后,我们定义代表熔断器的 CircuitBreaker 接口,如下所示:
1 | public interface CircuitBreaker { |
对于 CircuitBreaker
接口的实现过程是我们讨论的重点。为了实现对熔断器状态的合理控制,我们首先需要定义一系列的中间变量,如下所示:
1 | //远程调用的超时时间 |
当我们发起一个远程调用时,我们需要基于调用结果合理设置熔断器的状态,代码如下所示:
1 | public String attemptRequest() throws RemoteServiceException { |
我们继续来实现当调用成功和失败时,对应的 recordSuccess 和 recordFailure 方法的执行逻辑,代码如下所示:
1 | //调用成功,失败次数清零,最近失败时间设置成无限大,并把熔断器状态设置成关闭 |
当系统运行一段时间之后,我们如何来获取熔断器的当前状态呢?可以实现如下所示的 getState 方法:
1 | public String getState() { |
对应的,如果我们想要直接对熔断器状态进行设置,可以使用如下所示的 setState 方法:
1 | public void setState(State state) { |
可以看到,这里我们也只是通过对熔断器的几个核心变量设置合适的值来更新熔断器的最新状态。
以上代码示例可以帮助你更好地理解一个熔断器的内部实现原理,也可以帮助你回答类似“如果让你来实现一个简单的熔断机制,你会怎么做?”这种开放式问题。
但是,这个毕竟只是一个示例。要想完整理解熔断器的实现过程,还是需要我们来对主流分布式服务框架中的原理展开解析。
源码解析
在 Spring Cloud 中,专门为开发人员提供了具备服务熔断功能的Spring Cloud Circuit Breaker 组件。
从命名上看,Spring Cloud Circuit Breaker 是对熔断器的一种抽象,支持不同的熔断器实现方案。在 Spring Cloud Circuit Breaker 中,内置了四种熔断器,如下图所示:
上图中的
- Netflix Hystrix 显然来自于 Netflix OSS
- Resilience4j 是受 Hystrix 项目启发所诞生的一款新型的容错库
- Sentinel 从定位上讲是一款包含了熔断降级功能的高可用流量防护组件
- Spring Retry 是 Spring 自研的重试和熔断框架
针对以上四种熔断器,Spring Cloud Circuit Breaker 提供了统一的 API。
Spring Cloud Circuit Breaker 组成结构
为了在应用程序中创建一个熔断器,我们可以使用 Spring Cloud Circuit Breaker 中的工厂类 CircuitBreakerFactory
,该工厂类的定义如下:
1 | public abstract class CircuitBreakerFactory<CONF, CONFB extends ConfigBuilder<CONF>> extends AbstractCircuitBreakerFactory<CONF, CONFB> { |
可以看到这是一个抽象类,只有一个 create
方法用来创建 CircuitBreaker
。CircuitBreaker
是一个接口,约定了熔断器应该具有的功能,该接口定义如下所示:
1 | public interface CircuitBreaker { |
这里用到了函数式编程的一些语法,但我们从方法定义上还是可以明显看出包含了 run
和 fallback
这两个方法。其中的 Supplier
包含了你希望运行在熔断器中的业务代码,而 Function
则代表着回退(Fallback)方法。如果你熟悉 Netflix Hystrix
中的 HystrixCommand
,你会发现两者之间存在明显的对应关系。
在 Spring Cloud Circuit Breaker 中,分别针对 Hystrix、Resilience4j、Sentinel 和 Spring Retry 这四款框架提供了 CircuitBreakerFactory
抽象类的子类。
一旦在代码工程的类路径中添加了相关的 starter
,系统就会自动创建 CircuitBreaker
。也就是说 CircuitBreakerFactory.create
方法会实例化对应框架的一个 CircuitBreaker
实例。
在引入具体的开发框架之后,下一步工作就是对它们进行配置。在 CircuitBreakerFactory
的父类 AbstractCircuitBreakerFactory
中,我们发现了如下所示的两个抽象方法:
1 | //针对某一个id创建配置构造器 |
这里用到了大量的泛型定义,我们可以猜想,在这两个抽象方法的背后,Spring Cloud Circuit Breaker 会针对不同的第三方框架提供不同的配置实现过程。我们在接下来的内容中会基于具体的框架对这一过程做展开讨论。
让我们来到 Hystrix 框架,来看看在 Spring Cloud Circuit Breaker 中是如何使用统一编程模式完成对该框架的集成。我们首先关注实现了 CircuitBreaker
接口的 HystrixCircuitBreaker
类,如下所示:
1 | public class HystrixCircuitBreaker implements CircuitBreaker { |
不难想象,这里应该构建了一个 HystrixCommand
对象,并在该对象原有的 run
和 getFallback
方法中封装了 CircuitBreaker
中的统一方法调用,而最终实现熔断操作的还是 Hystrix 原生的 HystrixCommand
。
然后,我们接着来看 HystrixCircuitBreakerFactory
,这个类的实现过程也简洁明了,如下所示:
1 | public class HystrixCircuitBreakerFactory extends CircuitBreakerFactory<HystrixCommand.Setter, HystrixCircuitBreakerFactory.HystrixConfigBuilder> { |
上述代码基本就是对原有 HystrixCommand
中关于服务分组等属性的简单封装,你可以结合接下来要介绍的 Hystrix
框架熔断机制内容做进一步理解。
Hystrix 熔断机制
在 Hystrix 中,最核心的就是 HystrixCircuitBreaker
接口,该接口代表了对熔断器的抽象过程,如下所示:
1 | public interface HystrixCircuitBreaker { |
可以看到 HystrixCircuitBreaker
接口只有三个方法。在 Hystrix 中,该接口的实现类是 HystrixCircuitBreakerImpl
。
我们首先来看最重要的 allowRequest
方法,该方法用来判断每个请求是否可被执行。allowRequest
实际上是对 isOpen
方法做了一层封装,在通过调用 isOpen
来触发熔断器的计算逻辑之前,先根据 HystrixCommandProperties
中的配置信息来判断是否强制开启熔断器,具体实现如下所示:
1 | public boolean allowRequest() { |
接下来的 isOpen()
方法用来获取熔断器的当前状态。请注意,熔断器中关于阈值判断的一系列处理逻辑都位于该方法中,如下所示:
1 | public boolean isOpen() { |
最后,我们来到用来关闭熔断器的 markSuccess
方法。显然,该方法在熔断器处于半开状态下进行使用,我们可以通过该方法将熔断器设置为关闭状态。
这时候,熔断器要做的一件事情就是重置对请求的统计指标,如下所示:
1 | public void markSuccess() { |
HystrixCircuitBreaker
接口的这三个方法的执行逻辑实际上都不复杂,HystrixCircuitBreaker
通过一个 circuitOpen
状态位控制着整个熔断判断流程,而这个状态位本身的状态值则取决于系统目前的运行时数据。
解题要点
从解题思路上讲,目前业界主流的熔断器实现模型基本都是类似的。就知识体系而言,要注意的是在熔断器内部实现过程中,并不是只有熔断和非熔断这两个简单状态,而是会引入一个半熔断的状态,通过对当前服务所处理请求的情况进行统计分析,熔断器会基于一定的阈值动态完成这些状态之间的自动切换。
另一方面,面试官在考查候选人能力的一大关注点还是实践能力,所以可以结合具体工具的使用过程来阐述熔断器的核心概念。