雪崩效应
现如今SOA、微服务风愈演愈烈，越来越多的业务和资源被以服务的形式包装和发布，服务间又可能会依赖其他各种服务。由此而来不可避免的会产生很多问题。
比如一个服务，其依赖了另外30个服务。假设每个服务的可用率都有三个9（99.9%），那么我们计算一下：
99.99%^30 = 99.7%
现实很残酷，这个服务的实际可用性只能是99.7%，也就是说每个月这个服务都要好宕机8000+秒~~~
正常用户请求时，服务内部依次请求A\P\H\I服务，兵返回响应结果。
非常不幸，我们的I服务出了某些问题，此时我们的用户请求就被堵塞在I服务处。
更加悲剧的是，后续越来越多的请求都被堵塞在I服务处，而这些被堵塞的请求会占用线程、IO、网络等系统资源，随着资源被占用的越来越多，本来不存在的性能问题也会随之而来，造成系统中的其他服务出现问题，甚至导致系统奔溃。
这也就是我们常说的雪崩效应
服务容灾
为了避免出现服务的雪崩，我们需要对服务做容灾处理。
常规的服务容灾处理思路有：
-
资源隔离
-
超时设定
-
服务降级
- 服务限流
其中每种思路又可以有不同的解决方案。
比如资源隔离可以通过将不同的服务发布在独立的docker容器或服务器中，这样即使一个服务出现问题，也不会殃及池鱼。
服务降级和服务限流可以通过前端nginx+lua来实现，当服务处理延迟或宕机时，nginx可以直接返回固定的降级/失败响应，已快速跳过问题服务。
Hystrix
Hystrix，是Netflix的一个开源熔断器，通过Hystrix，我们可以很方便的实现资源隔离、限流、超时设计、服务降级等服务容灾措施，并且还提供了强大的监控，可以查看各个熔断器的允许情况。
通过上图，可以看出，Hystrix提供了一个HystrixCommand用来包装调用请求。HystrixCommand的执行流程大概如下：
1.首先检查缓存中是否有结果。如果有则直接返回缓存结果。
2.判断断路器是否开启，如果断路器闭合，执行降级业务逻辑并返回降级结果。
3.
