Hystrix

示例图

什么是服务雪崩?

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

对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。

所以通常当发现某个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。

1.1.Hystrix是干嘛的

Hystrix是一个用于处理分布式系统的延迟和容错的一个开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能保证在一个依赖出现问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的稳定性。“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的,可处理的备选响应,而不是长时间等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。

1.2.服务降级(Fallback)

1.2.1什么是服务降级

假设对方系统不可用了,向调用方返回一个符合预期的,可备选的响应。服务器忙,请稍后重试,不让客户等待并立刻返回一个友好的提示,这就是服务降级。就像if( ){ }else if{}....有备选方案。再比如给10086打电话,客服繁忙...

出现服务降级的情况:

  • ①程序运行异常;
  • ②超时;
  • ③服务熔断触发服务降级;
  • ④线程池/信号量打满也会导致服务降级。

1.2.2进行服务降级的情况

用jmeter进行压力测试,开启20000个线程进行测试,测试服务端8001环境下的两个地址,结果发现不仅压测访问的地址变慢,同一微服务下的另一个地址访问也变慢了,假设客户端80访问,一定会更慢,那样客户端一定会很不满意。那就来试一下,让客户端访问:8001同一层次的其它接口服务被困死(20000个线程访问),因为tomcat线程池里面的工作线程已经被挤占完毕,80此时调用8001,客户端访问响应会变慢,转圈圈。正是因为这些故障和不佳表现,才有我们的降级、容错、限流等技术的产生。

解决要求:

  • 超时导致服务器变慢(转圈):超时不再等待;
  • 出错(宕机或程序运行出错):出错要有兜底。

1.2.3解决方案

对方服务(8001)超时了,调用者(80)不能一直卡死等待,必须有服务降级;对方服务(8001)宕机了,调用者(80)不能一直卡死等待,必须服务降级;对方服务(8001)OK(可能),调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者),自己处理降级。

1.2.4如何启用服务降级

服务端做降级:首先在业务类中加入新的配置标签@HystrixCommand,相当于在fallbackMethod中添加一个方法,如下value设置为3s,当超过3秒时,就会调用备用的方法,或者是方法中运行错误,比如说是以下的10/0报错。

image

然后在主启动类中加入@EnableCircuitBreaker,这样就可以在服务提供端测试自己的服务降级了

而一般Hystrix服务降级fallback是放在客户端的,步骤如下:

①首先在yml加上hystrix和feign的配置

image

②在主启动类中添加注解@EnableHystrix

③在业务类中利用Hystrix实现服务降级就行了,跟服务提供端类似。在这里消费者端的服务降级时间设置的是1.5秒,而上面服务端设置的时间是3s,加入服务端线程运行时间实际花费了2秒,在客户端照样会发生服务降级,而以下10/0在会直接进行降级。

image

上面的方法是利用openfeign直接调用服务端提供的方法。是前面学习过的。

image

1.2.5设置全局通用服务降级方法

目前存在的问题,每个业务方法都会有一个兜底的方法,会导致代码膨胀,可以设置一个全局通用的服务降级兜底的方法,如果需要特殊配置的在另外配。需要加入一个新的注解:DefaultProperties(defaultFallback=" ")统一跳转到处理结果页面。这样可以使得代码量大大减少。首先在类上加上新的注解,其他的方法没有设置fallback属性的话,就会进入全局fallback方法。

image

就像这样,下面的方法只添加了@HystricCommand注解,如果出现异常就会进入payment_global_fallback兜底方法。

image

1.2.6通配服务降级

目前来看,耦合度太高,在controller中要声明很多兜底的方法以备用,可以从源头来解决这个问题,在这里使用的feign调用的服务端提供的方法,可以直接在这个调用类里进行解决,如下:写一个fallback的类直接实现这个接口,一旦这个接口中的某个方法出现了问题,会直接调用实现类中的方法。如果发生运行、超时、宕机异常都会导致降级,而下面的paymentinfo_OK在其他地方没有配置降级方法,如果8001宕机,一定会调用下面实现类的paymentinfo_OK方法。

image
image
image

1.3服务熔断(break)

类似保险丝达到最大服务访问时,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示。断路器就相当于是保险丝。

熔断机制的描述:熔断机制是应对雪崩效应的一种微服务链路保护机制,当扇出链路某个微服务出错不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回错误信息。当检测到该节点微服务调用响应正常后,恢复调用链路。熔断机制通过Hystrix实现,Hystrix会监控微服务间的调用的状况,当失败的调用到一定的阈值,缺省是5秒内20次调用失败,就会启动熔断机制,熔断机制的注解是@HystrixCommand。

Hystrix结构图
image

断路器三个重要参数:快照时间窗、请求总数阈值、错误百分比阈值

1、快照时间窗:断路器确定是否打开需要统计一些请求和错误数据,而统计的时间范围就是快照时间窗,默认为最近的10s。
2、请求总数阈值:在快照时间窗内,必须满足请求总数阈值才有资格熔断,默认为20,意味着在10s内,如果该hystrix命令的调用次数不足20次,即使所有的请求都超时或其他原因失败,断路器都不会打开。
3、错误百分比阈值:当请求总数在快照时间窗内超过了阈值,比如发生了30次调用,如果在这30次调用中,有15次发生了超时异常,也就是超过50%的错误百分比,在默认设置50%阈值的情况下,这时候就会将断路器打开。

如以下所示,仍然还是在HystrixCommand注解中进行配置,在上面加了四个Hystrix新的属性配置,意思就是在10s的窗口期内,发送十次请求,假如说有60%也就是6次都失败了,就激活断路器。而当他断路器激活以后,所有的请求都无法处理了,而过一段时间之后,断路器又会尝试着让少量的请求通过一下(也就是断路器进入了half-open状态),而如果请求仍然失败,断路器又会重新回到open状态,如果请求成功,断路器则会关闭。也就是链路恢复。

在controller中写出响应的调用,然后进行访问,如果十次中有六次及以上是负数,会发现,第11次时就算是正数仍然会进入fallback方法,因为此时进行了服务熔断。

image

1.4服务限流:(flowlimit)

秒杀高并发的操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序的进行。

1.5 Hystrix工作流程总结

image

1.6 接近实时的监控

Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续的记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求,多少成功,多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。

1.6.1搭建流程

①首选创建一个新的module,导入pom,主要是spring-cloud-starter-netflix-hystrix-dashboard

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

注意还有一个依赖,这个依赖如果是要进行图形化展示是一定要有的,一般和web同时存在

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

②然后配置yml

暂且配置一个端口号就够用了

image

③主启动类,注意添加了一个新的注解:@EnableHystrixDashboard,一般要用一个新的功能,就要添加新的注解

image

④:最后访问localhost://9001/hystrix就可以显示了

image

1.6.2进一步配置以进行监控

Hystrix的服务监控需要自己配置,对于传统的微服务架构一定是够用了,而spring Cloud Alibaba提供的微服务监控可以直接访问,在后面会学习到,主要进行sentienl的学习。

image
image
image
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,816评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,729评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,300评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,780评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,890评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,084评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,151评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,912评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,355评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,666评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,809评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,504评论 4 334
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,150评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,882评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,121评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,628评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,724评论 2 351

推荐阅读更多精彩内容