springcloud学习手册-Hystrix(服务容错保护)

导读 | Hystrix 服务容错保护 的概念和说明

大家看到这个图,千万可不要害怕啊!大家都知道这是什么吗? 这就是大名鼎鼎的:豪猪

豪猪的英文就是:Hystrix,国外一些大牛的程序员在给自己的架构起名字的时候,往往就这么特别。哪天咱们中国人自己也能写出些架构,咱们就按照中国人的习惯给自己的框架命名,要我就命名为:熊猫、神龙、白蛇、神雕。嘿嘿!有点不正经了,下面回到今天的正题,Hystrix 。

前面几节克我们介绍了springcloud中Eureka (服务治理) 和 Ribbon(负载均衡)。从今天开始,咱们介绍springcloud 中比较重要的一部分内容: Hystrix 服务容错保护机制。

一、 哪服务框架中为什么需要服务容错保护呢?

在微服务架构中,我们将系统拆分成了很多服务单元,各单元的应用间通过服务注册与订阅的方式互相众依赖。由于每个单元都在不同的进程中进行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟,而这些问题会直接导致调用方的服务也出现延迟,如果调用方的请求不断增加,最后就会因等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪。

上面这些文字比如抽象,咱们通过一个词和一张图就可以说明【雪崩效应】。哪什么是雪崩效应呢?请看下图,一边看图一边说明

在微服务架构中通常会有多个服务层调用,大量的微服务通过网络进行通信,从而支撑起整个系统。各个微服务之间也难免存在大量的依赖关系。然而任何服务都不是100%可用的,网络往往也是脆弱的,所以难免有些请求会失败。基础服务的故障导致级联故障,进而造成了整个系统的不可用,这种现象被称为服务雪崩效应。服务雪崩效应描述的是一种因服务提供者的不可用导致服务消费者的不可用,并将不可用逐渐放大的过程。

正如上面的图表示的一样: A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者。A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了。

二、要解决雪崩效应带来的系统瘫痪影响,我们程序员和架构人员应该要怎么做呢?

两种解决方案和思路:超时机制 、断路器模式

超时机制

通过网络请求其他服务时,都必须设置超时。正常情况下,一个远程调用一般在几十毫秒内就返回了。当依赖的服务不可用,或者因为网络问题,响应时间将会变得很长(几十秒)。而通常情况下,一次远程调用对应了一个线程/进程,如果响应太慢,那这个线程/进程就会得不到释放。而线程/进程都对应了系统资源,如果大量的线程/进程得不到释放,并且越积越多,服务资源就会被耗尽,从而导致资深服务不可用。所以必须为每个请求设置超时。

但超时机制不能彻底解决雪崩的出现。

断路器模式

上面就是一个“断路器”原理图。

“断路器”本身是一种开关装置,用于在电路上保护线路过载,当线咱中有电器 发生短路时,“断路器”能及时切断故障电路和,防止发生过载、发热甚至起火等严重后果。

试想一下,家庭里如果没有断路器,电流过载了(例如功率过大、短路等),电路不断开,电路就会升温,甚至是烧断电路、起火。有了断路器之后,当电流过载时,会自动切断电路(跳闸),从而保护了整条电路与家庭的安全。当电流过载的问题被解决后,只要将关闭断路器,电路就又可以工作了。

所以有了这个“断路器”,家里就安全多了。

三、分布式架构中 “断路器”模式的作用

当某个服务单元发生故障(类似电器发生短路)后,通过断路器的故障监控(类似熔断保险丝),向调用 方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用而不释放,避免了故障在分布式系统中的蔓延(雪崩效应就不会发生,家里就不会发生电器过热导致火灾)。

同样的道理,当依赖的服务有大量超时时,再让新的请求去访问已经没有太大意义,只会无谓的消耗现有资源。譬如我们设置了超时时间为1秒,如果短时间内有大量的请求(譬如50个)在1秒内都得不到响应,就往往意味着异常。此时就没有必要让更多的请求去访问这个依赖了,我们应该使用断路器避免资源浪费。

断路器可以实现快速失败,如果它在一段时间内侦测到许多类似的错误(譬如超时),就会强迫其以后的多个调用快速失败,不再请求所依赖的服务,从而防止应用程序不断地尝试执行可能会失败的操作,这样应用程序可以继续执行而不用等待修正错误,或者浪费CPU时间去等待长时间的超时。断路器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。

断路器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数,然后决定使用允许操作继续,或者立即返回错误。

四、Spring cloud Hystrix 服务容错保护机制

下面这段代码中直接使用Hystrix介绍中的一张原图:

spring cloud Hystrix 实现了断路器、线程隔离等一系列服务保护功能。该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力 ,Hystrix 具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等功能。

六、总结

Hystrix 提供一系列服务保护功能,是服务治理框架必不可少的一部分内容。

咱们在下节课程中介绍到:如何在程序中实现引入Hystrix

声明:文章属于个人原创,转载请注明文章出处

原文发布于微信公众号 - 全华班(quanhuaban)

原文发表时间:2017-12-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏chenssy

【追光者系列】HikariCP连接池监控指标实战

该指标持续飙高,说明DB连接池中基本已无空闲连接。 拿之前业务方应用pisces不可用的例子来说(如下图所示),当时所有线程都在排队等待,该指标已达172,此时...

854
来自专栏沃趣科技

容器化RDS|计算存储分离架构下的 IO 优化

在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Sensi...

2794
来自专栏架构师之路

“id串行化”到底是怎么实现的?

一、需求缘起 在上一篇文章《消息“时序”与“一致性”为何这么难?》中,介绍了一种为了保证“所有群友展示的群消息时序都是一致的”所使用的“id串行化”的方法:让同...

3528
来自专栏IT技术精选文摘

缓存更新的套路

看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。试想,两个并发操作,一个是更新操作...

2607
来自专栏腾讯技术工程官方号的专栏

PGXZ 腾讯分布式关系数据集群—架构解析

本文作者:数据平台部存储引擎组PGXZ项目负责人,2013年从华为加入腾讯,从事数据库和存储相关的工作。多年来一直致力于数据库引擎的研究和开发,从事过多款数据库...

23911
来自专栏码洞

你没读过的Jetty使用入门

在近几年的开源Java容器市场上,Tomcat依旧保持在龙头老大的位置,其地位丝毫没有被撼动的迹象。与此同时Tomcat也因为架构臃肿结构复杂而饱受批评。作为T...

832
来自专栏JAVA高级架构

网站高并发大流量访问的处理及解决方法

.硬件升级 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不...

2826
来自专栏IT大咖说

容器化RDS|计算存储分离架构下的 IO 优化

摘要 在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Se...

3168
来自专栏码农之路_构建基础

基于汇编的 C/C++ 协程 - 背景知识

近几年来,协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案,并且说明其在异步开发模式中的应用。

1623
来自专栏smartguys

(二): 基于ZeroMQ的实时通讯平台

  上篇:C++分布式实时应用框架 (Cpp Distributed Real-time Application Framework)----(一):整体介绍

743

扫描关注云+社区