即使 Hystrix 再也不维护，它仍然值得学习！

本文由 yanglbme 首发于 GitHub 技术社区 Doocs，目前 stars 已超 30k。
项目地址：github.com/doocs/advan…

Hystrix 是什么？

在分布式系统中，每一个服务均可能会调用不少其余服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。

Hystrix 可让咱们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。

Hystrix 经过将依赖服务进行资源隔离，进而阻止某个依赖服务出现故障时在整个系统全部的依赖服务调用中进行蔓延；同时Hystrix 还提供故障时的 fallback 降级机制。

总而言之，Hystrix 经过这些方法帮助咱们提高分布式系统的可用性和稳定性。

Hystrix 的历史

Hystrix 是高可用性保障的一个框架。Netflix（能够认为是国外的优酷或者爱奇艺之类的视频网站）的 API 团队从 2011 年开始作一些提高系统可用性和稳定性的工做，Hystrix 就是从那时候开始发展出来的。

在 2012 年的时候，Hystrix 就变得比较成熟和稳定了，Netflix 中，除了 API 团队之外，不少其余的团队都开始使用 Hystrix。

时至今日，Netflix 中天天都有数十亿次的服务间调用，经过 Hystrix 框架在进行，而 Hystrix 也帮助 Netflix 网站提高了总体的可用性和稳定性。

2018 年 11 月，Hystrix 在其 Github 主页宣布，再也不开放新功能，推荐开发者使用其余仍然活跃的开源项目。维护模式的转变毫不意味着 Hystrix 再也不有价值。相反，Hystrix 激发了不少伟大的想法和项目，咱们高可用的这一块知识仍是会针对 Hystrix 进行讲解。

Hystrix 的设计原则

• 对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护。
• 在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延。好比某一个服务故障了，致使其它服务也跟着故障。
• 提供 fail-fast（快速失败）和快速恢复的支持。
• 提供 fallback 优雅降级的支持。
• 支持近实时的监控、报警以及运维操做。

举个栗子。

有这样一个分布式系统，服务 A 依赖于服务 B，服务 B 依赖于服务 C/D/E。在这样一个成熟的系统内，好比说最多可能只有 100 个线程资源。正常状况下，40 个线程并发调用服务 C，各 30 个线程并发调用 D/E。

调用服务 C，只须要 20ms，如今由于服务 C 故障了，好比延迟，或者挂了，此时线程会 hang 住 2s 左右。40 个线程所有被卡住，因为请求不断涌入，其它的线程也用来调用服务 C，一样也会被卡住。这样致使服务 B 的线程资源被耗尽，没法接收新的请求，甚至可能由于大量线程不断的运转，致使本身宕机。服务 A 也挂。

Hystrix 能够对其进行资源隔离，好比限制服务 B 只有 40 个线程调用服务 C。当此 40 个线程被 hang 住时，其它 60 个线程依然能正常调用工做。从而确保整个系统不会被拖垮。

Hystrix 更加细节的设计原则

• 阻止任何一个依赖服务耗尽全部的资源，好比 tomcat 中的全部线程资源。
• 避免请求排队和积压，采用限流和 fail fast 来控制故障。
• 提供 fallback 降级机制来应对故障。
• 使用资源隔离技术，好比 bulkhead（舱壁隔离技术）、swimlane（泳道技术）、circuit breaker（断路技术）来限制任何一个依赖服务的故障的影响。
• 经过近实时的统计/监控/报警功能，来提升故障发现的速度。
• 经过近实时的属性和配置热修改功能，来提升故障处理和恢复的速度。
• 保护依赖服务调用的全部故障状况，而不单单只是网络故障状况。

---

欢迎关注个人微信公众号“Doocs开源社区”，原创技术文章第一时间推送。