SpringCloud的Hystrix的降级和熔断的理解

对于某一服务A发生的异常，可以有两种处理机制
特别的提一下，可能的异常有：
1、调用其他服务时发生的异常：比如被调用服务已关闭，或被调用的服务发生异常、超时等
2、处理自身业务时发生的异常：比如空指针异常

一、由服务A自己处理，此即服务熔断

优点：1、消费者除了会遇到服务A关闭所导致的异常外，基本上不会再遇到其他类型的异常（默认都被服务A捕获了）
缺点：需要逐个方法添加fallback函数，造成代码过多，且与controller层耦合度过高

二、由调用服务A的消费者处理，此即服务降级

优点：可以与Feign结合，独立处理调用A时发生的异常，实现与Controller层的分离
缺点：可能无法识别服务A到底发生了哪种异常，只是知道调用服务A会出错

如果两者结合使用，所有服务A发生的所有异常都会被处理，包括服务A已经预料到的，和A未预料到的。
但其实服务降级就已经能处理所有调用A时所发生的所有异常。但若调用服务A的服务（假设为服务B），为最终客户端，则只能采取服务熔断，以避免自身自身发生的异常直接表现给用户（即人），不过其实人类也自备了服务降级机制，“我绝对不会再用这个东西了!~~~”

简单的类比来说：
服务熔断就是try…catch
服务降级则是 throws

微总结：

服务熔断是服务方，为了处理自身可能发生的异常，而提前准备的异常处理机制

服务降级则是，请求服务方，即消费者方，为了处理服务方提供服务时发生的异常，而提前准备的异常处理机制