hystrix实战--why hystrix？

背景：

在分布式服务架构中，可能会调用很多的远程服务来完成一个业务流程。
如果某一个依赖服务有问题；在高并发大数据量的场景下，很多应用服务器（比如tomcat）内部的线程就会卡死在这个调用服务上。

更坏的情况，会有越来越多的线程进入等待中；导致没有额外的线程处理该服务中其他的业务接口；进而导致整个服务不可用。

如果他本身也是个底层服务，被很多其他服务依赖，那么就可能会导致整个平台的不可用。

虽然对于调用方来说，可以设置超时时间的机制来推出本次请求，但这个其实也不能解决服务端本身的压力。

举个例子，比如是一个app网关，他本身依赖了N多的底层业务系统，对上层的APP端提供对应的业务支撑。如果说他不做任何的保护措施，那将非常的可怕，服务的健壮性很难保证，如果是其他的一个业务接口不可用，导致调用的延迟，超时，可能会影响其他业务接口，因为所有的接口都是部署在一个tomcat 容器集群中，然而容器的线程资源也是有限的；所以就可能会出现整个app网关的直接不可用，可想而知，情况是多么的糟糕。

如果解决以上的困境？

高可用如何保证？

这时候我们就引入一个资源隔离的概念，其实算是一个抽象的概念，也就是说我们需要把某一个依赖服务的调用请求都封装在同一个资源池内；全部走这个资源池的资源；hsstrix提供了一个抽象的概念（command）,每次请求都是封装成一个command来调用资源池中的一个线程资源去执行。

如果我们的服务实现了资源隔离的功能，那就不需要每天担心受怕，不需要害怕自己的服务的线程资源全部耗尽，导致服务不可用。虽然不能完全防止雪崩的发生，但是能够保证服务的调用方在发送雪崩的时候自己不会被卡死。