谈谈我对服务熔断、服务降级的理解

1. 在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。
2. 大家都见过女生旅行吧，大号的旅行箱是必备物，平常走走近处绰绰有余，但一旦出个远门，再大的箱子都白搭了，怎么办呢？常见的情景就是把物品拿出来分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子够用了，再带上用一用。而服务降级，就是这么回事，整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

1. 目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
2. 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
3. 粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
4. 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

1. 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
2. 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
3. 实现方式不太一样，这个区别后面会单独来说；

1. Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制；
2. Open：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），到了这个时间，进入半熔断状态；
3. Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态；

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负责了核心的服务熔断和降级的处理，子类要实现的方法主要有两个：

1. run方法：实现依赖的逻辑，或者说是实现微服务之间的调用；
2. getFallBack方法：实现服务降级处理逻辑，只做熔断处理的则可不实现；

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) {
				
			}
		});
	}
}

public abstract class HystrixPropertiesStrategy {

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

    ......
}

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

1. circuitBreakerEnabled：是否允许熔断，默认允许；
2. circuitBreakerRequestVolumeThreshold：熔断器是否开启的阀值，也就是说单位时间超过了阀值请求数，熔断器才开；
3. circuitBreakerSleepWindowInMilliseconds：熔断器默认工作时间，超过此时间会进入半开状态，即允许流量做尝试；
4. circuitBreakerErrorThresholdPercentage：错误比例触发熔断；
5. ……

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