架构师：通透，才能写出好代码！

断路器的思想来源于生活：家中的保险丝、保险盒。而Java程序中的断路器模式的思想**貌似**首次来源于Netflix这家公司。需要纠正一点：因为很多Java程序员首次听说断路器是源自`Spring Cloud`，并且恰好`Spring Cloud`也“不要脸的”有个接口：`org.springframework.cloud.client.circuitbreaker.CircuitBreaker`，且还有个实现类就恰好也叫`HystrixCircuitBreaker`（和本文所讲同名），所以不少小伙伴误以为

上篇文章介绍了`Hystrix`和`Archaius`的整合，对深入了解`Hystrix`内部的属性配置打好了基础。对于属性配置，程序员们的感受可能是可能既爱又恨，因为那些浩如烟海的配置项确实可能已经超过了你的脑容量。但越是这样的工作，就越不可能靠强记的，而是应掌握其规律，学会查“字典”才是永恒之道。`Hystrix`的属性配置不在少数，但它管理得非常的好，因此本文将从**全局配置和实例配置**作为切入点，授之以渔帮小伙伴们**从根本上掌握`Hystrix`的配置**相关知识点。

了解了`Hystrix`的基本情况后，接下来将逐步深入到它的使用以及原理上。作为一个流行的开源库，扩展性、设计的弹性是必不可少的，而所谓弹性一般都通过外部化配置来实现。`Hystrix`也不例外，它支持非常非常多的配置选项，对于多如牛毛的配置项，管理起来、统一实现动态化亦是一个必备的设计要素。本文将介绍`Hystrix`的属性抽象，以及和`Archaius`的整合来实现配置的外部化、以及动态化~

`Hystrix`也是`Netflix OSS`的一部分，它是一个断路器，用于**保护你的微服务**。随着微服务的流行，熔断作为其中一项**很重要的技术**也广为人知。当微服务的运行质量低于某个**临界值**时（静态阈值的实现方式），启动熔断机制，暂停微服务调用一段时间，以保障后端的微服务不会因为持续过负荷而宕机（熔断、限流）。在分布式系统中，单个应用通常会有多个不同类型的外部依赖服务，**内部通常依赖于各种RPC服务（当然也可能是Http实现），外部则依赖于各种HTTP服务**。这些依赖服务不可避免的

Netflix OSS套件，Spring Cloud的官方推荐

Hystrix内部使用了大量的RxJava代码来书写，使得把其代码精简到了极致，性能也提升了很多。虽说Hystrix的源代码难啃，但是它面向使用者提供的API是较为友好的，特别是`HystrixCommand`它非常暖心的提供了同步执行的`execute()`方法以及异步执行的`queue()`方法，使得你无论同步/异步均无需同RxJava打交道，大大降低了使用门槛。前面几篇文章“啃”遍了源码，知道了`AbstractCommand`它是如何控制一个它command的执行的，以及如何降级、熔断。那么本文

Hystrix的源码因为是基于RxJava来书写的，一方面是很多小伙伴对RxJava并不熟悉，另一方面是基于观察者模式实现的代码绕来绕去就是不好理解，所以总的来说Hystrix的源码是比较难啃的。前面我们已经把Hystrix的**正常执行 + 异常fallback执行**都“逐个击破”了，有了良好的知识铺垫，本文主要仅需做归并即可捋出其执行原理。另外，虽然我们最常使用的是`HystrixCommand`，而真正的执行逻辑`99%`都是在`AbstractCommand`里，它才是集大成者。

前面用了几篇文章内容分析了Hystrix执行fallback的逻辑以及导致降级的各种情况，但是作为**正常执行**的逻辑均还没涉及。比如需要知道：在线程池隔离下如何执行？在信号量隔离下如何执行呢？介绍过了异常情况的处理，本文将介绍Hystrix的正常执行流程以及源码解析。

通过前面文章我们知道了，Hystrix是个强大的熔断降级框架：收集目标方法的成功、失败等指标信息，触发熔断器。其中失败信息**通过异常来表示**，交给Hystrix进行统计。但是，有的时候有些异常是并不能触发熔断的，比如请求参数异常等，那怎么办呢？或许你已经知道了结论：目标方法执行抛出异常时，**除`HystrixBadRequestException`之外**，其他异常都会认为是Hystrix命令执行失败并触发服务降级处理逻辑。那么本文将深入研究为何如此，以及给出具体的实践方案。

我们知道Hystrix每个请求都对应有一个Command命令对象，**在线程池隔离模式下**，每个命令对象在初始化时都会对应有一个“自己的”线程池`HystrixThreadPool`，当然这由`threadPoolKey`来决定（理论上多个CommandKey是可以共用同一个线程池资源的），并且有全局缓存（不会每次都执行初始化动作）。Hystrix使用RxJava来编程，那么你是否知道它在执行目标方法时（发射数据时），是如何调用线程池资源的呢？换句话说，Hystrix是如何把自己的线程池“输入”到Rx

上篇文章详细介绍了Hystrix的fallback降级逻辑，并且深入分析了其源码实现：`getFallbackOrThrowException()`方法，但我在文末留下了一个小问题：Hystrix中哪些情况会触发它的降级逻辑呢？带着这个疑问开始这篇文章的内容，本文将详细为你介绍触发Hystrix执行fallback逻辑的5种case，并且分别给出示例代码，让你既能学到，又能用到。

我们知道Hystrix是一个限流、降级容错框架，它能很好的保护我们的接口、应用。这很大程度上得益于它提供了fallback机制：回退（也叫降级）。本文所讲述的fallabck机制是`xxxCommand`系列的fallback实现，它是我们主要的使用方式。由于很多小伙伴并不清楚什么时候会触发fallabck，以及常问的fallabck后到底发生了什么呢？本文就带你一起深入了解Hystrix的fallback回退逻辑源码解读部分，从根本上掌握Hystrix回退处理逻辑。

上篇文章介绍了Hystrix事件计数器EventCounts和执行结果`ExecutionResult`，它帮忙记录着执行过程中的事件计数以及各种时间、状态等结果。本文将要介绍命令执行过程中的核心接口，包括同步执行方法、异步执行方法以及基于RxJava的`Observable`执行方式。本篇内容仅会着眼于接口层面进行描述，从大的框架方面去掌握Hystrix的设计，这样后面仅需以一个“实现类”举例便可举一反三了。

前面文章已经把Hystrix的数据源、数据流、指标数据收集都介绍了，从本文开始将要进入到数据生产方：`command`命令的执行过程，数据发射过程的学习。在此直线，本着组件化逐个攻破的学习的方式，以最为复杂的、最为常用的`AbstractCommand`为例，先了解其主要框架、主要组件的功能，这样便能对它有个更全面的掌握，使用起来也更加的得心应手。本文将要介绍贯穿其中两个非常重要的组件：事件计数器EventCounts和执行结果ExecutionResult。

前面已经花了5篇文章专门介绍了Hystrix基于事件机制的数据收集、Stream流式处理，再回头来理解它的`HystrixMetrics`指标收集就一清二楚了。在`HystrixCommand`执行过程(开始执行、结束执行、异常、超时)时会不断发出各类事件，通过**收集这些数据**，提供给消费者。如断路器、`Hystrix Dashboard`可以统计分析这些数据，从而完成特定的功能。`Hystrix`以command命令模式的方式来控制业务逻辑以及熔断逻辑的调用时机，所以说数据统计对它来说不算难事，

上篇文章介绍了`Hystrix`的“主流”：在滑动窗口内统计流、健康流。既然`Hystrix`的指标数据收集是基于事件驱动，那么自然可以多一些监听流，那么本文将做个收尾，对`Hystrix`内置的累计统计流、分发流、最大并发流...等等分别做介绍，让小伙伴们能对这种模式有个更深的理解，后面介绍的Hystrix**各维度的监控**都基于它们扩展出来的哦。Hystrix已经内置了对事件监听时各种流的实现，大多数数情况下无需自己来扩展实现的，当然若你着实要和第三方监控平台深度集成，那么你也可以自定义收集方式。

上篇文章介绍了桶计数器`BucketedCounterStream`，它提出了桶的概念并且提供了事件到桶的归约操作，可以说为滑动窗口实现打好了基础。当然，基于`BucketedCounterStream`桶的实现**并不要求必须是滑动窗口**，比如你也可以是固定窗口，也可以是累计计算等。在Hystrix里，基于桶实现的一共有两种统计方式：- 在滑动窗口内统计，子类是`BucketedRollingCounterStream`体系- 持续累计统计：子类是`BucketedCumulativeCount

上篇文章介绍了`Hystrix`指标数据收集的数据源`HystrixEvent`和数据流`HystrixEventStream`，通过示例了解了Hystrix数据收集的基本模型，但实际上并不精确。我们已经知道`Hystrix`它是通过**滑动窗口的数据结构/算法**来统计调用的指标数据的，但若直接使用`HystrixEventStream`作为管道传播数据的话，是**点对点**的，并无时间区间、时间窗口等概念。因此本文将以以这为目的，深入了解与时间窗口相关的数据传输、收集处理的核心API：`Bucket

`HystrixCommand`在执行过程中会持续不断的产生数据，Hystrix会收集到这些数据后做运算，进而按策略做出仲裁。数据的发送方为命令执行方，接收方为指标数据收集方，那么这些数据的传输通道是什么？以什么样的方式进行传输呢？这将是本文讲解的主要内容。`Hystrix`自从1.5版本开始便通过数据流`HystrixEventStream`的方式持续不断的收集数据，而该数据流里面的内容便用`HystrixEvent`数据源俩表示。

`Hystrix`能够提供熔断、**限流**、断路器保护等等功能，而这些功能均基于数据采集。`Netflix Hystrix`通过类似**滑动窗口**的数据结构来统计命令执行过程中的各种指标数据，进而做出对应的响应。滑动窗口算法(`Sliding Window Algorithm`)是常见的一种算法：它思想简洁且功能强大，可以用来解决一些查找满足一定条件的**连续区间**的性质/长度的问题。由于区间连续，因此当区间发生变化时，可以通过旧有的计算结果对搜索空间进行剪枝，这样便减少了重复计算，**降低了时间

说到线程间的数据传递，你肯定会联想到`ThreadLocal`。但若是跨线程传递数据呢？阅读本文之前，我个人建议你已经能够非常熟练的使用`ThreadLocal`并了解其基本原理，至少看过下面两篇文章表述的内容：在`Hystrix`里，它支持两种隔离模式：线程池隔离和信号量隔离。前者是默认选项：每个命令都在线程池里隔离执行，因此**必然会涉及到**存在跨线程传递数据的问题，这是Hystrix需要解决的（信号量隔离不存在此问题~）。

`Hystrix`提供了插件机制（SPI机制）来提升自身的扩展性，提高弹性。这里所指的插件包括：- `HystrixConcurrencyStrategy`：获取并发相关类- `HystrixEventNotifier`：事件通知类- `HystrixMetricsPublisher`：度量信息类- `HystrixPropertiesStrategy`：Properties配置类- `HystrixCommandExecutionHook`：HystrixCommand回调函数类- `Hyst