hystrix 源码 线程池隔离_Spring Cloud Hystrix 源码学习合集

# Spring Cloud Hystrix 源码学习合集

**Hystrix: Latency and Fault Tolerance for Distributed Systems**


近期逐渐学习了 Hystrix 这位 **"守护神"** 的部分源码，本文作为 Hystrix 系列的小结篇。

在刚看完一丢丢源码时，Netflix 官方便已宣布进入 **"维护模式"**，版本定格在 **1.5.18**，官宣该版本已足够满足现存应用的需求。同时，官方也推荐了 [**resilience4j**](https://github.com/resilience4j/resilience4j) 这个活跃项目，另阿里系的 [**Sentinel**](https://github.com/alibaba/Sentinel) 也现也十分火热。

对于早已投产的系统来说，Hystrix 自然是重点，无论是 Zuul 路由，还是 Feign 做服务间的调用，它们都结合了 Hystrix 来守护系统。

下面是几篇粗浅的源码学习文章，学习了其工作原理、守护技能(降级、隔离、熔断)、性能提升(请求缓存、合并)等。因请求合并少用，未做学习。

* [Spring Cloud 源码学习之 Hystrix 入门](https://chenyongjun.vip/articles/75)

* [Spring Cloud 源码学习之 Hystrix 工作原理](https://chenyongjun.vip/articles/88)

* [Spring Cloud 源码学习之 Hystrix Metrics 收集](https://chenyongjun.vip/articles/89)

* [Spring Cloud 源码学习之 Hystrix 熔断器](https://chenyongjun.vip/articles/90)

* [Spring Cloud 源码学习之 HystrixRequestContext](https://chenyongjun.vip/articles/91)

* [Spring Cloud 源码学习之 Hystrix 请求缓存](https://chenyongjun.vip/articles/93)

* [Spring Cloud 源码学习之 Hystrix 隔离策略](https://chenyongjun.vip/articles/95)

Hystrix 源码学习收获不小，罗列几点：

* **工欲善其事，必先利其器** & **产生对响应式的兴趣**

Hystrix 基于 RxJava 进行实现，RxJava 是一种基于观察者模式的响应式编程框架。我也花了不少时间对其概念和Hystrix 中所使用的方法做了些学习，产生了学习兴趣。Hystrix 的决策(如熔断、线程池/信号量拒绝)都需要数据支撑，而这些数据就是在各个 Command 执行时不断产生，借着 RxJava 十分便利的收集、聚合。

* **隔离设计是绝妙的防护罩**

在单体应用中，一类服务、一个线程、一个Bug等局部因素压垮整个系统也是屡见不鲜。微服务中，服务间依赖重重，通过隔离，很好的控制住风险范围，再结合请求拒绝和超时控制，有效剔除 "老鼠屎"，避免坏了一锅粥。

同时也见识了线程池隔离，以后需要做类似的事情时也是非常好的参考。


* **特定生命周期存储结构的设计**

日常开发也就接触 ThreadLocal 这种 thread-scoped 类型的数据结构，偶尔还得徒手在非父子线程间传递数据。

HystrixRequestContext 的出现令人恍然大悟，设计了 request-scoped 的存储结构，原来任务本身就是线程间信息传递最好的载体，以后就可以设计出 **任意生命周期** 内的存储结构了。

* **好的技术产品，拓展性肯定非常好**

不同垂直业务场景，需求也是多种多样。良好的拓展性，使得技术产品具备良好的弹性，开发人员可以基于设计的拓展机制实现各项功能。例如：Hystrix 中有很多下面样式的代码，它们设计在了Command执行过程中，默认实现其实啥也没做，但是为开发人员在必要时提供了拓展入口。

```java

executionHook.onStart(...);

eventNotifier.markEvent(...);

```

而Spring Cloud 全家桶，拓展性更是处处可见，如：Zuul 的过滤器、Feign 对于请求和响应提供的拦截器等。

* **拥有良好的恢复能力自然更健康**

熔断的设计，在服务出现问题时可以起到很好的保护作用，避免压垮服务的最后一根稻草渗透进去。然后逐渐利用**请求探针** 试探一下服务，如果恢复健康，则自动关闭熔断。

如果任由请求肆虐，服务早就死翘了吧。

如果使用微服务并已上线，深入学习各组件的原理和原理还是非常有必要，否则遇到问题就只能懵逼，然后重启大法好了。

其他 Spring Cloud 文章：

* [Spring Cloud 之极端续租间隔时间的影响](https://chenyongjun.vip/articles/70)

* [Spring Cloud 源码学习之 Zuul](https://chenyongjun.vip/articles/72)

* [Spring Cloud 实战之 Zuul 网关不响应任何请求](https://chenyongjun.vip/articles/76)

* [Spring Cloud 源码学习之 Feign](https://chenyongjun.vip/articles/94)

扫码或搜索 codercyj 关注微信公众号, 结伴学习, 一起努力