深圳html5网站开发多少钱,wordpress搜索结果模板,南昌建筑工程公司,网站设计文献1、背景
分布式系统环境下#xff0c;服务间类似依赖非常常见#xff0c;一个业务调用通常依赖多个基础服务。如下图#xff0c;对于同步调用#xff0c;当库存服务不可用时#xff0c;商品服务请求线程被阻塞#xff0c;当有大批量请求调用库存服务时#xff0c;最终可…1、背景
分布式系统环境下服务间类似依赖非常常见一个业务调用通常依赖多个基础服务。如下图对于同步调用当库存服务不可用时商品服务请求线程被阻塞当有大批量请求调用库存服务时最终可能导致整个商品服务资源耗尽无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递这种现象被称为雪崩效应。 1.1 雪崩效应常见场景
硬件故障如服务器宕机机房断电光纤被挖断等。流量激增如异常流量重试加大流量等。缓存穿透一般发生在应用重启所有缓存失效时以及短时间内大量缓存失效时。大量的缓存不命中使请求直击后端服务造成服务提供者超负荷运行引起服务不可用。程序BUG如程序逻辑导致内存泄漏JVM长时间FullGC等。同步等待服务间采用同步调用模式同步等待造成的资源耗尽。
1.2 雪崩效应应对策略
针对造成雪崩效应的不同场景可以使用不同的应对策略没有一种通用所有场景的策略参考如下
硬件故障多机房容灾、异地多活等。流量激增服务自动扩容、流量控制限流、关闭重试等。缓存穿透缓存预加载、缓存异步加载等。程序BUG修改程序bug、及时释放资源等。同步等待资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。
综上所述如果一个应用不能对来自依赖的故障进行隔离那该应用本身就处在被拖垮的风险中。 因此为了构建稳定、可靠的分布式系统我们的服务应当具有自我保护能力当依赖服务不可用时当前服务启动自我保护功能从而避免发生雪崩效应。本文将重点介绍使用Hystrix解决同步等待的雪崩问题。
2、初探Hystrix
Hystrix [hɪst’rɪks]中文含义是豪猪因其背上长满棘刺从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架同样具有自我保护能力。为了实现容错和自我保护下面我们看看Hystrix如何设计和实现的。
Hystrix设计目标
对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的阻止故障的连锁反应快速失败并迅速恢复回退并优雅降级提供近实时的监控与告警
Hystrix遵循的设计原则
防止任何单独的依赖耗尽资源线程过载立即切断并快速失败防止排队尽可能提供回退以保护用户免受故障使用隔离技术例如隔板泳道和断路器模式来限制任何一个依赖的影响通过近实时的指标监控和告警确保故障被及时发现通过动态修改配置属性确保故障及时恢复防止整个依赖客户端执行失败而不仅仅是网络通信
Hystrix如何实现这些设计目标
使用命令模式将所有对外部服务或依赖关系的调用包装在HystrixCommand或HystrixObservableCommand对象中并将该对象放在单独的线程中执行每个依赖都维护着一个线程池或信号量线程池被耗尽则拒绝请求而不是让请求排队。记录请求成功失败超时和线程拒绝。服务错误百分比超过了阈值熔断器开关自动打开一段时间内停止对该服务的所有请求。请求失败被拒绝超时或熔断时执行降级逻辑。近实时地监控指标和配置的修改。
2.1 Hystrix入门
2.1.1 Hystrix简单示例
开始深入Hystrix原理之前我们先简单看一个示例。
第一步继承HystrixCommand实现自己的command在command的构造方法中需要配置请求被执行需要的参数并组合实际发送请求的对象代码如下
public class QueryOrderIdCommand extends HystrixCommandInteger {private final static Logger logger LoggerFactory.getLogger(QueryOrderIdCommand.class);private OrderServiceProvider orderServiceProvider;public QueryOrderIdCommand(OrderServiceProvider orderServiceProvider) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(orderService)).andCommandKey(HystrixCommandKey.Factory.asKey(queryByOrderId)).andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerRequestVolumeThreshold(10)//至少有10个请求熔断器才进行错误率的计算.withCircuitBreakerSleepWindowInMilliseconds(5000)//熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试.withCircuitBreakerErrorThresholdPercentage(50)//错误率达到50开启熔断保护.withExecutionTimeoutEnabled(true)).andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(10)));this.orderServiceProvider orderServiceProvider;}Overrideprotected Integer run() {return orderServiceProvider.queryByOrderId();}Overrideprotected Integer getFallback() {return -1;}
}第二步调用HystrixCommand的执行方法发起实际请求。
Test
public void testQueryByOrderIdCommand() {Integer r new QueryOrderIdCommand(orderServiceProvider).execute();logger.info(result:{}, r);
}2.1.2 Hystrix处理流程
Hystrix流程图如下 Hystrix整个工作流如下
构造一个 HystrixCommand或HystrixObservableCommand对象用于封装请求并在构造方法配置请求被执行需要的参数执行命令Hystrix提供了4种执行命令的方法后面详述判断是否使用缓存响应请求若启用了缓存且缓存可用直接使用缓存响应请求。Hystrix支持请求缓存但需要用户自定义启动判断熔断器是否打开如果打开跳到第8步判断线程池/队列/信号量是否已满已满则跳到第8步执行HystrixObservableCommand.construct()或HystrixCommand.run()如果执行失败或者超时跳到第8步否则跳到第9步统计熔断器监控指标走Fallback备用逻辑返回请求响应
从流程图上可知道第5步线程池/队列/信号量已满时还会执行第7步逻辑更新熔断器统计信息而第6步无论成功与否都会更新熔断器统计信息。
2.1.3 执行命令的几种方法
Hystrix提供了4种执行命令的方法execute()和queue() 适用于HystrixCommand对象而observe()和toObservable()适用于HystrixObservableCommand对象。
execute() 以同步堵塞方式执行run()只支持接收一个值对象。hystrix会从线程池中取一个线程来执行run()并等待返回值。
queue() 以异步非阻塞方式执行run()只支持接收一个值对象。调用queue()就直接返回一个Future对象。可通过 Future.get()拿到run()的返回结果但Future.get()是阻塞执行的。若执行成功Future.get()返回单个返回值。当执行失败时如果没有重写fallbackFuture.get()抛出异常。
observe() 事件注册前执行run()/construct()支持接收多个值对象取决于发射源。调用observe()会返回一个hot Observable也就是说调用observe()自动触发执行run()/construct()无论是否存在订阅者。
如果继承的是HystrixCommandhystrix会从线程池中取一个线程以非阻塞方式执行run()如果继承的是HystrixObservableCommand将以调用线程阻塞执行construct()。
observe()使用方法
调用observe()会返回一个Observable对象调用这个Observable对象的subscribe()方法完成事件注册从而获取结果
toObservable() 事件注册后执行run()/construct()支持接收多个值对象取决于发射源。调用toObservable()会返回一个cold Observable也就是说调用toObservable()不会立即触发执行run()/construct()必须有订阅者订阅Observable时才会执行。
如果继承的是HystrixCommandhystrix会从线程池中取一个线程以非阻塞方式执行run()调用线程不必等待run()如果继承的是HystrixObservableCommand将以调用线程堵塞执行construct()调用线程需等待construct()执行完才能继续往下走。
toObservable()使用方法
调用observe()会返回一个Observable对象调用这个Observable对象的subscribe()方法完成事件注册从而获取结果
需注意的是HystrixCommand也支持toObservable()和observe()但是即使将HystrixCommand转换成Observable它也只能发射一个值对象。只有HystrixObservableCommand才支持发射多个值对象。
几种方法的关系 execute()实际是调用了queue().get()queue()实际调用了toObservable().toBlocking().toFuture()observe()实际调用toObservable()获得一个cold Observable再创建一个ReplaySubject对象订阅Observable将源Observable转化为hot Observable。因此调用observe()会自动触发执行run()/construct()。
Hystrix总是以Observable的形式作为响应返回不同执行命令的方法只是进行了相应的转换。
3、Hystrix容错
Hystrix的容错主要是通过添加容许延迟和容错方法帮助控制这些分布式服务之间的交互。 还通过隔离服务之间的访问点阻止它们之间的级联故障以及提供回退选项来实现这一点从而提高系统的整体弹性。Hystrix主要提供了以下几种容错方法
资源隔离熔断降级
下面我们详细谈谈这几种容错机制。
3.1 资源隔离
资源隔离主要指对线程的隔离。Hystrix提供了两种线程隔离方式线程池和信号量。
3.1.1 线程隔离-线程池
Hystrix通过命令模式对发送请求的对象和执行请求的对象进行解耦将不同类型的业务请求封装为对应的命令请求。如订单服务查询商品查询商品请求-商品Command商品服务查询库存查询库存请求-库存Command。并且为每个类型的Command配置一个线程池当第一次创建Command时根据配置创建一个线程池并放入ConcurrentHashMap如商品Command
final static ConcurrentHashMapString, HystrixThreadPool threadPools new ConcurrentHashMapString, HystrixThreadPool();
...
if (!threadPools.containsKey(key)) {threadPools.put(key, new HystrixThreadPoolDefault(threadPoolKey, propertiesBuilder));
}后续查询商品的请求创建Command时将会重用已创建的线程池。线程池隔离之后的服务依赖关系 通过将发送请求线程与执行请求的线程分离可有效防止发生级联故障。当线程池或请求队列饱和时Hystrix将拒绝服务使得请求线程可以快速失败从而避免依赖问题扩散。
线程池隔离优缺点 优点
保护应用程序以免受来自依赖故障的影响指定依赖线程池饱和不会影响应用程序的其余部分。当引入新客户端lib时即使发生问题也是在本lib中并不会影响到其他内容。当依赖从故障恢复正常时应用程序会立即恢复正常的性能。当应用程序一些配置参数错误时线程池的运行状况会很快检测到这一点通过增加错误延迟超时拒绝等同时可以通过动态属性进行实时纠正错误的参数配置。如果服务的性能有变化需要实时调整比如增加或者减少超时时间更改重试次数可以通过线程池指标动态属性修改而且不会影响到其他调用请求。除了隔离优势外hystrix拥有专门的线程池可提供内置的并发功能使得可以在同步调用之上构建异步门面外观模式为异步编程提供了支持Hystrix引入了Rxjava异步框架。
注意尽管线程池提供了线程隔离我们的客户端底层代码也必须要有超时设置或响应线程中断不能无限制的阻塞以致线程池一直饱和。
缺点 线程池的主要缺点是增加了计算开销。每个命令的执行都在单独的线程完成增加了排队、调度和上下文切换的开销。因此要使用Hystrix就必须接受它带来的开销以换取它所提供的好处。 通常情况下线程池引入的开销足够小不会有重大的成本或性能影响。但对于一些访问延迟极低的服务如只依赖内存缓存线程池引入的开销就比较明显了这时候使用线程池隔离技术就不适合了我们需要考虑更轻量级的方式如信号量隔离。
3.1.2 线程隔离-信号量
上面提到了线程池隔离的缺点当依赖延迟极低的服务时线程池隔离技术引入的开销超过了它所带来的好处。这时候可以使用信号量隔离技术来代替通过设置信号量来限制对任何给定依赖的并发调用量。下图说明了线程池隔离和信号量隔离的主要区别 使用线程池时发送请求的线程和执行依赖服务的线程不是同一个而使用信号量时发送请求的线程和执行依赖服务的线程是同一个都是发起请求的线程。先看一个使用信号量隔离线程的示例
public class QueryByOrderIdCommandSemaphore extends HystrixCommandInteger {private final static Logger logger LoggerFactory.getLogger(QueryByOrderIdCommandSemaphore.class);private OrderServiceProvider orderServiceProvider;public QueryByOrderIdCommandSemaphore(OrderServiceProvider orderServiceProvider) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(orderService)).andCommandKey(HystrixCommandKey.Factory.asKey(queryByOrderId)).andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerRequestVolumeThreshold(10)至少有10个请求熔断器才进行错误率的计算.withCircuitBreakerSleepWindowInMilliseconds(5000)//熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试.withCircuitBreakerErrorThresholdPercentage(50)//错误率达到50开启熔断保护.withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE).withExecutionIsolationSemaphoreMaxConcurrentRequests(10)));//最大并发请求量this.orderServiceProvider orderServiceProvider;}Overrideprotected Integer run() {return orderServiceProvider.queryByOrderId();}Overrideprotected Integer getFallback() {return -1;}
}由于Hystrix默认使用线程池做线程隔离使用信号量隔离需要显示地将属性execution.isolation.strategy设置为ExecutionIsolationStrategy.SEMAPHORE同时配置信号量个数默认为10。客户端需向依赖服务发起请求时首先要获取一个信号量才能真正发起调用由于信号量的数量有限当并发请求量超过信号量个数时后续的请求都会直接拒绝进入fallback流程。
信号量隔离主要是通过控制并发请求量防止请求线程大面积阻塞从而达到限流和防止雪崩的目的。
线程隔离总结 线程池和信号量都可以做线程隔离但各有各的优缺点和支持的场景对比如下
线程切换支持异步支持超时支持熔断限流限流信号量否否否是是小线程池是是是是是大
线程池和信号量都支持熔断和限流。相比线程池信号量不需要线程切换因此避免了不必要的开销。但是信号量不支持异步也不支持超时也就是说当所请求的服务不可用时信号量会控制超过限制的请求立即返回但是已经持有信号量的线程只能等待服务响应或从超时中返回即可能出现长时间等待。线程池模式下当超过指定时间未响应的服务Hystrix会通过响应中断的方式通知线程立即结束并返回。
3.2 熔断
3.2.1 熔断器简介
现实生活中可能大家都有注意到家庭电路中通常会安装一个保险盒当负载过载时保险盒中的保险丝会自动熔断以保护电路及家里的各种电器这就是熔断器的一个常见例子。Hystrix中的熔断器(Circuit Breaker)也是起类似作用Hystrix在运行过程中会向每个commandKey对应的熔断器报告成功、失败、超时和拒绝的状态熔断器维护并统计这些数据并根据这些统计信息来决策熔断开关是否打开。如果打开熔断后续请求快速返回。隔一段时间默认是5s之后熔断器尝试半开放入一部分流量请求进来相当于对依赖服务进行一次健康检查如果请求成功熔断器关闭。
3.2.2 熔断器配置
Circuit Breaker主要包括如下6个参数
1、circuitBreaker.enabled
是否启用熔断器默认是TRUE。 2 、circuitBreaker.forceOpen
熔断器强制打开始终保持打开状态不关注熔断开关的实际状态。默认值FLASE。 3、circuitBreaker.forceClosed 熔断器强制关闭始终保持关闭状态不关注熔断开关的实际状态。默认值FLASE。
4、circuitBreaker.errorThresholdPercentage 错误率默认值50%例如一段时间10s内有100个请求其中有54个超时或者异常那么这段时间内的错误率是54%大于了默认值50%这种情况下会触发熔断器打开。
5、circuitBreaker.requestVolumeThreshold
默认值20。含义是一段时间内至少有20个请求才进行errorThresholdPercentage计算。比如一段时间了有19个请求且这些请求全部失败了错误率是100%但熔断器不会打开总请求数不满足20。
6、circuitBreaker.sleepWindowInMilliseconds
半开状态试探睡眠时间默认值5000ms。如当熔断器开启5000ms之后会尝试放过去一部分流量进行试探确定依赖服务是否恢复。
3.2.3 熔断器工作原理
下图展示了HystrixCircuitBreaker的工作原理 熔断器工作的详细过程如下
第一步调用allowRequest()判断是否允许将请求提交到线程池
如果熔断器强制打开circuitBreaker.forceOpen为true不允许放行返回。如果熔断器强制关闭circuitBreaker.forceClosed为true允许放行。此外不必关注熔断器实际状态也就是说熔断器仍然会维护统计数据和开关状态只是不生效而已。
第二步调用isOpen()判断熔断器开关是否打开
如果熔断器开关打开进入第三步否则继续如果一个周期内总的请求数小于circuitBreaker.requestVolumeThreshold的值允许请求放行否则继续如果一个周期内错误率小于circuitBreaker.errorThresholdPercentage的值允许请求放行。否则打开熔断器开关进入第三步。
第三步调用allowSingleTest()判断是否允许单个请求通行检查依赖服务是否恢复
如果熔断器打开且距离熔断器打开的时间或上一次试探请求放行的时间超过circuitBreaker.sleepWindowInMilliseconds的值时熔断器器进入半开状态允许放行一个试探请求否则不允许放行。
此外为了提供决策依据每个熔断器默认维护了10个bucket每秒一个bucket当新的bucket被创建时最旧的bucket会被抛弃。其中每个blucket维护了请求成功、失败、超时、拒绝的计数器Hystrix负责收集并统计这些计数器。
3.2.4 熔断器测试
1、以QueryOrderIdCommand为测试command
2、配置orderServiceProvider不重试且500ms超时
dubbo:reference idorderServiceProvider interfacecom.huang.provider.OrderServiceProvidertimeout500 retries0/3、OrderServiceProviderImpl实现很简单前10个请求服务端休眠600ms使得客户端调用超时。
Service
public class OrderServiceProviderImpl implements OrderServiceProvider {private final static Logger logger LoggerFactory.getLogger(OrderServiceProviderImpl.class);private AtomicInteger OrderIdCounter new AtomicInteger(0);Overridepublic Integer queryByOrderId() {int c OrderIdCounter.getAndIncrement();if (logger.isDebugEnabled()) {logger.debug(OrderIdCounter:{}, c);}if (c 10) {try {Thread.sleep(600);} catch (InterruptedException e) {}}return c;}Overridepublic void reset() {OrderIdCounter.getAndSet(0);}
}4、单测代码
Test
public void testExecuteCommand() throws InterruptedException {orderServiceProvider.reset();int i 1;for (; i 15; i) {HystrixCommandInteger command new QueryByOrderIdCommand(orderServiceProvider);Integer r command.execute();String method r -1 ? fallback : run;logger.info(call {} times,result:{},method:{},isCircuitBreakerOpen:{}, i, r, method, command.isCircuitBreakerOpen());}//等待6s使得熔断器进入半打开状态Thread.sleep(6000);for (; i 20; i) {HystrixCommandInteger command new QueryByOrderIdCommand(orderServiceProvider);Integer r command.execute();String method r -1 ? fallback : run;logger.info(call {} times,result:{},method:{},isCircuitBreakerOpen:{}, i, r, method, command.isCircuitBreakerOpen());}
}
5、输出结果
2018-02-07 11:38:36,056 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 1 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:36,564 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 2 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:37,074 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 3 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:37,580 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 4 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:38,089 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 5 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:38,599 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 6 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:39,109 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 7 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:39,622 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 8 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:40,138 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 9 times,result:-1,method:fallback,isCircuitBreakerOpen:false
2018-02-07 11:38:40,647 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 10 times,result:-1,method:fallback,isCircuitBreakerOpen:true
2018-02-07 11:38:40,651 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 11 times,result:-1,method:fallback,isCircuitBreakerOpen:true
2018-02-07 11:38:40,653 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 12 times,result:-1,method:fallback,isCircuitBreakerOpen:true
2018-02-07 11:38:40,656 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 13 times,result:-1,method:fallback,isCircuitBreakerOpen:true
2018-02-07 11:38:40,658 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:36 call 14 times,result:-1,method:fallback,isCircuitBreakerOpen:true
2018-02-07 11:38:46,671 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:44 call 15 times,result:10,method:run,isCircuitBreakerOpen:false
2018-02-07 11:38:46,675 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:44 call 16 times,result:11,method:run,isCircuitBreakerOpen:false
2018-02-07 11:38:46,680 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:44 call 17 times,result:12,method:run,isCircuitBreakerOpen:false
2018-02-07 11:38:46,685 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:44 call 18 times,result:13,method:run,isCircuitBreakerOpen:false
2018-02-07 11:38:46,691 INFO [main] com.huang.test.command.QueryByOrderIdCommandTest:testExecuteCommand:44 call 19 times,result:14,method:run,isCircuitBreakerOpen:false
前9个请求调用超时走fallback逻辑
10-14个请求熔断器开关打开直接快速失败走fallback逻辑
15-19个请求熔断器进入半开状态放行一个试探请求调用成功熔断器关闭后续请求恢复。
3.3 回退降级
降级通常指务高峰期为了保证核心服务正常运行需要停掉一些不太重要的业务或者某些服务不可用时执行备用逻辑从故障服务中快速失败或快速返回以保障主体业务不受影响。Hystrix提供的降级主要是为了容错保证当前服务不受依赖服务故障的影响从而提高服务的健壮性。要支持回退或降级处理可以重写HystrixCommand的getFallBack方法或HystrixObservableCommand的resumeWithFallback方法。
Hystrix在以下几种情况下会走降级逻辑
执行construct()或run()抛出异常熔断器打开导致命令短路命令的线程池和队列或信号量的容量超额命令被拒绝命令执行超时
3.3.1 降级回退方式
Fail Fast 快速失败 快速失败是最普通的命令执行方法命令没有重写降级逻辑。 如果命令执行发生任何类型的故障它将直接抛出异常。
Fail Silent 无声失败 指在降级方法中通过返回null空Map空List或其他类似的响应来完成。
Override
protected Integer getFallback() {return null;
}Override
protected ListInteger getFallback() {return Collections.emptyList();
}Override
protected ObservableInteger resumeWithFallback() {return Observable.empty();
}
Fallback: Static 指在降级方法中返回静态默认值。 这不会导致服务以“无声失败”的方式被删除而是导致默认行为发生。如应用根据命令执行返回true / false执行相应逻辑但命令执行失败则默认为true
Override
protected Boolean getFallback() {return true;
}
Override
protected ObservableBoolean resumeWithFallback() {return Observable.just( true );
}Fallback: Stubbed
当命令返回一个包含多个字段的复合对象时适合以Stubbed 的方式回退。
Override
protected MissionInfo getFallback() {return new MissionInfo(missionName,error);
}Fallback: Cache via Network 有时如果调用依赖服务失败可以从缓存服务如redis中查询旧数据版本。由于又会发起远程调用所以建议重新封装一个Command使用不同的ThreadPoolKey与主线程池进行隔离。
Override
protected Integer getFallback() {return new RedisServiceCommand(redisService).execute();
}Primary Secondary with Fallback 有时系统具有两种行为- 主要和次要或主要和故障转移。主要和次要逻辑涉及到不同的网络调用和业务逻辑所以需要将主次逻辑封装在不同的Command中使用线程池进行隔离。为了实现主从逻辑切换可以将主次command封装在外观HystrixCommand的run方法中并结合配置中心设置的开关切换主从逻辑。由于主次逻辑都是经过线程池隔离的HystrixCommand因此外观HystrixCommand可以使用信号量隔离而没有必要使用线程池隔离引入不必要的开销。原理图如下 主次模型的使用场景还是很多的。如当系统升级新功能时如果新版本的功能出现问题通过开关控制降级调用旧版本的功能。示例代码如下
public class CommandFacadeWithPrimarySecondary extends HystrixCommandString {private final static DynamicBooleanProperty usePrimary DynamicPropertyFactory.getInstance().getBooleanProperty(primarySecondary.usePrimary, true);private final int id;public CommandFacadeWithPrimarySecondary(int id) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(SystemX)).andCommandKey(HystrixCommandKey.Factory.asKey(PrimarySecondaryCommand)).andCommandPropertiesDefaults(// 由于主次command已经使用线程池隔离Facade Command使用信号量隔离即可HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)));this.id id;}Overrideprotected String run() {if (usePrimary.get()) {return new PrimaryCommand(id).execute();} else {return new SecondaryCommand(id).execute();}}Overrideprotected String getFallback() {return static-fallback- id;}Overrideprotected String getCacheKey() {return String.valueOf(id);}private static class PrimaryCommand extends HystrixCommandString {private final int id;private PrimaryCommand(int id) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(SystemX)).andCommandKey(HystrixCommandKey.Factory.asKey(PrimaryCommand)).andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey(PrimaryCommand)).andCommandPropertiesDefaults( HystrixCommandProperties.Setter().withExecutionTimeoutInMilliseconds(600)));this.id id;}Overrideprotected String run() {return responseFromPrimary- id;}}private static class SecondaryCommand extends HystrixCommandString {private final int id;private SecondaryCommand(int id) {super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(SystemX)).andCommandKey(HystrixCommandKey.Factory.asKey(SecondaryCommand)).andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey(SecondaryCommand)).andCommandPropertiesDefaults( HystrixCommandProperties.Setter().withExecutionTimeoutInMilliseconds(100)));this.id id;}Overrideprotected String run() {return responseFromSecondary- id;}}public static class UnitTest {Testpublic void testPrimary() {HystrixRequestContext context HystrixRequestContext.initializeContext();try {ConfigurationManager.getConfigInstance().setProperty(primarySecondary.usePrimary, true);assertEquals(responseFromPrimary-20, new CommandFacadeWithPrimarySecondary(20).execute());} finally {context.shutdown();ConfigurationManager.getConfigInstance().clear();}}Testpublic void testSecondary() {HystrixRequestContext context HystrixRequestContext.initializeContext();try {ConfigurationManager.getConfigInstance().setProperty(primarySecondary.usePrimary, false);assertEquals(responseFromSecondary-20, new CommandFacadeWithPrimarySecondary(20).execute());} finally {context.shutdown();ConfigurationManager.getConfigInstance().clear();}}}
}
通常情况下建议重写getFallBack或resumeWithFallback提供自己的备用逻辑但不建议在回退逻辑中执行任何可能失败的操作。
4、总结
本文介绍了Hystrix及其工作原理还介绍了Hystrix线程池隔离、信号量隔离和熔断器的工作原理以及如何使用Hystrix的资源隔离熔断和降级等技术实现服务容错从而提高系统的整体健壮性。
Hystrix主要用来做容错处理提高系统的整体弹性。
资源隔离主要是线程隔离通过线程池或信号量实现熔断(负载过载的时候熔断然后超时后自动半打开恢复)回退降级(Hystrix提供的降级主要是为了容错保证当前服务不受依赖服务故障的影响从而提高服务的健壮性。)
Hystrix git wiki介绍
https://github.com/Netflix/Hystrix/wiki/How-it-Works
