Hystrix能解决的问题

Hystrix

问题产生

雪崩效应：一种因为服务提供者的不可用导致服务调用者不可用，并将不可用情况逐渐放大的过程
形成过程：
- 服务提供者不可用：
  - 硬件故障，硬件损坏，服务器宕机，网络硬件故障，造成不可用
  - 程序bug
  - 缓存击穿：大量请求同一个key此处key过期，导致loder到DB造成服务提供者过载导致不可用
  - 用户大量请求：
- 重试加大流量：
  - 用户重试：用户不断刷新页面
  - 代码逻辑重试：服务调用端存在服务异常之后的重试逻辑
- 服务调用者不可用：
  - 同步调用等待造成资源耗尽，服务调用者此时也不可用，造成服务雪崩
Hystrix工作原理
- 线程池隔离：Hystrix隔离方式采用线程/信号量的方式，通过隔离限制依赖的并发量和阻塞扩散
  - 线程隔离： hystrix在每一个依赖调用分配了一个线程池，单线程池满了调用将会立即被拒绝，默认采用不排队，加速失败判定，线程数是可以被设定的。
  - 原理：用户请求将不直接依赖于服务本身，而是通过线程池中空闲线程来范文服务，如果线程池已满，择进行降级处理，用户请求不会被阻塞，至少可以有一个执行结果，例如友好的提示，而不是无休止的等待知道系统奔溃
- 信号隔离：类似信号量的一个使用，用于限制并发访问，反正阻塞扩散，与现场隔离最大不同在于执行依赖代码的线程依然是请求线程(改线程需要通过信号申请，如果客户端是可以信的且可以快速放回，可以使用信号隔离代替线程隔离，降低开销)，信号量大小可以动态调整
熔断器：circuit Breaker
- 熔断器是位于线程池之前的组建，当用户请求某一个服务之后，hystrix会先经过熔断器，此时如果熔断器的状态是打开，说明已经熔断的，这时将直接进行降级处理，不会继续发送请求到线程池，熔断器相当于线程池之前的一层屏障，每个熔断器默认维护十个bucket，美妙创建一个bucket，每个bucket记录成功，失败，超时，拒绝次数，当新的bucket被创建，旧的bucket被抛弃，依照bucket的记录来决定是否打开或者关闭断路器。
- 熔断器状态机：
  - closed：熔断器关闭状态，调用失败次数累计到了阀值，或者一定比例，择启动熔断机制。
  - open：熔断打开状态，下游调用直接返回错误，不走网络，不进入线程池，进入这个状态之后，设计了一个时钟选型，默认时间达到一定时间（一般设置成平均故障处理事件也就是MTTR）会进入半熔断状态
  - half-open：半熔断状态，允许定量的服务请求（也就是一部分请求尝试）如果调用都成功，或者一定比例成功，则认为恢复，关闭断路器，否则认为还没好，有回到熔断打开状态。
熔断流程：
- 将请求request封装成一个HystrixCommend,或者HystrixObservableCommand对象
- 执行execute(),queue()方法来做同步或者异步调用
- 如果Hystrix缓存中有数据，则读取缓存数据，之后返回
- 检查熔断器，circuit-breaker是否打开，如果打开，择直接执行getFallback方法降级处理
- 判断线程池，信号量，队列是否被占满，如果满直接执行getFallBack方法降级处理
- 执行HystrixObservableCommand.construct()或者HystrixCommand.run()
- 如果调用超时，执行getFallback方法
- 如果调用异常抛出HystrixBadRequestException，也直接执行getFallback方法
- 调用成功返回成功结果
- getFallBack降级逻辑，以下情况执行
  - 断路器已经打开
  - 线程池，队列，信号量满
  - run方法执行抛出HystrixBadrequestException
  - run方法超时
- 没有实现getFallBack方法直接抛出异常信息
- 降级逻辑失败，也直接抛异常
Hystrix执行方式：刚才说的HystricCommend中的run方法，Hystrix可以有不同的执行策略
- execute为代表的同步执行：一旦开始执行，当前线程就得阻塞一直等到命令返回结果
- queue座位代表的异步执行：命令执行开始返回一个future对象，不阻塞后面的逻辑，开发者更具自己需求获取结果
- 响应式执行，HystrixObservableCommand中使用的模式：命令会返回一个Observable对象，开发可以给Observable对象注册上Observable，通过Rxjava的方式响应式的处理命令执行过程中的不同阶段，比如HystrixCommand中的Observer方法去消费observable中生产的事件。

Hystrix能解决的问题相关推荐

SpringCloud-容错处理Hystrix熔断器
前言:微服务架构应用的特点就是多服务,而服务层之间通过网络进行通信,从而支撑起整个应用系统,所以,各个微服务之间不可避免的存在耦合依赖关系.但任何的服务应用实例都不可能永远的健康或网络不可能永远的都相 ...
分布式服务防雪崩熔断器，Hystrix理论+实战
Hystrix是什么? hystrix对应的中文名字是"豪猪",豪猪周身长满了刺,能保护自己不受天敌的伤害,代表了一种防御机制,这与hystrix本身的功能不谋而合,因此Netfl ...
SpringCloud教程- 断路器（Hystrix）(SpringCloud版本Finchley)
文章目录一.断路器简介(Hystrix) 二.在ribbon中使用断路器(Hystrix) 代码地址:github-spring-cloud地址前言:在微服务架构中,根据业务来拆分成一个个的服务, ...
如何解决微服务架构中的雪崩问题？
记得在三年前公司因为业务发展需要,就曾经将单体应用迁移到分布式框架上来.当时就遇到了这样一个问题:系统仅有一个控制单元,它会调用多个运算单元,如果某个运算单元(作为服务提供者)不可用,将导致控制单元( ...
hystrix 单独使用_使用Hystrix对Dubbo消费者提供线程隔离保护
在dubbo中对于消费者的保护提供了actives进行并发控制保护,但是功能相对薄弱,下面我们探讨下如何使用Netflix提供的服务容错组件Hystrix对dubo消费者提供线程隔离保护为什么需要H ...
SpringCloud与Hystrix断路器
服务熔断,服务降级,服务监控的学习笔记: 问题复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败. 服务雪崩多个微服务之间调用的时候,假设微服务A调用微服务B和 ...
Netflix的Hystrix使用教程
为什么80%的码农都做不了架构师?>>> 一:为什么需要Hystrix? 在大中型分布式系统中,通常系统很多依赖(HTTP,hession,Netty,Dubbo等),如下图: ...
Hystrix都停更了，我为什么还要学？
最近小主看到很多公众号都在发布Hystrix停更的文章,spring cloud体系的使用者和拥护者一片哀嚎,实际上,spring作为Java最大的家族,根本不需要担心其中一两个零件的废弃,Hystr ...
Hystrix入门与分析（一）：初识Hystrix
在以前的文章中,我们介绍过使用Gauva实现限流的功能,现在我们来了解一下如何在服务框架中实现熔断和降级的方法. 简介Hystrix 大型系统架构的演进基本上都是这样一个方向:从单体应用到分布式架构. ...

Hystrix能解决的问题

Hystrix

问题产生

Hystrix能解决的问题相关推荐

最新文章

热门文章