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配置上不用做任何改动。

1、配置文件

application.properties添加这一条:

feign.hystrix.enabled=true

2、创建回调类

创建HelloRemoteHystrix类继承与HelloRemote实现回调的方法

@Component
public class HelloRemoteHystrix implements HelloRemote{

    @Override
    public String hello(@RequestParam(value = "name") String name) {
        return "hello" +name+", this messge send failed ";
    }
}

3、添加fallback属性

HelloRemote类添加指定fallback类,在服务熔断的时候返回fallback类中的内容。

@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class)
public interface HelloRemote {

    @RequestMapping(value = "/hello")
    public String hello(@RequestParam(value = "name") String name);

}

改动点就这点,很简单吧。

4、测试

那我们就来测试一下看看效果吧。

依次启动spring-cloud-eureka、spring-cloud-producer、spring-cloud-consumer三个项目。

浏览器中输入:http://localhost:9001/hello/neo

返回:hello neo,this is first messge

说明加入熔断相关信息后,不影响正常的访问。接下来我们手动停止spring-cloud-producer项目再次测试:

浏览器中输入:http://localhost:9001/hello/neo

返回:hello neo, this messge send failed

根据返回结果说明熔断成功。

示例代码

参考:

使用Spring Cloud与Docker实战微服务

微服务框架Spring Cloud介绍 Part5: 在微服务系统中使用Hystrix, Hystrix Dashboard与Turbine



作者:纯洁的微笑
出处:http://www.ityouknow.com/
版权归作者所有,转载请注明出处

时间: 2025-01-29 22:22:34

springcloud(四):熔断器Hystrix的相关文章

使用 Spring Cloud 和 Docker 构建微服务

该项目主要是对微服务,以及Spring Cloud系统学习的一些总结,使用gitbook写成了书. 探讨的话题主要有: 什么是微服务 注册中心Eureka 服务提供者 服务消费者 客户端负载均衡Ribbon 简化的Http客户端Feign 熔断器 Hystrix Hystrix监控界面Hystrix Dashboard Hystrix集群监控工具Turbine 配置中心 API Gateway 使用Docker构建微服务 目前基于Spring Cloud构建微服务的必要组件已经讲解完成. 下一步

从架构演进的角度聊聊Spring Cloud都做了些什么?

Spring Cloud作为一套微服务治理的框架,几乎考虑到了微服务治理的方方面面,之前也写过一些关于Spring Cloud文章,主要偏重各组件的使用,本次分享主要解答这两个问题:Spring Cloud在微服务的架构中都做了哪些事情?Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利? 这也是我写Spring Cloud三部曲的最后一篇文章,前两面篇内容如下: 中小型互联网公司微服务实践-经验和教训 Spring Cloud在国内中小型公司能用起来吗? 我们先来简单回顾一下

springcloud微服务四:服务容错保护Hystrix断路器

通过前边的学习,服务注册中心.服务提供者和服务消费者都成功建立并运行起来,而且通过默认的配置restTemplate及@loadbalanced注解开启了负载均衡. 在默认的情况下,负载均衡策略是线性轮询的方式,也就是说在客户端获取到的服务列表中依次交替,例如开启了三个服务server1.server2.server3,那么在线性轮询时,就会按这个顺序来调用. 我之前是开启了两个服务,一个端口是1001,另一个是2001,那么在之前的这种情况下,如果我关闭其中一个服务,就比如这里关闭1001端口

springcloud(五):熔断监控Hystrix Dashboard和Turbine

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具,通过Hystrix Dashboard我们可以在直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据.但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine.   Hystrix Dashboard 我们在熔断示例项目spring

王新栋 | Hystrix技术解析

一.认识Hystrix Hystrix是Netflix开源的一款容错框架,包含常用的容错方法:线程池隔离.信号量隔离.熔断.降级回退.在高并发访问下,系统所依赖的服务的稳定性对系统的影响非常大,依赖有很多不可控的因素,比如网络连接变慢,资源突然繁忙,暂时不可用,服务脱机等.我们要构建稳定.可靠的分布式系统,就必须要有这样一套容错方法. 本文将逐一分析线程池隔离.信号量隔离.熔断.降级回退这四种技术的原理与实践. 二.线程隔离 2.1为什么要做线程隔离 比如我们现在有3个业务调用分别是查询订单.查

springcloud(一):大话Spring Cloud

研究了一段时间spring boot了准备向spirng cloud进发,公司架构和项目也全面拥抱了Spring Cloud.在使用了一段时间后发现Spring Cloud从技术架构上降低了对大型系统构建的要求,使我们以非常低的成本(技术或者硬件)搭建一套高效.分布式.容错的平台,但Spring Cloud也不是没有缺点,小型独立的项目不适合使用,另外对分布式事物的支持暂时也没有. Spring Cloud是什么鬼? Spring Cloud是一个基于Spring Boot实现的云应用开发工具,

DockOne微信分享(九十六):爱油科技基于SpringCloud的微服务实践

本文讲的是DockOne微信分享(九十六):爱油科技基于SpringCloud的微服务实践[编者的话]本次分享主要介绍了爱油科技基于Docker和Spring Cloud将整体业务微服务化的一些实践经验,主要包括: 微服务架构的分层和框架选型 服务发现和配置管理 服务集成和服务质量保证 基于领域驱动设计 实施DevOps 从单体应用到微服务 单体应用 对于单体应用来说,优点很多,例如: 小而美,结构简单易于开发实现 部署门槛低,单个Jar包或者网站打包即可部署 可快速实现多实例部署 然而随着业务

springcloud config 分布式配置中心

一.介绍 1.场景: 微服务系统中,系统多.实例多,如果每个系统都有自己一套配置加载.维护的机制,会导致在生产过程中因为配置问题引发的不必要的沟通成本.故障风险.需要采用分布式配置中心统一管理.统一实现方式. 2.Spring cloud config特性 服务端:存储方式(git.svn.本地文件).配置读取方式(环境化.多项目仓库).安全性(访问密码.加密存储).自动刷新. 客户端:加载远程配置.刷新配置.@refreshscope作用域刷新.集成消息总线. 二.docker中运行gitla

从Netflix的Hystrix框架理解服务熔断和服务降级

本文讲的是从Netflix的Hystrix框架理解服务熔断和服务降级,伴随着微服务架构被宣传得如火如荼,一些概念也被推到了我们面前,其实大多数概念以前就有,但很少被提的这么频繁.想起有人总结的一句话,微服务架构的特点就是:"一解释就懂,一问就不知,一讨论就吵架". 其实对老外的总结能力一直特别崇拜,Kevin Kelly.Martin Fowler.Werner Vogels--,都是著名的"演讲家".正好这段时间看了些微服务.容器的相关资料,也在我们新一代产品中进