Hystrix介绍

最新推荐文章于 2024-08-11 22:45:54 发布

lcli

最新推荐文章于 2024-08-11 22:45:54 发布

阅读量364

点赞数

分类专栏： Hystrix Java

51 篇文章 0 订阅

订阅专栏

8 篇文章 0 订阅

订阅专栏

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

History of Hystrix

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

Hystrix旨在执行以下操作：

复杂分布式体系结构中的应用程序具有许多依赖关系，每个依赖关系在某些时候都将不可避免地失败。如果主机应用程序未与这些外部故障隔离，则可能会被它们取下。

例如，对于依赖于30个服务的应用程序，其中每个服务的正常运行时间为99.99％，您可以期待以下内容：

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

现实情况通常更糟。

即使所有依赖关系都表现良好，如果您没有为整个系统设计弹性，那么即使0.01％停机时间对数十种服务中的每项服务的总体影响也相当于每月停机一小时。

当一切都很健康时，请求流可能如下所示：

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

对于高流量流量，单个后端依赖性变为潜在可能导致所有资源在所有服务器上在几秒钟内变得饱和。

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

当通过第三方客户端执行网络访问时，这些问题会加剧 - 一个“黑匣子”，其中隐藏实施细节并且可以随时更改，并且每个客户端库的网络或资源配置不同，并且通常难以监控更改。

更糟糕的是传递依赖性，这些依赖性执行潜在的昂贵或容易出错的网络调用，而不是由应用程序显式调用。网络连接失败或降级。服务和服务器失败或变慢。新库或服务部署会更改行为或性能特征。

客户端库有bug。所有这些都代表了需要隔离和管理的故障和延迟，因此单个故障依赖关系无法取消整个应用程序或系统。

Hystrix的工作原理是：

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

Hystrix通过以下方式实现：

将所有对外部系统（或“依赖项”）的调用包含在HystrixCommand或HystrixObservableCommand对象中，该对象通常在单独的线程中执行（这是命令模式的一个示例）。
定时调用的时间超过您定义的阈值。有一个默认值，但对于大多数依赖项，您可以通过“属性”自定义设置这些超时，以便它们略高于每个依赖项的测量的第99.5百分位性能。
为每个依赖项维护一个小的线程池（或信号量）;如果它变满，将立即拒绝发往该依赖项的请求而不是排队。衡量成功，失败（客户端引发的异常），超时和线程拒绝。
如果服务的错误百分比超过阈值，则手动或自动地使断路器跳闸以停止对特定服务的所有请求一段时间。
当请求失败时执行回退逻辑，被拒绝，超时或短路。
近乎实时地监控指标和配置更改。

当您使用Hystrix来包装每个底层依赖项时，上图中所示的体系结构将更改为类似于下图。每个依赖项彼此隔离，在发生延迟时可以饱和的资源受到限制，并且在回退逻辑中涵盖，该逻辑决定了在依赖项中发生任何类型的故障时要做出的响应：