现在对于各个公司，大多将服务不断拆分，一方面使用RPC实现服务化，另一方面各个RPC循环调用，导致服务异常复杂。稍有不慎就会发生雪崩式的崩溃，所以hystrix应运而生。今天就学习一下服务的熔断、降级。
我们的某个业务流程依赖于30个外部服务，每个服务可靠率为99.99%，但是30个服务叠加起来可考虑只能是99.7%，也就是意味着我们某个QPS为50的接口，每天就有21个请求出错。
更严重的是，我们这依赖了这30个服务，只要其中一个服务超时无响应，就会导致我们当前所有流程停下来了。也就是说，很快我们的线程都会被block，都挂起了导致不能再处理新的请求。
再某次故障中，就是因为强依赖了一个外部门接口挂了，导致所有线程池被打满，导致了雪崩式的崩溃，这段时间内所有业务都挂了。
那我们来讲讲什么是熔断，什么是降级。
降级
服务降级就是主逻辑失败，使用备用逻辑的过程。
比如说那次故障中，那个接口本质是调一个库查询一个数据，但是我们作为业务方，我们可以维护一个备用库（这个库平时可能不使用），这个库数据可能不是最新，但是保证大部分都是正确的。这样，他们再次出问题时候，我们可以使用我们的备用逻辑，保证我们的服务不会因此全量崩溃。
再举个例子，假定我们的系统只能支撑1000QPS，但是产品说，我们要进行一次秒杀。对于我们系统支付流程来说，计算订单总价的很重要，但是计算订单的详细信息是可有可无。所以我们就可以通过停掉详细信息的接口的方式，来保证我们再用户支付时候能正常把钱收回来。
针对我们后端应用，我们可以使用一下策略来进行服务降级：
- 抛异常
- 返回NULL
- 调用Mock数据
- 调用Fallback处理逻辑
熔断
熔断，顾名思义，我们引入了类似于保险丝的机制，当某个服务超时了，直接停掉这个服务，不再调用，以免影响所有服务。
我们使用股市熔断作为类比
股票市场的交易时间中，当价格波动的幅度达到某一个限定的目标（熔断点）时，对其暂停交易一段时间的机制。
当然不是所有的服务都能进行熔断，比如那次故障的系统要是熔断了，我们的的整个流程也没得玩了。
通常，最简单的熔断器分为一下三种状态：
- Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制；
- Open：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），到了这个时间，进入半熔断状
- Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态；
