Hystrix

最新推荐文章于 2023-11-19 22:39:18 发布

zhengzengliang

最新推荐文章于 2023-11-19 22:39:18 发布

阅读量108

点赞数

分类专栏： Hystrix 文章标签： java

原文链接：https://github.com/Netflix/Hystrix/wiki

版权

1 篇文章 0 订阅

订阅专栏

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

海斯特里克斯的历史

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

以下链接提供了有关Hystrix及其尝试解决的挑战的更多背景信息：

Hystrix 旨在执行以下操作：

复杂分布式架构中的应用程序具有数十个依赖项，每个依赖项在某些时候都不可避免地会失败。如果主机应用程序未与这些外部故障隔离，则它可能会随这些故障一起被关闭。

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

99.9930= 99.7% 正常运行时间
10 亿个请求的 0.3% = 3，000，000 次故障
2 小时以上的停机时间/月，即使所有依赖项都具有出色的正常运行时间。

现实情况通常更糟。

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

当一切正常时，请求流可能如下所示：

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

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

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

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

更糟糕的是可传递依赖项，这些依赖项执行可能代价高昂或容易出错的网络调用，而应用程序未显式调用。

网络连接失败或降级。服务和服务器出现故障或变慢。新的库或服务部署会更改行为或性能特征。客户端库存在错误。

所有这些都代表了需要隔离和管理的故障和延迟，以便单个失败的依赖项无法关闭整个应用程序或系统。

## Hystrix背后的设计原则是什么？

Hystrix的工作原理是：

Hystrix通过以下方式做到这一点：

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

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

关注