springcloud(八)：熔断器Hystrix

熔断器

雪崩效应

在微服务架构中一般会有多个服务层调用，基础服务的故障可能会致使级联故障，进而形成整个系统不可用的状况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用致使“服务消费者”的不可用,并将不可用逐渐放大的过程。

若是下图所示：A做为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引发了B的不可用，并将不可用像滚雪球同样放大到C和D时，雪崩效应就造成了。

熔断器（CircuitBreaker）

熔断器的原理很简单，如同电力过载保护器。它能够实现快速失败，若是它在一段时间内侦测到许多相似的错误，会强迫其之后的多个调用快速失败，再也不访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操做，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可使应用程序可以诊断错误是否已经修正，若是已经修正，应用程序会再次尝试调用操做。

熔断器模式就像是那些容易致使错误的操做的一种代理。这种代理可以记录最近调用发生错误的次数，而后决定使用容许操做继续，或者当即返回错误。 熔断器开关相互转换的逻辑以下图：

熔断器就是保护服务高可用的最后一道防线。

Hystrix特性

1.断路器机制

断路器很好理解, 当Hystrix Command请求后端服务失败数量超过必定比例(默认50%), 断路器会切换到开路状态(Open). 这时全部请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回状况, 若是请求成功, 断路器切回闭路状态(CLOSED), 不然从新切换到开路状态(OPEN). Hystrix的断路器就像咱们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 而且断路器有自我检测并恢复的能力.

2.Fallback

Fallback至关因而降级操做. 对于查询操做, 咱们能够实现一个fallback方法, 当请求后端服务出现异常的时候, 可使用fallback方法返回的值. fallback方法的返回值通常是设置的默认值或者来自缓存.

3.资源隔离

在Hystrix中, 主要经过线程池来实现资源隔离. 一般在使用的时候咱们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用帐户服务的Command放入B线程池. 这样作的主要优势是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者因为其余缘由致使本身所在线程池被耗尽时, 不会对系统的其余服务形成影响. 可是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 若是是对性能有严格要求并且确信本身调用服务的客户端代码不会出问题的话, 可使用Hystrix的信号模式(Semaphores)来隔离资源.

Feign Hystrix

由于熔断只是做用在服务调用这一端，所以咱们根据上一篇的示例代码只须要改动spring-cloud-consumer项目相关代码就能够。由于，Feign中已经依赖了Hystrix因此在maven配置上不用作任何改动。

 

本帖转自：http://www.ityouknow.com/springcloud/2017/05/16/springcloud-hystrix.html

转载请注明出处！