hystrix适用场景
2017-06-13 16:31
260 查看
在分布式架构中,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。
如果需要保护后端的es集群,需要协调调用方限制自己的请求,当后端请求返回比较慢的情况下,通过hystrix超时进行熔断,避免后端es挂掉。前提是调用方对查询的数据容忍度比较高,就算查询不到数据也可以接受(短暂性)
hystrix可以有丰富的配置,其原理是:在一个窗口时间内针对错误进行计数,当达到阈值则熔断提供方,不在请求该熔断的提供方,然后快速返回。
并不是每一个业务都需要开启hystrix的支持
在启用hystrix的情况下,对于整个分布式服务集群来讲,并不能完全避免服务雪崩,仅能保证调用方服务在发生网络雪崩发时候自己不被拖死,减少雪崩的影响范围。
hystrix适用场景
核心无降级业务
计费业务,id生成器业务作为核心业务,是整个短信业务的核心,如果引入熔断机制会导致业务流程失败,相当于整个短信业务不可用,所以这类核心无降级的服务是不应该启动hystrix的。边缘业务或者可降级的业务
相对的,短信发送微服务,因为对接了多个渠道,当某个渠道不可用的情况下,hystrix熔断掉,然后采取另外的渠道进行下发。在发送量级比较大的情况,可以减少短信发送进行重试的时间。如果需要保护后端的es集群,需要协调调用方限制自己的请求,当后端请求返回比较慢的情况下,通过hystrix超时进行熔断,避免后端es挂掉。前提是调用方对查询的数据容忍度比较高,就算查询不到数据也可以接受(短暂性)
hystrix vs dubbo
dubbo对于调用方,可以设置超时时间来打断未响应的调用,但是并不能减轻提供方的压力。hystrix可以有丰富的配置,其原理是:在一个窗口时间内针对错误进行计数,当达到阈值则熔断提供方,不在请求该熔断的提供方,然后快速返回。
总结
是否启动hystrix和hystrix作用阈值应该根据不同业务进行不同精细化的配置,才能发挥出最大的作用。并不是每一个业务都需要开启hystrix的支持
在启用hystrix的情况下,对于整个分布式服务集群来讲,并不能完全避免服务雪崩,仅能保证调用方服务在发生网络雪崩发时候自己不被拖死,减少雪崩的影响范围。
相关文章推荐
- 【Hystrix系列】三、适用的熔断降级场景
- JAVA集合框架中的常用集合及其特点、适用场景、实现原理简介
- volatile的适用场景
- Ajax不适用场景和Ajax适用场景
- 多进程和多线程的区别及适用场景
- Redis是单线程还是双线程?适用场景及经验总结 road
- Thread和Service的区别以及适用场景
- innobackupex中--slave-info参数的含义和适用场景
- 消息队列服务Kafka揭秘:痛点、优势以及适用场景
- storm记录--4-- Storm适用场景
- Kafka学习笔记02 - 适用场景
- java 常用集合list与Set、Map区别及适用场景总结
- 冒泡排序的Java实现、性能分析以及适用场景
- 简单选择排序的Java实现、性能分析以及适用场景
- mongodb适用和不适用的应用场景
- Apache Spark Streaming的适用场景
- 线程同步互斥锁和读写锁的区别和各自适用场景
- go语言的官方包sync.Pool的实现原理和适用场景
- NoSQL数据库:Redis适用场景及产品定位(转)
- memcache适用和不适用场景[转载] - jamesbd