gpt4 book ai didi

1、Hystrix 简介

转载 作者:大佬之路 更新时间:2024-01-21 22:29:48 28 4
gpt4 key购买 nike

hystrix介绍

Hystrix 供分布式系统使用,提供延迟和容错功能,隔离远程系统、访问和第三方程序库的访问点,防止级联失败,保证复杂的分布系统在面临不可避免的失败时,仍能有其弹性。

hystrix历史

hystrix,高可用性保障的一个框架,是Netflix公司API团队从2011年开始做一些提升系统可用性和稳定性的工作,Hystrix就是从那时候开始发展出来的。时至今日,Netflix中每天都有数十亿次的服务间调用,通过Hystrix框架在进行,而Hystrix也帮助Netflix网站提升了整体的可用性和稳定性。

hystrix的适用场景

适用场景:

对于一个分布式系统,不同的的服务间存在着很多依赖,比如服务A依赖服务B、C、D,服务A拿到B、C、D返回的数据,进行下一个环节的操作,这时候如果服务B出现故障,这时候使用hystrix可以确保服务A停止调用服务B,只调用服务C、服务D,使系统能正常的响应,不会因为服务B故障而导致整个系统崩溃。

例如:

短信发送微服务,因为对接了多个渠道,当某个渠道不可用的情况下,hystrix熔断掉,然后采取另外的渠道进行下发。在发送量级比较大的情况,可以减少短信发送进行重试的时间。

不适用场景:

如果你的服务所依赖的服务均是核心业务,不能熔断,这个时候就不能使用hystrix了。

例如:

计费业务,id生成器业务作为核心业务,是整个短信业务的核心,如果引入熔断机制会导致业务流程失败,相当于整个短信业务不可用,所以这类核心无降级的服务是不应该启动hystrix的。

hystrix vs dubbo

也许你们的脑海中会有疑问,就是既然我们的分布式系统都使用了分布式服务治理框架了,例如dubbo,可以设置超时时间来打断未响应的调用;为什么还需要hystrix,这不是多此一举么,其实不然,因为dubbo设置的超时时间并不能减轻服务提供方的压力,当你的服务提供方出现故障时,大量的请求依然会打过来,这时候你的服务提供者不段的进行超时处理,抛timeout异常,也就是提供方依然在不断的接收大量的请求,如果突然来了个流量洪峰,你的web容器的线程就会瞬间被吃光,这时候会导致整个系统卡死,无法再为用户作出任何响应了。

而hystrix可以有丰富的配置,其原理是:在一个窗口时间内针对错误进行计数,当达到阈值则熔断提供方,不在请求该熔断的提供方,然后快速返回。hystrix能够解决服务提供者不可用的场景。他采用了资源隔离模式,通过线程隔离和信号量隔离保护主线程池;使用熔断器避免无节操的重试,并提供断路自动复位功能。下面我们就来看一看如何使用hystrix。

hystrix开发原则

1、 阻止任何一个依赖服务耗尽所有的资源,比如tomcat中的所有线程资源;
2、 避免请求排队和积压,采用限流和fail fast来控制故障;
3、 提供fallback降级机制来应对故障;
4、 使用资源隔离技术,比如bulkhead(舱壁隔离技术),swimlane(泳道技术),circuit breaker(短路技术),来限制任何一个依赖服务故障导致的影响;
5、 通过近实时的统计/监控/报警功能,来提高故障发现的速度;
6、 通过近实时的属性和配置热修改功能,来提高故障处理和恢复的速度;
7、 保护依赖服务调用的所有故障情况,而不仅仅只是网络故障情况;

hystrix如何实现目标

1、 通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求,这个访问请求一般会运行在独立的线程中,资源隔离;
2、 对于超出我们设定阈值的服务调用,直接进行超时,不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间,但是一般我们可以自己设置一下;
3、 为每一个依赖服务维护一个独立的线程池,或者是semaphore,当线程池已满时,直接拒绝对这个服务的调用;
4、 对依赖服务的调用的成功次数,失败次数,拒绝次数,超时次数,进行统计;
5、 如果对一个依赖服务的调用失败次数超过了一定的阈值,自动进行熔断,在一定时间内对该服务的调用直接降级,一段时间后再自动尝试恢复;
6、 当一个服务调用出现失败,被拒绝,超时,短路等异常情况时,自动调用fallback降级机制;
7、 对属性和配置的修改提供近实时的支持;

摘抄

App Container可以是我们的应用容器,比如jettytomcat,也可以是一个用来处理外部请求的线程池(比如netty的worker线程池)。一个用户请求有可能依赖其他多个外部服务,比如上图中的A,H,I,P,在不可靠的网络环境下,任何的RPC都可能会面临三种情况:成功、失败、超时。如果一次用户请求所依赖外部服务(A,H,I,P)有任何一个不可用,就有可能导致整个用户请求被阻塞。考虑到应用容器的线程数目基本都是固定的(比如tomcat的线程池默认200),当在高并发的情况下,某一外部依赖的服务超时阻塞,就有可能使得整个主线程池被占满,这是长请求拥塞反模式(https://tech.meituan.com/performance_tuning_pattern.html)。

 

更进一步,线程池被占满就会导致整个服务不可用,而依赖该服务的其他服务,就又可能会重复产生上述问题。因此整个系统就像雪崩一样逐渐的扩散、坍塌、崩溃了!

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com