概述
Hystrix采取了舱壁隔离技术对外部依赖进行资源隔离，从而避免任何外部依赖的故障导致本服务崩溃。
Hystrix对每个外部依赖用一个单独的线程池，因此，外部依赖的调用在单独的线程中执行，这样就能跟调用线程隔离开来，即使对那个外部依赖调用延迟很严重，最多就是耗尽那个依赖自己的线程池而已，不会影响其他的依赖调用。
线程池隔离技术的设计原则
Hystrix选择用线程池机制来进行资源隔离，要面对的场景如下：
（1）每个服务都会调用几十个后端依赖服务，那些后端依赖服务通常是由很多不同的团队开发的
（2）每个后端依赖服务都会提供它自己的client调用库，比如说用thrift的话，就会提供对应的thrift依赖
（3）client调用库随时会变更
（4）client调用库随时可能会增加新的网络请求的逻辑
（5）client调用库可能会包含诸如自动重试，数据解析，内存中缓存等逻辑
（6）client调用库一般都对调用者来说是个黑盒，包括实现细节，网络访问，默认配置，等等
（7）在真实的生产环境中，经常会出现调用者，突然间惊讶的发现，client调用库发生了某些变化
（8）即使client调用库没有改变，依赖服务本身可能有会发生逻辑上的变化
（9）有些依赖的client调用库可能还会拉取其他的依赖库，而且可能那些依赖库配置的不正确
（10）大多数网络请求都是同步调用的
（11）调用失败和延迟，也有可能会发生在client调用库本身的代码中，不一定就是发生在网络请求中
总的来说，就是默认client调用库就很不靠谱，而且随时可能会有各种变化，所以就要用强制隔离的方式来确保任何服务的故障不能影响当前服务。
线程池机制的优点
线程池机制的优点如下：
（1）任何一个依赖服务都可以被隔离在自己的线程池内，即使自己的线程池资源填满了，也不会影响任何其他的服务调用
（2）服务可以随时引入一个新的依赖服务，因为即使这个新的依赖服务有问题，也不会影响其他任何服务的调用
（3）当一个故障的依赖服务重新变好的时候，可以通过清理掉线程池，瞬间恢复该服务的调用，而如果是tomcat线程池被占满，再恢复就很麻烦
（4）如果一个client调用库配置有问题，线程池的健康状况随时会报告，比如成功/失败/拒绝/超时的次数统计，然后可以近实时热修改依赖服务的调用配置，而不用停机
（5）如果一个服务本身发生了修改，需要重新调整配置，此时线程池的健康状况也可以随时发现，比如成功/失败/拒绝/超时的次数统计，然后可以近实时热修改依赖服务的调用配置，而不用停机
（6）基于线程池的异步本质，可以在同步的调用之上，构建一层异步调用层
总的来说，线程池机制最大的好处就是资源隔离，即使任何一个依赖服务故障，不会拖垮当前的服务。
线程池机制的缺点
线程池机制的缺点：
（1）线程池机制最大的缺点就是增加了cpu的开销
除了tomcat本身的调用线程之外，还有hystrix自己管理的线程池
（2）每个command的执行都依托一个独立的线程，会进行排队，调度，还有上下文切换
（3）Hystrix官方自己做了一个多线程异步带来的额外开销，通过对比多线程异步调用+同步调用得出，Netflix API每天通过hystrix执行10亿次调用，每个服务实例有40个以上的线程池，每个线程池有10个左右的线程
（4）最后发现说，用hystrix的额外开销，就是给请求带来了3ms左右的延时，最多延时在10ms以内，相比于可用性和稳定性的提升，这是可以接受的
sempahore技术
一般情况下，采用hystrix semaphore技术来实现对某个依赖服务的并发访问量的限制，而不是通过线程池/队列的大小来限制流量。
sempahore技术可以用来限流和削峰，但是不能用来对调研延迟的服务进行timeout和隔离。
如果通过semaphore调用的时候，底层的网络调用延迟很严重，那么是无法timeout的，只能一直堵塞住。
一旦请求数量超过了semephore限定的数量之后，就会立即开启限流。
