Hystrix-基本概念（设计原则和两种隔离技术）

一、Hystrix是什么
在微服务的架构系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务。有的时候某些依赖服务出现故障也是很正常的。Hystrix可以让我们在对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。Hystrix通过将依赖服务进行资源隔离，进而组织某个依赖服务出现故障的时候，这种故障在整个系统所有的依赖服务调用中进行蔓延，同时Hystrix还提供故障时的fallback降级机制。总而言之，Hystrix通过这些方法帮助我们提升系统的可用性和稳定性。

二、Hystrix为了实现高可用性的架构，设计hystrix的时候，一些设计原则是什么
（1）对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护。
（2）阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整个系统全部故障，整体宕机。
（3）提供fail-fast（快速失败）和快速恢复的支持。
（4）提供fallback优雅降级的支持。
（5）支持近实时的监控、报警以及运维操作。

三、Hystrix是如何实现它的目标的
（1）通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离。
（2）对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。
（3）为每一个依赖服务维护一个独立的线程池或者是semaphore（信号量），当线程池已满时，直接拒绝对这个服务的调用。
（4）对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计。
（5）如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复。
（6）当一个服务调用出现失败、被拒绝、超时、短路等异常情况时，自动调用fallback降级机制。
（7）对属性和配置的修改提供近实时的支持。

四、Hystrix两种隔离技术
Hystrix里核心的一项功能就是所谓的资源隔离，要解决的最最核心的问题，就是将多个依赖服务的调用分别隔离到各自自己的资源池内。避免说对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上。一旦说某个服务的线程资源全部耗尽的话，可能就导致服务就会崩溃，甚至说这种故障会不断蔓延。资源隔离的两种技术：线程池的资源隔离、信号量的资源隔离。

五、线程池隔离技术和信号量隔离技术，分别在什么样的场景下去使用
线程池：适合绝大多数的场景，线程池资源隔离一般用于对依赖服务的网络请求的调用和访问，timeout这种问题。每个command运行在一个线程中，限流是通过线程池的大小进行控制的。
信号量：适合对内部的一些比较复杂的业务逻辑的访问，但是像这种访问，系统内部的代码其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获timeout类似的问题，算法+数据结构的效率不是太高，并发量突然太高，因为这里稍微耗时一些，导致很多线程卡在这里的话，不太好，所以进行一个基本的资源隔离和访问，避免内部复杂的低效率的代码，导致大量的线程被hang住。command是运行在调用线程中，但是通过信号量的容量来进行限流。

————————————————
版权声明：本文为CSDN博主「Anbang713」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Anbang713/article/details/85591774