什么是 Hystrix？
在分布式环境中，许多服务之间相关互相依赖，在这种复杂环境中总不可避免地会失败。Hystrix 就是解决这类问题的一个容错治理框架，它通过添加延迟容错和容错逻辑来帮助您控制在这种环境中分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点、阻止它们之间的级联故障并提供回退选项来实现这一点，所有这些都为了提高系统的整体弹性。
Hystrix 的历史
Hystrix 由 Netflix API 团队于 2011 年开始的弹性工程工作演变而来。 2012 年，Hystrix 不断发展和成熟，Netflix 内部的许多团队都采用了它。如今，Netflix 每天通过 Hystrix 执行数百亿个线程隔离和数千亿个信号量隔离调用。保障了正常运行时间和弹性的显着改善。
Hystrix 有什么用？
Hystrix 旨在执行以下操作：
- 通过第三方客户端库访问的依赖项（通常通过网络）提供延迟和故障的保护和控制。
- 停止复杂分布式系统中的级联故障。
- 快速失败并快速恢复。
- 在可能的情况下回退并优雅地降级。
- 实现近乎实时的监控、警报和操作控制。
Hystrix 解决了什么问题？
复杂分布式架构中的应用程序通常有成千上万个依赖项，每个依赖项可能会在某个时刻不可避免地失败。如果主机应用程序没有与这些外部故障隔离开来，它就有可能被它们拖垮。
例如，对于依赖 30 个服务的应用程序，其中每个服务的正常运行时间为 99.99%，您可以期待以下内容：
99.99 30 = 99.7% 的正常运行时间
10 亿次请求的 0.3% = 3,000,000 次故障
每月停机时间超过 2小时，即使所有依赖项都具有出色的正常运行时间。
但现实情况通常更糟。即使所有依赖项都表现良好，如果您不设计整个系统以实现弹性，即使是 0.01% 的停机时间对数十个服务中的每一个的总体影响也等同于每月潜在的几个小时停机时间。
当一切正常时，请求流可能如下所示：
（图一）
当后端系统中从多依赖服务中某个依赖项目不稳定（产生故障）时，它可以阻止整个用户请求：
（图二）
在面对大量流量冲击情景中，某个后端微服务的依赖变得不稳定时可能导致其所在服务器上的所有资源在短短数秒钟内变得饱和。
应用程序中通过网络或客户端库访问可能导致网络请求的每个点都是潜在故障的来源。比故障更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，耗尽级联系统中所有相关队列、线程和其他系统资源，从而导致整个系统出现大崩溃故障。
（图四）
当通过第三方客户端执行网络访问时，这些问题会更加严重——一个“黑匣子”，其中隐藏了实现细节并且可以随时更改，每个客户端库的网络或资源配置都不同，通常难以监控和改变。更糟糕的是传递依赖，它们执行潜在的昂贵或容易出错的网络调用，而没有被应用程序显式调用。网络连接失败或降级，服务和服务器出现故障或变慢；所有这些都代表需要隔离和管理的故障和延迟，以便单个失败的依赖项无法关闭整个应用程序或系统。
Hystrix 背后的设计原则是什么？
设计目标是什么？
- 防止任何单个依赖项耗尽所有容器（例如 Tomcat）用户线程。
- 减轻负载和快速失败而不是排队。
- 在可行的情况下提供回退以保护用户免于失败。
- 使用隔离技术（例如隔板、泳道和断路器模式）来限制任何一种依赖性的影响。
- 通过近乎实时的指标、监控和警报优化发现时间
- 通过配置更改的低延迟传播和支持 Hystrix 大部分方面的动态属性更改来优化恢复时间，这允许您使用低延迟反馈循环进行实时操作修改。
- 防止整个依赖客户端执行中的故障，而不仅仅是网络流量。
Hystrix 如何实现其目标？
Hystrix 通过以下方式执行此操作：
- 将所有对外部系统（或“依赖项”）的调用包装在一个
HystrixCommand或HystrixObservableCommand对象中，该对象通常在单独的线程中执行。 - 超时调用时间超过您定义的阈值。有一个默认值，但对于大多数依赖项，您可以通过“属性”自定义设置这些超时，以便它们略高于每个依赖项的测量的 99.5 th百分位性能。
- 为每个依赖项维护一个小的线程池（或信号量）；如果它已满，则发往该依赖项的请求将立即被拒绝，而不是排队。
- 计算统计一定时间窗口内成功、失败（客户端抛出的异常）、超时和线程拒绝的数据。
- 如果服务的错误百分比超过阈值，则手动或自动触发断路器以在一段时间内停止对特定服务的所有请求。
- 当请求失败、被拒绝、超时或短路时执行回退逻辑。
- 近乎实时地监控指标和配置更改。
（图五）
断路器的开关控制逻辑如下：
- 在一个统计时间窗口（HYST rixCommandProperties.metricsRollingStatisticalWindowInMilliseconds()）内，处理的请求数达到设置的最小阈值（HYST）rixCommandProperties.circuitBreakerRequestVolumeThreshold（）），错误百分比超过设置的最大阈值（HYST）rixCommandProperties.circuitBreakerThreshold（） ) )此时断路器分闸，断路器状态由合闸切换为分闸。
- 当断路器断开时，它将直接融合所有请求（快速失败）并经过回退逻辑。
- 经过一个休眠窗口时间（HYST rixCommandProperties.circuitBreakerSleepWindowInMilliseconds()），Hystrix会释放一个进行后续服务并将断路器开关切换到半开（half OPEN）。如果请求失败，断路器将熔断开关切换到OPEN状态，继续熔断所有请求，直到下一个休眠时间窗口到来；如果请求成功，断路器将切换到 CLOSED 状态，此时允许所有请求通过，直到发生一步，断路器开关才会切换到 OPEN 状态。
（图六）
当您使用 Hystrix 包装每个底层依赖项时，如图四所示的架构将更改为类似于下图。每个依赖项间彼此隔离，限制在发生延迟时，降低资源饱和度，并覆盖在回退逻辑中，该逻辑决定在依赖项中发生任何类型的故障时做出什么响应：
（图七）
使用 Zuul、Ribbon、Feign、Eureka 和 Sleuth、Zipkin 创建简单spring cloud微服务用例-spring cloud 入门教程
微服务集成SPRING CLOUD SLEUTH、ELK 和 ZIPKIN 进行监控-spring cloud 入门教程
使用Hystrix 、Feign 和 Ribbon构建微服务-spring cloud 入门教程
使用 Spring Boot Admin 监控微服务-spring cloud 入门教程