前言

1. 问题产生

2. 形成过程

2. 服务熔断和服务降级区别

2.1 服务降级:系统有限的资源的合理协调

2.2 服务熔断：应对雪崩效应的链路自我保护机制。可看作降级的特殊情况

2.3 服务降级和服务熔断区别

3. 工作原理

4. 流程

5. 执行方式

6. 代码实现

前言

在配电系统和用电设备中，熔断器是当电流超过规定值一段时间后，以其自身产生的热量使熔体熔化，从而使电路断开，它的作用是为了对电路进行保护。

在股市中熔断机制，也叫自动停盘机制，是指当股指波幅达到规定的熔断点时，交易所为控制风险采取的暂停交易措施，其作用同样是避免金融交易产品价格波动过度，给市场一定时间的冷静期，向投资者警示风险，并为有关方面采取相关的风险控制手段和措施赢得时间和机会。

同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

1. 问题产生

雪崩效应：是一种因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程。

正常情况下的服务：

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

2. 形成过程

1）服务提供者不可用

a）硬件故障：硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问

b）程序Bug:

c) 缓存击穿：缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用

d）用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用

2）重试加大流量

a）用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单

b）代码逻辑重试: 服务调用端的会存在大量服务异常后的重试逻辑

3）服务调用者不可用

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

2. 服务熔断和服务降级区别

2.1 服务降级:系统有限的资源的合理协调

概念：服务降级一般是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而释放服务器资源的资源以保证核心业务的正常高效运行。
原因：服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大
应用场景：多用于微服务架构中，一般当整个微服务架构整体的负载超出了预设的上限阈值（和服务器的配置性能有关系），或者即将到来的流量预计会超过预设的阈值时（比如双11、6.18等活动或者秒杀活动）
服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
需要考虑的问题：
- 区分那些服务为核心？那些非核心
- 降级策略（处理方式，一般指如何给用户友好的提示或者操作）
- 自动降级还是手动降

2.2 服务熔断：应对雪崩效应的链路自我保护机制。可看作降级的特殊情况

概念：应对微服务雪崩效应的一种链路保护机制，类似股市、保险丝
原因：微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务c，某一时间链路上对服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应
服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。

-应用场景：微服务架构中，多个微服务相互调用出使用

需要考虑问题：
- 如何所依赖的服务对象不稳定
- 失败之后如何快速恢复依赖对象，如何探知依赖对象是否恢复

2.3 服务降级和服务熔断区别

触发原因不一样，服务熔断由链路上某个服务引起的，服务降级是从整体的负载考虑
管理目标层次不一样，服务熔断是一个框架层次的处理，服务降级是业务层次的处理
实现方式不一样，服务熔断一般是自我熔断恢复，服务降级相当于人工控制
触发原因不同服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

一句话：

服务熔断是应对系统服务雪崩的一种保险措施，给出的一种特殊降级措施。而服务降级则是更加宽泛的概念，主要是对系统整体资源的合理分配以应对压力。

服务熔断是服务降级的一种特殊情况，他是防止服务雪崩而采取的措施。系统发生异常或者延迟或者流量太大，都会触发该服务的服务熔断措施，链路熔断，返回兜底方法。这是对局部的一种保险措施。

服务降级是对系统整体资源的合理分配。区分核心服务和非核心服务。对某个服务的访问延迟时间、异常等情况做出预估并给出兜底方法。这是一种全局性的考量，对系统整体负荷进行管理。

限流：限制并发的请求访问量，超过阈值则拒绝；

降级：服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；

熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统自动执行和恢复

3. 工作原理

Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力。Netflix的众多开源项目之一。

1. 隔离：

Hystrix隔离方式采用线程/信号的方式，通过隔离限制依赖的并发量和阻塞扩散

1)线程隔离

Hystrix在用户请求和服务之间加入了线程池。

Hystrix为每个依赖调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。线程数是可以被设定的。

原理：用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少可以看到一个执行结果（例如返回友好的提示信息），而不是无休止的等待或者看到系统崩溃。

隔离前：

隔离后：

b）信号隔离：

信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请, 如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销。信号量的大小可以动态调整, 线程池大小不可以。（参考文章2）

2. 熔断：

如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

熔断器:Circuit Breaker

熔断器是位于线程池之前的组件。用户请求某一服务之后，Hystrix会先经过熔断器，此时如果熔断器的状态是打开（跳起），则说明已经熔断，这时将直接进行降级处理，不会继续将请求发到线程池。熔断器相当于在线程池之前的一层屏障。每个熔断器默认维护10个bucket ，每秒创建一个bucket ，每个blucket记录成功,失败,超时,拒绝的次数。当有新的bucket被创建时，最旧的bucket会被抛弃。

熔断器的状态机：

Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制；
Open：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），到了这个时间，进入半熔断状态；
Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态；

4. 流程

流程说明:

1:每次调用创建一个新的HystrixCommand，把依赖调用封装在run()方法中。

2:执行execute()/queue做同步或异步调用。

3:判断熔断器(circuit-breaker)是否打开，如果打开跳到步骤8，进行降级策略，如果关闭进入步骤。

4:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8，否则继续后续步骤。

5:调用HystrixCommand的run方法。运行依赖逻辑

5a:依赖逻辑调用超时，进入步骤8。

6:判断逻辑是否调用成功

6a:返回成功调用结果

6b:调用出错，进入步骤8。

7:计算熔断器状态，所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态。

8:getFallback()降级逻辑。

以下四种情况将触发getFallback调用：

(1)：run()方法抛出非HystrixBadRequestException异常

(2)：run()方法调用超时

(3)：熔断器开启拦截调用

(4)：线程池/队列/信号量是否跑满

8a:没有实现getFallback的Command将直接抛出异常

8b:fallback降级逻辑调用成功直接返回

8c:降级逻辑调用失败抛出异常

9:返回执行成功结果

5. 执行方式

同步执行：即一旦开始执行该命令，当前线程就得阻塞着直到该命令返回结果，然后才能继续执行下面的逻辑

异步执行：命令开始执行会返回一个Future<T>的对象，不阻塞后面的逻辑，开发者自己根据需要去获取结果。

响应式执行：命令开始执行会返回一个Observable<T> 对象，开发者可以给给Obeservable对象注册上Observer或者Action1对象，响应式地处理命令执行过程中的不同阶段。当调用HystrixCommand的observe()方法，或使用Observable的工厂方法（just(),from()）即为响应式执行，这个功能的实现是基于Netflix的另一个开源项目RxJava（https://github.com/Netflix/RxJava）来的，更细节的用法可以参考：How To Use · Netflix/Hystrix Wiki · GitHub。

6. 代码实现

jar包：

hystrix包

<dependency>

<groupId>com.netflix.hystrix</groupId>

<artifactId>hystrix-core</artifactId>

<version>1.4.21</version>

</dependency>

设置参数 展开原码

参数	作用	备注
circuitBreaker.errorThresholdPercentage	失败率达到多少百分比后熔断	默认值：50 主要根据依赖重要性进行调整
circuitBreaker.forceClosed	是否强制关闭熔断	如果是强依赖，应该设置为true
circuitBreaker.requestVolumeThreshold	熔断触发的最小个数/10s	默认值：20
circuitBreaker.sleepWindowInMilliseconds	熔断多少秒后去尝试请求	默认值：5000
commandKey		默认值：当前执行方法名
coreSize	线程池coreSize	默认值：10
execution.isolation.semaphore.maxConcurrentRequests	信号量最大并发度	SEMAPHORE模式有效，默认值：10
execution.isolation.strategy	隔离策略，有THREAD和SEMAPHORE	默认使用THREAD模式，以下几种可以使用SEMAPHORE模式：只想控制并发度外部的方法已经做了线程隔离调用的是本地方法或者可靠度非常高、耗时特别小的方法（如medis）
execution.isolation.thread.interruptOnTimeout	是否打开超时线程中断	THREAD模式有效
execution.isolation.thread.timeoutInMilliseconds	超时时间	默认值：1000 在THREAD模式下，达到超时时间，可以中断在SEMAPHORE模式下，会等待执行完成后，再去判断是否超时
execution.timeout.enabled	是否打开超时
fallback.isolation.semaphore.maxConcurrentRequests	fallback最大并发度	默认值：10
groupKey	表示所属的group，一个group共用线程池	默认值：getClass().getSimpleName();
maxQueueSize	请求等待队列	默认值：-1 如果使用正数，队列将从SynchronizeQueue改为LinkedBlockingQueue
hystrix.command.default.metrics.rollingStats.timeInMilliseconds	设置统计的时间窗口值的，毫秒值	circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒，则rolling window会被分成n个buckets，每个bucket包含success，failure，timeout，rejection的次数的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets	设置一个rolling window被划分的数量
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds	记录health 快照（用来统计成功和错误绿）的间隔，默认500ms

有兴趣可以关注我的微信公众号“自动化测试全栈”，微信号：QAlife，学习更多自动化测试技术。

也可加入我们的自动化测试技术交流群，QQ群号码:301079813；Jmeter/Loadrunner性能测试交流群QQ群：541897224

主要探讨loadrunner/JMeter测试、Selenium/RobotFramework/Appium自动化测试、接口自动化测试，测试工具等测试技术，让我们来这里分享经验、交流技术、结交朋友、拓展视野、一起奋斗！

分布式系统熔断机制的工作原理相关推荐

哨兵 (sentinal) 机制的工作原理
哨兵 (sentinal) 机制的工作原理什么是哨兵机制? Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务: 监控(Monitori ...
Android开发：图文分析 Handler通信机制的工作原理
前言在Android开发的多线程应用场景中,Handler机制十分常用下面,将图文详解 Handler机制的工作原理目录 1. 定义一套 Android 消息传递机制 2. 作用在多线程的 ...
理解并取证：以太通道的动态协商机制的工作原理
理解并取证:以太通道的动态协商机制的工作原理取自博主<思科CCNP交换技术详解与实验指南>试读版 3.1理解以太通道的理论部分 3.1.1提出以太通道的原因.以太通道的作用和功能 3.1 ...
Springboot事件监听机制：工作原理
目录前言 1.观察者模式 1.1观察者模式的核心元素 1.2观察者模式的工作流程 2.springboot事件监听机制的基本工作原理 2.1事件发布器是什么时候在哪里产生的呢? 2.2事件监听器是什 ...
php的工作原理,PHP的运行机制和工作原理的内容
这篇文章给大家介绍的内容是关于PHP的运行机制和工作原理的内容,有着一定的参考价值,有需要的朋友可以参考一下. 一.PHP设计理念及特点多进程模型:由于PHP是多进程模型,不同请求间互不干涉,这样保 ...
redis哨兵模式原理_Redis的哨兵 (sentinal) 机制的工作原理
什么是哨兵机制? Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务: 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Mas ...
java中的熔断机制_微服务熔断机制与Hystrix原理
微服务是由多个子系统构成的系统,每个子系统分别负责自己的业务,各个服务之间通过HTTP请求进行通讯,所以保证每个服务的可用性是整体可用性的前提,因此在一些服务提供者不可用的情况下,导致大量请求阻塞到此 ...
【学习周报】注意力机制的工作原理和主流方法。
学习目标深度学习Attention模型深度学习花书第16章学习内容 Attention模型和机制.基本思想. 花书结构化概率模型学习时间 9.5 ~ 9.10 深度学习Attention模型 ...
SpringCloud进阶-Hystrix的熔断机制+Hystrix的工作流程
提示:本文主要对SpringCloud中的Hystrix的熔断机制和工作流程进行总结文章目录前言一.简介 1.熔断是什么二.实操 1.实现 2.测试三.总结 1.大神结论 2.熔断类型 3. ...

分布式系统熔断机制的工作原理

前言

1. 问题产生

2. 形成过程

2. 服务熔断和服务降级区别

2.1 服务降级:系统有限的资源的合理协调

2.2 服务熔断：应对雪崩效应的链路自我保护机制。可看作降级的特殊情况

2.3 服务降级和服务熔断区别

3. 工作原理

4. 流程

5. 执行方式

6. 代码实现

分布式系统熔断机制的工作原理相关推荐

最新文章

热门文章