服务熔断、服务降级，好高大上的样子，以前望尘莫及，今日终于揭开它神秘面纱，好好应用一把了。
了解这两者之前，我们首先要了解是产生什么问题了，才需要熔断、降级。
服务雪崩
分布式系统面临的问题是，复杂分布式体系结构中的应用有十多个依赖关系，每个依赖在某些时候将不可避免的失败。
容器中一个请求需要调用A,P,H,I，如果I服务超时会出现什么情况呢？一次这样，如果上万次呢，会导致雪崩。
- 服务雪崩
多个微服务间调用，假设A调B，B调C，C调其他，这就是“扇出”，如果扇出的链路上某个微服务的调用响应时间过长或不可用，对微服务A的调用会占用越来越多的资源，进而引起“雪崩效应”。
对于高流量来说，单一后端依赖可能导致所有服务器上的所有资源都在几秒内饱和，比失败更糟糕的是，这些应用程序还可能导致服务间延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
服务熔断
一般是某个服务故障或异常引起，类似“保险丝”，当某个异常被触发，直接熔断整个服务，而不是等到此服务超时。
服务降级
降级是在客户端，与服务端无关。
降级，从整体负荷考虑，某个服务熔断后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，这样，虽然服务水平下降，但可用，比直接挂掉要好。
当整体资源快不够了，先将某些服务关掉，待度过难关，再开启。
服务熔断与降级，我们用的是Hystrix，如何使用呢，我们下篇见，欢迎来访。