Spring Cloud Hystrix 源码学习合集_hystrix 源码导入idea-CSDN博客

本文链接：https://blog.csdn.net/myle69/article/details/86487128

欢迎访问陈同学博客原文

Hystrix: Latency and Fault Tolerance for Distributed Systems

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

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

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

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

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

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

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

隔离设计是绝妙的防护罩

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

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

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

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

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

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

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

executionHook.onStart(...);
eventNotifier.markEvent(...);

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

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

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

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

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

其他 Spring Cloud 文章：

欢迎关注陈同学的公众号，一起学习，一起成长