Spring Cloud - Hystrix的真情独白

关于麦洛

麦洛是 Java 开发者和技术爱好者。 对 Java 相关技术特别感兴趣，包括 javaee、 Spring系列、 微服务等

文章出处:What Is Hystrix?

一.什么是 Hystrix？

在分布式环境中，许多服务依赖项中的一些将不可避免地失败。 Hystrix 是一个库，通过添加延迟容忍和容错逻辑，帮助您控制这些分布式服务之间的交互。 Hystrix 通过隔离服务之间的访问点，停止它们之间的级联故障，并提供回退选项来实现这一点，所有这些都提高了系统的总体弹性。

Hystrix的历史

Hystrix是从 Netflix API 团队2011年开始的弹性工程工作中演化而来的。2012年，Hystrix 继续发展和成熟，Netflix 内部的许多团队都采用了它。今天，Netflix 每天通过 Hystrix 执行数百亿个线程隔离的、数千亿个信号量隔离的呼叫。 这导致了正常运行时间和弹性的显著改善。

二.Hystrix是干什么的?

Hystrix 的设计目的如下:

• 通过第三方客户端库从依赖项访问(通常通过网络)提供对延迟和故障的保护和控制
• 停止复杂分布式系统中的级联故障
• 快速而迅速的失败
• 如果可能的话，撤退并优雅地降级
• 启用接近实时的监视、警报和操作控制

三.Hystrix解决了什么问题?

复杂分布式体系结构中的应用程序有许多依赖项，每个依赖项都不可避免地在某个时刻失败。 如果宿主应用程序没有与这些外部故障隔离开来，那么它可能会随着这些外部故障而被关闭。

例如，对于依赖于30个服务的应用程序，其中每个服务的正常运行时间为99.99% ，以下是您可以期望的:

99.99³⁰ = 99.7% uptime
0.3% of 1 billion requests = 3,000,000 failures
2+ hours downtime/month even if all dependencies have excellent uptime.

99.993099.7% 正常运行时间0.3% 的10亿次请求3,000,000次故障2小时以上停机 / 月，即使所有依赖项都有很好的正常运行时间。

现实通常更糟糕。

即使所有依赖项都运行良好，如果您不对整个系统进行弹性设计，那么即使是对几十个服务中的每个服务的0.01% 停机时间的累计影响也可能相当于每个月数小时的停机时间。

当一切正常时，请求流可以是这样的:

当许多后端系统中的一个变得异常时，它可以阻止整个用户请求:

在高流量的情况下，单个后端依赖变得异常可能导致所有服务器上的所有资源在几秒钟内饱和。

应用程序中通过网络或进入客户端库的每个点都可能导致网络请求，这是潜在故障的根源。 比故障更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，从而备份队列、线程和其他系统资源，导致整个系统发生更多级联故障。

当通过第三方客户机进行网络访问时，这些问题就更加严重了——这是一个”黑匣子” ，其中隐藏了实现细节，并且可以随时更改，而且每个客户机库的网络或资源配置不同，往往难以监控和更改。

更糟糕的是可传递依赖关系，这些依赖关系在应用程序没有显式调用的情况下执行可能代价高昂或容易出错的网络调用。

网络连接失败或降级。 服务和服务器失败或变慢。 新的库或服务部署会改变行为或性能特征。 客户机库有 bug。

所有这些都表示需要隔离和管理的故障和延迟，以便单个故障依赖关系不能关闭整个应用程序或系统。

四.Hystrix 是如何实现其目标的？

​ Hystrix的工作原理是

• 防止任何单个依赖项用尽所有容器（例如Tomcat）用户线程。

• 脱落负载并快速失败而不是排队。

• 在可行的情况下提供回退以保护用户免于失败。

• 使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖项的影响。

• 通过近实时指标，监控和警报优化发现时间

• 通过Hystrix的大多数方面的配置更改的低延迟传播和对动态属性更改的支持来优化恢复时间，这允许您使用低延迟反馈循环进行实时操作修改。

• 防止整个依赖关系客户端执行中的故障，而不仅仅是网络流量。

  Hystrix通过以下方式实现：

• 将对外部系统（或“依赖项”）的所有调用包含在通常在单独线程中执行的对象HystrixCommand或HystrixObservableCommand对象中（这是命令模式的示例）。

• 定时调用的时间超过您定义的阈值。有一个默认的，而是由“属性”的方式对大多数依赖你自定义设置这些超时，使它们成功率笔99.5略高。

• 为每个依赖服务维护一个小的线程池（或信号量）; 如果它变满，将立即拒绝发往该依赖项的请求而不是排队。

• 衡量成功，失败（客户端引发的异常），超时和线程拒绝。

• 如果服务的错误百分比超过阈值，则手动或自动地使断路器跳闸以停止对特定服务的所有请求一段时间。

• 当请求失败时执行callback逻辑，被拒绝，超时或短路。

• 近乎实时地监控指标和配置更改。

当您使用 Hystrix 包装每个基础依赖项时，如上图所示的体系结构将变得类似于下图。 每个依赖都是相互隔离的，当延迟发生时它可以饱和的资源受到限制，并且包含在回退逻辑中，该逻辑决定当依赖中发生任何类型的故障时应该做出什么响应:

五:结论

制，并且包含在回退逻辑中，该逻辑决定当依赖中发生任何类型的故障时应该做出什么响应:

[外链图片转存中…(img-RO5lgsjE-1584629829225)]

五:结论

Netflix 已经官方宣布不再维护 Hystrix，所以在生产环境，技术选型的时候需要综合考虑。