正文
1. 概述
本文对Hystrix进行介绍,本文内容如下:
-
什么是Hystrix
-
Hystrix要解决的问题和产生的原因分析
-
Hystrix设计原则
-
Hystrix的处理流程图和详细流程说明
-
断路器工作流程
2. Hystrix
2.1. 什么是Hystrix
在分布式环境中,一个服务可能会依赖很多其他的服务,并且这些服务都不可避免地有失效的可能。Hystrix通过隔离服务之间的访问点,阻止它们之间的级联故障以及提供回退选项以提高系统的整体可靠性。
2.2. Hystrix要解决的问题和产生的原因分析
Hystrix要解决的问题和必要性
避免因为单点故障导致服务级联失败,从而使得整个系统崩溃。
官方中提供一个例子,如果一个应用依赖30个服务,每个服务99.99%的时间处于正常服务状态
>
正常工作时间:99.9930 = 99.7% uptime
失败次数:0.3% of 1亿个请求 = 3,000,000 失败
每个月至少有2个小时处于异常状态
即使只有0.01%的失败率,每个月仍然有几个小时服务不可用
Hystrix问题产生的原因分析
正常请求处理流程如下
如果后端的一个服务出现延迟,则会阻塞整个请求
对于高并发的系统,即使只有一个后端的服务出现延迟,它也会导致整个系统的资源在几秒内被全部消耗掉。更糟糕的是,这些服务有可能被其他服务依赖,由于每个服务都有队列、线程池、其他系统资源等,一旦某个服务失效或者延迟增高,会导致整个系统发生更多的级联故障,从而导致这个分布式系统都不可用
2.3. Hystrix设计原则
-
防止单个服务的故障,耗尽整个系统服务的容器(比如tomcat)的线程资源,避免分布式环境里大量级联失败。通过第三方客户端访问(通常是通过网络)依赖服务出现失败、拒绝、超时或短路时执行回退逻辑
-
用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量,当线程池满或信号量满,会立即拒绝服务而不会排队等待)和优雅的服务降级;当依赖服务失效后又恢复正常,快速恢复
-
提供接近实时的监控和警报,从而能够快速发现故障和修复。监控信息包括请求成功,失败(客户端抛出的异常),超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸,此时服务会在一段时间内停止对特定服务的所有请求
-
将所有请求外部系统(或请求依赖服务)封装到HystrixCommand或HystrixObservableCommand对象中,然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池(或信号量),当线程池满或信号量满,会立即拒绝服务而不会排队等待
2.4. Hystrix处理后新的流程
当您使用Hystrix包装每个基础依赖关系时,新的图如下。每个依赖都是相互隔离的,当延迟发生时,会快速失败,执行回退逻辑,避免消耗掉所有资源
3. Hystrix的处理流程图和详细流程说明
Hystrix的处理流程
1. 构造HystrixCommand或HystrixObservableCommand对象
创建代码如下
HystrixCommand command = new HystrixCommand(arg1, arg2);