Hystrx权威指南--Hystrix实现原理

1.Hystrix中的命令模式

将所有请求外部系统（或者叫依赖服务）的逻辑封装到 HystrixCommand或者HystrixObservableCommand（依赖RxJava）对象中

Run()方法为要实现的业务逻辑，这些逻辑将会在独立的线程中被执行

当请求依赖服务时出现拒绝服务、超时或者短路（多个依赖服务顺序请求，前面的依赖服务请求失败，则后面的请求不会发出）时，执行该依赖服务的失败回退逻辑(Fallback)

2.隔离策略

应用在复杂的分布式结构中，可能会依赖许多其他的服务，并且这些服务都不可避免地有失效的可能。如果一个应用没有与依赖服务的失效隔离开来，那么它将有可能因为依赖服务的失效而失效。

Hystrix为每一个依赖服务维护一个线程池（或者信号量），当线程池占满，该依赖服务将会立即拒绝服务而不是排队等待。

每个依赖服务都被隔离开来，Hystrix 会严格控制其对资源的占用，并在任何失效发生时，执行失败回退逻辑。

3.观察者模式

Hystrix通过观察者模式对服务进行状态监听。

每个任务都包含有一个对应的Metrics，所有Metrics都由一个ConcurrentHashMap来进行维护，Key是CommandKey.name()。 

在任务的不同阶段会往Metrics中写入不同的信息，Metrics会对统计到的历史信息进行统计汇总，供熔断器使用。

Metrics记录了哪些信息

Metrics内部又包含了许多内部用来管理各种状态的类，所有的状态都是由这些类管理的各种状态的内部也是用ConcurrentHashMap来进行维护的

如：HealthCountsStream是用来统计任务失败率的一个类。

而每个状态管理类内部又包含了各自的真实转态信息。如HealthCountsStream保存的信息的一部分如下：

public static class HealthCounts {        private final long totalCount;        private final long errorCount;        private final int errorPercentage;

Metrics如何统计？

Metrics在统计各种状态时，时运用滑动窗口思想进行统计的，在一个滑动窗口时间中又划分了若干个Bucket（滑动窗口时间与Bucket成整数倍关系），滑动窗口的移动是以Bucket为单位进行滑动的，

如：HealthCounts 记录的是一个Buckets的监控状态，Buckets为一个滑动窗口的一小部分，如果一个滑动窗口时间为 t ,Bucket数量为 n，那么每t/n秒将新建一个HealthCounts对象。

熔断机制

熔断是参考电路而产生的一种保护性机制，即系统中如果存在某个服务，失败率过高时，将开启熔断器，对于后续的调用，不在继续请求服务，而是进行Fallback操作。

熔断所依靠的数据即是Metrics中的HealthCount所统计的错误率。