springcloud hystrix概述（一）

一：什么是Hystrix?

在分布式环境中，许多服务依赖项中的一些将不可避免地失败。Hystrix是一个库，通过添加延迟容差和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止其间的级联故障以及提供回退选项，从而提高系统的整体弹性。

Hystrix旨在执行以下操作

1：对通过第三方客户端库访问（通常通过网络）的依赖关系提供保护并控制延迟和故障。

2：隔离复杂分布式系统中的级联故障。

3：快速发现故障，尽快恢复。

4：回退，尽可能优雅地降级。

5：启用近实时监控，警报和操作控制。

二：为什么需要Hystrix?

分布式系统所面临的分体：大型分布式系统中，一个客户端或者服务依赖外部服务，如果一个服务宕了，那么由于我们设置了服务调用系统超时时间，势必会影响相应时间，在高并发的情况下大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性。严重会产生服务雪崩

服务雪崩效应:

         多个微服务之间调用的时候，假设微服务A服务调用微服务B服务和C服务，微服务B和微服务C又调用其他微服务，这就是所谓的 "扇出" 。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的的系统资源，进而引起系统资源崩溃，这就是所谓的雪崩效应。

(图片官方图片)

当一切都健康时，请求可以看起来像这样

 

下图A   P   H    I  四个服务，如果I服务超时会出现什么情况呢？

当许多后端服务系统中的一个宕掉时或者响应超时，整个用户请求：

如果多个客户端调用同一个异常服务的时候，出现的情况是：

 

 

 

 

 

三：Hystrix解决什么问题？

分布式架构中的应用程序具有几十个依赖关系，每个依赖关系在某个时刻将不可避免的出现异常。如果应用程序不与这些外部故障隔离，则可能出现线程池阻塞，引起系统雪崩。

例如，对于依赖30个服务的应用程序，每个服务的正常运行时间为99.99％，您可以：

99.99%的30次方 = 99.7％正常运行时间

0.3％的10亿次请求= 3,000,000次故障

2+小时宕机/月，即使所有依赖关系正常运行时间。

当使用Hystrix进行熔断后，每个依赖关系彼此隔离了，限制了当发生延迟时的阻塞。

 

四：Hystrix能干嘛

　1.请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).

　　　 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

　　2.服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。

　　3.依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放

　　　后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，

　　　我的B服务依然可以用。

　　4.请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。

　　5.请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。