Home > Archives > 微服务:服务熔断和服务降级

微服务:服务熔断和服务降级

Publish:

伴随着微服务架构被宣传得如火如荼,一些概念也被推到了我们面前(管你接受不接受),其实大多数概念以前就有,但很少被提的这么频繁(现在好像不提及都不好意思交流了)。想起有人总结的一句话,微服务架构的特点就是:“一解释就懂,一问就不知,一讨论就吵架”。

其实对老外的总结能力一直特别崇拜,Kevin Kelly、Martin Fowler、Werner Vogels……,都是著名的“演讲家”。正好这段时间看了些微服务、容器的相关资料,也在我们新一代产品中进行了部分实践,回过头来,再来谈谈对一些概念的理解。

一、“服务熔断”和“服务降级”

今天先来说说“服务熔断”和“服务降级”。为什么要说这个呢,因为我很长时间里都把这两个概念同质化了,不知道这两个词大家怎么理解,一个意思or有所不同?现在的我是这么来看的:

两个示例:

示例1:

故事的背景是这样的:由于小强在工作中碰到一些问题,于是想请教一下业界大牛小壮。于是发生了下面的两个场景:

小强在拿起常用手机拨号时发现该手机没有能够拨通,所以就拿出了备用手机拨通了某A的电话,这个过程就叫做降级(主逻辑失败采用备用逻辑的过程)。

由于每次小壮的解释都属于长篇大论,不太容易理解,所以小强每次找小壮沟通的时候都希望通过常用手机来完成,因为该手机有录音功能,这样自己可以慢慢消化。由于上一次的沟通是用备用电话完成的,小强又碰到了一些问题,于是他又尝试用常用电话拨打,这一次又没有能够拨通,所以他不得不又拿出备用手机给某A拨号,就这样连续的经过了几次在拨号设备选择上的“降级”,小强觉得短期内常用手机可能因为运营商问题无法正常拨通了,所以,再之后一段时间的交流中,小强就不再尝试用常用手机进行拨号,而是直接用备用手机进行拨号,这样的策略就是熔断(常用手机因短期内多次失败,而被暂时性的忽略,不再尝试使用)

示例2:

所以从上述分析来看,两者其实从有些角度看是有一定的类似性的:

而两者的区别也是明显的:

二、熔断器的状态机

当然这只是我个人对两者的理解,外面把两者归为完全一致的也不在少数,或者把熔断机制理解为应对降级目标的一种实现也说的过去,可能“一讨论就吵架”也正是这个原因吧!

概念算是说完了,避免空谈,我再总结下对常用的实现方法的理解。对于这两个概念,号称支持的框架可不少,Hystrix当属其中的佼佼者。

先说说最裸的熔断器的设计思路,下面这张图大家应该不陌生(我只是参考着又画了画),简明扼要的给出了好的熔断器实现的三个状态机:

那Hystrix,作为Netflix开源框架中的最受喜爱组件之一,是怎么处理依赖隔离,实现熔断机制的呢,他的处理远比我上面说个实现机制复杂的多,一起来看看核心代码吧,我只保留了代码片段的关键部分:


public abstract class HystrixCommand<R> extends AbstractCommand<R> implements HystrixExecutable<R>, HystrixInvokableInfo<R>, HystrixObservable<R> {  
  
	protected abstract R run() throws Exception;  
  
	protected R getFallback() {  
		throw new UnsupportedOperationException("No fallback available.");  
	}  
  
	@Override  
	final protected Observable<R> getExecutionObservable() {  
		return Observable.defer(new Func0<Observable<R>>() {  
			@Override  
			public Observable<R> call() {  
				try {  
					return Observable.just(run());  
				} catch (Throwable ex) {  
					return Observable.error(ex);  
				}  
			}  
		});  
	}  
  
	@Override  
	final protected Observable<R> getFallbackObservable() {  
		return Observable.defer(new Func0<Observable<R>>() {  
			@Override  
			public Observable<R> call() {  
				try {  
					return Observable.just(getFallback());  
				} catch (Throwable ex) {  
					return Observable.error(ex);  
				}  
			}  
		});  
	}  
  
	public R execute() {  
		try {  
			return queue().get();  
		} catch (Exception e) {  
			throw decomposeException(e);  
		}  
	}  

HystrixCommand是重重之重,在Hystrix的整个机制中,涉及到依赖边界的地方,都是通过这个Command模式进行调用的,显然,这个Command负责了核心的服务熔断和降级的处理,子类要实现的方法主要有两个:

使用时,可参考如下方式:


public class TestCommand extends HystrixCommand<String> {  
  
	protected TestCommand(HystrixCommandGroupKey group) {  
		super(group);  
	}  
  
	@Override  
	protected String run() throws Exception {  
		//这里需要做实际调用逻辑  
		return "Hello";  
	}  
	  
	public static void main(String[] args) throws InterruptedException, ExecutionException, TimeoutException {  
		TestCommand command = new TestCommand(HystrixCommandGroupKey.Factory.asKey("TestGroup"));  
		  
		//1.这个是同步调用  
		command.execute();  
		  
		//2.这个是异步调用  
		command.queue().get(500, TimeUnit.MILLISECONDS);  
		  
		//3.异步回调  
		command.observe().subscribe(new Action1<String>() {  
			public void call(String arg0) {  
				  
			}  
		});  
	}  
}  

细心的同学肯定发现Command机制里大量使用了Observable相关的API,这个是什么呢?原来其隶属于RxJava,这个框架就不多介绍了 — 响应式开发,也是Netflix的作品之一,具体大家可参考这系列博客,我觉得作者写的很通俗:http://blog.csdn.net/lzyzsd/article/details/41833541/

接着呢,大家一定会问,那之前说的熔断阈值设置等,都在哪块做的呢?再来看看另一块核心代码:


public abstract class HystrixPropertiesStrategy {  
  
	public HystrixCommandProperties getCommandProperties(HystrixCommandKey commandKey, HystrixCommandProperties.Setter builder) {  
		return new HystrixPropertiesCommandDefault(commandKey, builder);  
	}  
  
	......  
}  

这个类作为策略类,返回相关的属性配置,大家可重新实现。而在具体的策略中,主要包括以下几种策略属性配置:

属性很多,这里就不一一说明了,大家可参考HystrixCommandProperties类里的详细定义。还有一点要着重说明的,在熔断器的设计里,隔离采用了线程的方式(据说还有信号的方式,这两个区别我还没搞太明白),处理依赖并发和阻塞扩展,示意图如下:

如上图,好处也很明显,对于每个依赖都有独立可控的线程池,当然高并发时,CPU切换较多,有一定的影响。

啰嗦了一堆,最后总结一下,我认为服务熔断和服务降级两者是有区别的,同时通过对Hystrix的简单学习,了解了其实现机制,会逐步引入到我们的产品研发中。当然还有好多概念:服务限流、分流,请求与依赖分离等,后面有时间一一与大家分享。

参考

声明: 本文采用 BY-NC-SA 授权。转载请注明转自: Ding Bao Guo