hystrix 概述

目录

1、什么是 Hystrix?

2、Hystrix 设计目的

3、Hystrix 解决的问题

4、Hystrix是如何实现它的目标的？

---

1、什么是 Hystrix?

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

Hystrix 的历史

Hystrix是由Netflix的API团队在2011年开始的弹性工程工作演变而来的。2012年，Hystrix继续发展和成熟，Netflix的许多团队都采用了它。如今，在Netflix上，每天都有数百亿的线程被隔离，以及数以千亿计的信号隔离电话。这导致了正常运行时间和弹性的显著改善。

下面的链接提供了关于Hystrix的更多上下文以及它试图解决的挑战：

• “Making Netflix API More Resilient”
• “Fault Tolerance in a High Volume, Distributed System”
• “Performance and Fault Tolerance for the Netflix API”
• “Application Resilience in a Service-oriented Architecture”
• “Application Resilience Engineering & Operations at Netflix”

2、Hystrix 设计目的

Hystrix的设计目的是：

• 通过第三方客户端库，对访问（通常是通过网络）的依赖项进行保护，并控制延迟和失败。
• 在一个复杂的分布式系统中停止级联故障。
• 快速失败，迅速恢复。
• 在可能的情况下，后退并优雅地降级。
• 启用近实时监控、警报和操作控制。

3、Hystrix 解决的问题

在复杂的分布式体系结构中，应用程序有几十个依赖项，每一个都将不可避免地在某一时刻失败。如果主机应用程序没有从这些外部故障中分离出来，那么它就有可能被它们占用。

例如，对于一个依赖于30个服务的应用程序，每个服务都有99。99%的正常运行时间，这是您可以期望的：

99.99^30 = 99.7% uptime
10亿个请求中的 0.3% = 3,000,000 次失败
即使所有的依赖关系都有很好的正常运行时间，每个月也有 2+ 小时的downtime

• 1
• 2
• 3

现实通常是更糟。

即使所有的依赖关系都很好地执行，即使是在每几十个服务中，即使是 0.01% 的停机时间，也会导致一个月的停机时间，如果你不设计整个系统来恢复弹性的话。

---

当一切都很健康时，请求流可以是这样的：

当后面的一个依赖有问题时，就会阻塞用户请求。

在高容量的流量中，一个后端依赖的潜在依赖会导致所有资源在所有服务器上的秒内变得饱和。

在应用程序中，通过网络或可能导致网络请求的客户机库中的每一点都是潜在故障的根源。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟，从而支持队列、线程和其他系统资源，从而导致系统中出现更多的级联故障。

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

更糟糕的是传递依赖关系，它们执行潜在的昂贵或容易出错的网络调用，而不需要被应用程序显式地调用。

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

所有这些都代表了需要隔离和管理的失败和延迟，这样一来，一个失败的依赖就不能拖垮整个应用程序或系统。

Hystrix的设计原则是什么？

• 防止任何单个依赖项耗尽所有容器（如Tomcat）用户线程。
• 甩掉负载和快速失败而不是排队。
• 在可行的情况下提供支持，以保护用户不受故障的影响。
• 使用隔离技术（如舱壁、泳道和断路器模式）来限制任何一个依赖项的影响。
• 通过接近实时的指标、监控和警报来优化发现时间
• 通过对配置更改的低延迟传播和对Hystrix的大多数方面的动态属性更改的支持来- - 优化时间恢复，这允许您使用低延迟反馈循环进行实时操作修改。
• 保护整个依赖客户端执行的失败，而不仅仅是在网络流量中。

4、Hystrix是如何实现它的目标的？

Hystrix 通过:

• 将所有调用封装到一个HystrixCommand或hystrix观察者的对象中，通常在一个单独的线程中执行（这是命令模式的一个例子）。
• 时间的调用比你定义的阈值要长。有一个默认值，但是对于大多数依赖项，您可以通过“属性”来定制这些超时，这样它们就会比每个依赖项的99.5%的性能稍微高一些。
• 维护每个依赖项的一个小线程池（或信号量）;如果它变得满了，那么就会立即拒绝请求这个依赖项的请求，而不是排队。
• 测量成功、失败（客户端抛出的异常）、超时和线程拒绝。
• 在一段时间内，如果服务的错误百分比超过了一个阈值，就会触发一个断路器来停止对特定服务的所有请求，无论是手动的还是自动的。
• 当一个请求失败时执行回退逻辑，被拒绝，超时，或短路。
• 监控指标和配置在接近实时的情况下发生变化。

当您使用 Hystrix 来包装每个潜在的依赖项时，上面的图表所示的体系结构将类似于下面的图表。每一个依赖关系都是相互隔离的，在延迟发生时，它可以被限制在资源中，并且包含在回退逻辑中，该逻辑决定了在依赖项中出现任何类型的故障时要做出什么响应：

原文地址：https://github.com/Netflix/Hystrix/wiki

转载：https://blog.csdn.net/u012410733/article/details/80446197