前言

本文主要内容：

Hystrix原理

服务雪崩

服务雪崩效应是一种因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程。服务雪崩效应的产生一般有三个流程：
1.首先是服务提供者不可用
2.然后重试会导致网络流量加大
3.最后导致服务调用者不可用。
导致服务提供者不可用的原因有很多：

可能是因为服务器的宕机或者网络故障；
也可能是因为程序存在的缺陷；
也有可能是大量的请求导致服务提供者的资源受限无法及时响应；
还有可能是因为缓存击穿造成服务提供者超负荷运行等等。

在服务提供者不可用发生之后，用户可能无法忍受长时间的等待，不断地发送相同的请求，服务调用者重新调用服务提供者，同时服务提供者中可能存在对异常的重试机制，这些都会加大对服务提供者的请求流量。然而此时的服务提供者已经是一艘破船，它也无能无力，无法返回有效的结果。最后是服务调用者因为服务提供者的不可用导致了自身的崩溃。当服务调用者使用同步调用的时候，大量的等待线程将会耗尽线程池中的资源，最终导致服务调用者的宕机，无法响应用户的请求，服务雪崩效应就此发生了。

断路器

在分布式系统中，不同服务之间的调用非常常见，当服务提供者不可用时就很有可能发生服务雪崩效应，导致整个系统的不可用。所以为了预防这种情况的发生，可以使用断路器模式进行预防（类比电路中的断路器，在电路过大的时候自动断开，防止电线过热损害整条电路）。断路器将远程方法调用包装到一个断路器对象中，用于监控方法调用过程的失败。一旦该方法调用发生的失败次数在一段时间内达到一定的阀值，那么这个断路器将会跳闸，在接下来时间里再次调用该方法将会被断路器直接返回异常，而不再发生该方法的真实调用。这样就避免了服务调用者在服务提供者不可用时发送请求，从而减少线程池中资源的消耗，保护了服务调用者。

如图所示，虽然断路器在打开的时候避免了被保护方法的无效调用，但是当情况恢复正常时，需要外部干预来重置断路器，使得方法调用可以重新发生。所以合理的断路器应该具备一定的开关转化逻辑，它需要一个机制来控制它的重新闭合，下图展示了一个通过重置时间来决定断路器的重新闭合的逻辑。

关闭状态：断路器处于关闭状态，统计调用失败次数，在一段时间内达到一定的阀值后断路器打开。
打开状态：断路器处于打开状态，对方法调用直接返回失败错误，不发生真正的方法调用。设置了一个重置时间，在重置时间结束后，断路器来到半开状态。
半开状态：断路器处于半开状态，此时允许进行方法调用，当调用都成功了（或者成功到达一定的比例），关闭断路器，否则认为服务没有恢复，重新打开断路器。

断路器的打开能保证服务调用者在调用异常服务时，快速返回结果，避免大量的同步等待，减少服务调用者的资源消耗。并且断路器能在打开一段时间后继续侦测请求执行结果，判断断路器是否能关闭，恢复服务的正常调用。

服务降级操作

断路器为隔断服务调用者和异常服务提供者防止服务雪崩的现象，提供了一种保护措施。而服务降级是为了在整体资源不够的时候，适当放弃部分服务，将主要的资源投放到核心服务中，待渡过难关之后，再重启已关闭的服务，保证了系统核心服务的稳定。

在Hystrix中，当服务间调用发生问题时，它将采用备用的Fallback方法代替主方法执行并返回结果，对失败服务进行了服务降级。当调用服务失败次数在一段时间内超过了断路器的阀值时，断路器将打开，不再进行真正的方法调用，而是快速失败，直接执行Fallback逻辑，服务降级，减少服务调用者的资源消耗，保护服务调用者中的线程资源，如图所示。

资源隔离

在货船中，为了防止漏水和火灾的扩散，一般会将货仓进行分割，避免了一个货仓出事导致整艘船沉没的悲剧。

同样的，在Hystrix中，也采用了舱壁模式，将系统中的服务提供者隔离起来，一个服务提供者延迟升高或者失败，并不会导致整个系统的失败，同时也能够控制调用这些服务的并发度。

1．线程与线程池

Hystrix通过将调用服务线程与服务访问的执行线程分隔开来，调用线程能够空出来去做其他的工作而不至于因为服务调用的执行阻塞过长时间。在Hystrix中，将使用独立的线程池对应每一个服务提供者，用于隔离和限制这些服务。于是，某个服务提供者的高延迟或者饱和资源受限只会发生在该服务提供者对应的线程池中。如图所示，Dependency D的调用失败或者高延迟仅会导致自身对应的线程池中的5个线程阻塞，并不会影响其他服务提供者的线程池。系统完全与服务提供者请求隔离开来，即使服务提供者对应的线程完全耗尽，并不会影响系统中的其他请求。

注意在服务提供者的线程池被占满时，对该服务提供者的调用会被Hystrix直接进入回滚逻辑，快速失败，保护服务调用者的资源稳定。

2．信号量

除了线程池外，Hystrix还可以通过信号量（计数器）来限制单个服务提供者的并发量。如果通过信号量来控制系统负载，将不再允许设置超时控制和异步化调用，这就表示在服务提供者出现高延迟时，其调用线程将会被阻塞，直至服务提供者的网络请求超时。如果对服务提供者的稳定性有足够的信心，可以通过信号量来控制系统的负载。

Hystrix实现思路

结合上面的介绍，我们可以简单理解一下Hystrix的实现思路：

□ 它将所有的远程调用逻辑封装到HystrixCommand或者HystrixObservableCommand对象中，这些远程调用将会在独立的线程中执行（资源隔离），这里使用了设计模式中的命令模式。
□ Hystrix对访问耗时超过设置阀值的请求采用自动超时的策略。该策略对所有的命令都有效（如果资源隔离的方式为信号量，该特性将失效），超时的阀值可以通过命令配置进行自定义。
□ 为每一个服务提供者维护一个线程池（或者信号量），当线程池被占满时，对于该服务提供者的请求将会被直接拒绝（快速失败）而不是排队等待，减少系统的资源等待。
□ 针对请求服务提供者划分出成功、失效、超时和线程池被占满等四种可能出现的情况。
□ 断路器机制将在请求服务提供者失败次数超过一定阀值后手动或者自动切断服务一段时间。
□ 当请求服务提供者出现服务拒绝、超时和短路（多个服务提供者依次顺序请求，前面的服务提供者请求失败，后面的请求将不会发出）等情况时，执行其Fallback方法，服务降级。
□ 提供接近实时的监控和配置变更服务。

Hystrix原理介绍：服务雪崩、断路器、服务降级、资源隔离-《Spring Cloud微服务架构进阶》读书笔记相关推荐

Spring Boot+Eureka+Spring Cloud微服务快速上手项目实战
说明我看了一些教程要么写的太入门.要么就是写的太抽象.真正好的文章应该是快速使人受益的而不是浪费时间.本文通过一个包括组织.部门.员工等服务交互的案例让刚接触spring cloud微服务的朋友快速 ...
实战系列-Spring Cloud微服务中三把利器Feign、Hystrix、Ribbon
导语在之前的分享中分享过关于Fegin的底层实现原理,以及Spring Cloud OpenFegin的启动原理.在这次的分享中主要总结一下Spring Cloud 微服务架构的三把利器.对于F ...
Spring Cloud微服务系统架构的一些简单介绍和使用
Spring Cloud 目录特征云原生应用程序 Spring Cloud上下文:应用程序上下文服务引导应用程序上下文应用程序上下文层次结构改变Bootstrap的位置Properties ...
spring cloud微服务治理eureka、hystrix、zuul代码例子
spring cloud微服务中台服务代码例子,包括eureka.hystrix.zuul https://github.com/birdstudiocn/spring-cloud-sample/tr ...
《Spring Cloud 微服务架构进阶》读书笔记
前页随着 DevOps 和以 Docker 为主的容器技术的发展,云原生应用架构和微服务变得流行起来. 云原生包含的内容很多,如 DevOps.持续交付.微服务.敏捷等第一章,微服务架构介绍架 ...
Spring Cloud 微服务技术栈
Spring Cloud 简介主要内容微服务简介 SpringCloud 简介 SpringCloud 框架结构 SpringCloud 和 Dubbo 的对比 SpringCloud 版本号说明 ...
Spring Cloud 微服务讲义
Spring Cloud 微服务讲义第一部分微服务架构第 1 节互联网应用架构演进第 2 节微服务架构体现的思想及优缺点第 3 节微服务架构中的核心概念第二部分 Spring Clo ...
《Spring Cloud微服务和分布式系统实践》即将印刷和出版
我经过一年多的沉寂, 我的新书<Spring Cloud微服务和分布式系统实践>即将发版,预计这个月底可以销售了. 全书大约514页,还算一本挺厚的书籍,不过价格未定,按人邮出版社的估计大 ...
疯狂Spring Cloud微服务架构实战
网站更多书籍点击进入>> CiCi岛下载电子版仅供预览及学习交流使用,下载后请24小时内删除,支持正版,喜欢的请购买正版书籍电子书下载(皮皮云盘-点击"普通下载" ...
Spring Cloud 微服务项目操作实战流程（完结）
Spring Cloud入门项目操作实战流程 Day01~02 〇.Service - 业务服务结构商品服务 item service,端口 8001 用户服务 user service,端口 81 ...

Hystrix原理介绍：服务雪崩、断路器、服务降级、资源隔离-《Spring Cloud微服务架构进阶》读书笔记

前言