Spring Cloud (8) 服务容错保护-Hystrix依赖隔离

依赖隔离

　　docker使用舱壁模式来实现进程的隔离，使容器与容器之间不会互相影响。而Hystrix则使用该模式实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算在某个Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他业务。

 

通过对依赖服务的线程池隔离实现，可以带来如下优势：

 

　　应用自身得到完全的保护，不会受不可控的依赖服务影响。即便给依赖服务分配的线程池填满，也不会影响应用自身的其余部分。

　　可以有效的降低接入新服务的风险。如果新服务接入后运行不稳定或存在问题，完全不会影响到其他的请求。

　　当依赖的服务从失效恢复正常后，它的线程池会被清理并且能够马上恢复健康的服务，相比之下容器级别的清理恢复速度要满的多。

　　当依赖的服务出现配置错误的时候，线程池会快速的反映出此问题（通过失败次数、延迟、超时、拒绝等指标的增加情况）。同时，我们可以在不影响应用功能的情况下通过实施的动态属性刷新来处理它。

　　当依赖的服务因实现机制等原因造成其性能出现很大变化的时候，此时线程池的监控指标信息会反映出这样的变化。同时，我们也可以通过实时动态刷新自身应用对依赖服务的阈值进行调整以适应依赖方的改变。

　　除了上面通过线程池隔离服务发挥的优点之外，每个转悠线程池都提供了内置的并发实现，可以利用它为同步的依赖服务构建异步的访问。

 

总之，通过对依赖服务实现线程池隔离，让我们的应用更加强健，不会因为个别依赖服务出现问题而引起非相关服务的异常，同时，也使得我们的应用变得更加灵活，可以在不停止服务的情况下，配合动态配置刷新实现配置上的调整。

 

虽然线程池隔离的方案带了如此多的好处，但是很多使用者可能会担心为每一个依赖服务都分配一个线程池是否会过多地增加系统的负载和开销。对于这一点，使用者不用过于担心，因为这些顾虑也是大部分工程师们会考虑到的，Netflix在设计Hystrix的时候，认为线程池上的开销相对于隔离所带来的好处是无法比拟的。同时，Netflix也针对线程池的开销做了相关的测试，以证明和打消Hystrix实现对性能影响的顾虑。

 

在上一篇中，我们使用@HystrixCommand来讲某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架救护i的为这个函数实现调用的隔离。所以，依赖隔离、服务降级在使用时候都是一体化实现的，这样利用Hystrix来实现服务容错保护在编程模型上就非常方便的，并且考虑更为全面。除了依赖隔离、服务降级之外，还有一个重要元素：断路器。