内容简介：阅读原文可查看文中连接Hystrix: Latency and Fault Tolerance for Distributed Systems
阅读原文可查看文中连接
Hystrix: Latency and Fault Tolerance for Distributed Systems
近期逐渐学习了 Hystrix 这位 “守护神” 的部分源码，本文作为 Hystrix 系列的小结篇。
在刚看完一丢丢源码时，Netflix 官方便已宣布进入 “维护模式” ，版本定格在 1.5.18 ，官宣该版本已足够满足现存应用的需求。同时，官方也推荐了 resilience4j 这个活跃项目，另阿里系的 Sentinel 也现也十分火热。
对于早已投产的系统来说，Hystrix 自然是重点，无论是 Zuul 路由，还是 Feign 做服务间的调用，它们都结合了 Hystrix 来守护系统。
下面是几篇粗浅的源码学习文章，学习了其工作原理、守护技能(降级、隔离、熔断)、性能提升(请求缓存、合并)等。因请求合并少用，未做学习。
-
Spring Cloud 源码学习之 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 文章：
-
Spring Cloud 源码学习之 Feign
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
有限与无限的游戏
[美]詹姆斯·卡斯 / 马小悟、余倩 / 电子工业出版社 / 2013-10 / 35.00元
在这本书中，詹姆斯·卡斯向我们展示了世界上两种类型的「游戏」：「有限的游戏」和「无限的游戏」。 有限的游戏，其目的在于赢得胜利；无限的游戏，却旨在让游戏永远进行下去。有限的游戏在边界内玩，无限的游戏玩的就是边界。有限的游戏具有一个确定的开始和结束，拥有特定的赢家，规则的存在就是为了保证游戏会结束。无限的游戏既没有确定的开始和结束，也没有赢家，它的目的在于将更多的人带入到游戏本身中来，从而延续......一起来看看 《有限与无限的游戏》 这本书的介绍吧!
