5、断路器 Netflix Hystrix 之 运维操作

Hystrix 不仅是一种弹性工程工具，也是一种操作工具。

本页面试图分享每天使用 100 多个 Hystrix 命令类型、40 多个线程池、100 多个线程隔离命令和 2000 多个信号量隔离命令执行的系统的一些经验。

本页上描述的截图和事件来自 Netflix API 系统，代表了真实的生产问题或对生产的 Latency Monkey 模拟。

1、如何配置和调优调用

部署新电路的典型方法是使用自由配置(超时/线程/信号量)将其发布到生产环境中，然后在看到它在峰值生产周期中运行后将其调优为更严格的配置。

在实践中，这通常看起来是:

• 保留默认的 1000ms 超时，除非知道需要更多的时间。
• 保持线程池默认为 10 个线程，除非知道需要更多线程。
• 金丝雀部署;如果一切顺利，请继续。
• 整个系统 24 小时投入生产。
• 依赖标准的警报和监视来捕捉问题(如果有的话)。
• 24 小时后，使用延迟百分比和通信量来计算对电路有意义的最低配置值。
• 在生产中实时更改这些值，并使用实时仪表板监视它们，直到您有信心为止。
• 只有当电路的行为或性能特征发生变化，并通过警报和/或仪表板监控引起您的注意时，才可以再次查看该电路的配置。

下图展示了如何选择线程池、队列和执行超时(或信号量大小)的典型思维过程:

对于大多数电路，您应该尝试将它们的超时值设置为正常运行系统的 99.5%，这样它们就可以切断坏请求，不让它们占用系统资源或影响用户行为。

您必须调整线程池和队列的大小，使它们只占整个应用程序资源的一小部分，否则它们将无法防止依赖关系使可用资源饱和。

关于配置和调优电路的重要事情是:

• 您应该在生产环境中根据真实的流量模式进行调优
• 您可以轻松地实时调整设置，同时监视以查看不同设置的影响

2、预料到抖动和失败

Hystrix 以毫秒的粒度度量和报告度量。这揭示了“抖动”——可以看作是超时、线程池拒绝、慢下来以及其他类似的事情的爆发。在一个大的集群中，对于一个大容量的电路来说，在任何特定的时间通常都有一些这样的事情发生。

Hystrix 所捕获的度量粒度是许多软件系统所不具备的，因此这些报告可能会引起不必要的担忧。

在这张来自 Netflix API 仪表板的截图中，你可以看到橙色和紫色的数字，显示在一个 10 秒的统计窗口中，代表 243 个服务器的一小部分请求发生超时和线程池拒绝。

大多数系统都是在相当高的级别上进行度量的——即使分解成百分位数延迟，也是每分钟完成一次。而且，通常是针对整个应用程序请求循环，而不是与之交互的每个依赖项。在《海斯特里克斯》中，你可以更清楚地看到发生了什么。使用放大镜显示每个依赖项的情况之后，如果您看到以前可能看不到的抖动，请不要感到惊讶。

一些原因:

• 客户端机器垃圾收集(您的机器在请求的中间进行垃圾收集)
• 服务机器垃圾收集(远程服务器在向它发出请求时执行垃圾收集)
• 网络问题
• 不同的请求参数有不同的负载大小
• 缓存错过
• 丛发性调用模式
• 新机器启动(部署、自动扩展事件)和“热身”

3、潜在的问题

如果你注意到了延迟，不要急于重新配置。如果 Hystrix 命令正在减轻负载，那么它就在做它应该做的事情(当然，假设您在它正常运行时对它进行了正确的配置——参见上文)。

在早期在 Netflix Hystrix 被采用,这是一个常见的反应时电路(我们内部称之为 Hystrix[Observable]Command/CircuitBreake 配对)成为潜在的动态更改属性增加线程池,队列、超时等等,试着给它一些喘息的空间,让它再次工作。但这与你应该做的相反。如果您正确地为运行良好的系统配置了命令，并且该命令现在正在拒绝、超时和/或短路，那么您应该集中精力解决根本原因。

不要犯这样的错误，即在响应时给命令提供更多的资源以满足它的需要(极端情况下，如果您这样做，您自己就可以通过增加线程池、队列、超时、信号量等大小来进行DDOS攻击)。

例如，假设您有一个由100个服务器组成的集群，每个服务器允许有10个并发连接到一个服务，即:1000个可能的并发连接。在健康的情况下，它通常在任何给定时间使用200-300个。如果出现延迟并备份它们，那么您现在将使用1000个连接。每箱10个对于客户来说似乎不多，所以让我们尝试增加到20个，对吗?很可能10个是饱和的，20个也会变成饱和的。现在有2000个连接对后端开放，这使情况变得更糟。

这就是断路器存在的原因之一——释放底层系统的压力，让它们恢复，而不是在重试循环中使用更多的请求，挂起连接，等等。

例如，下面是一个具有延迟的单个依赖项的例子，它导致的超时高到足以导致断路器在大约三分之一的集群上跳闸。这是系统中唯一存在健康问题的电路，而Hystrix正在阻止它在出现延迟问题时获取其他资源。

简而言之，让系统摆脱负载、短路、超时和拒绝，直到底层系统恢复健康，并在Hystrix层恢复健康。Hystrix正是为这种场景而设计的，其重点是减少潜在系统的资源利用，通过隔离大多数资源并远离那些挂起在潜在连接上的资源，从而快速恢复。

4、依赖失败是什么样的

分布式系统中最典型的故障类型是单个依赖项出现故障或潜伏，而其他所有依赖项都保持健康状态。在这些情况下，指标和仪表板会非常明显地显示正在发生的事情:

上面的截图显示了一个错误率为20%的电路:高到足以产生影响，但不足以开始跳闸断路器。其他三条线路则不受影响。

在这个特定的例子中，导致问题的是实际错误，而不是延迟——如红色数字所示，而不是橙色。

下面的图表是在同一事件中捕捉到的，展示了这条赛道的历史趋势，以及它是如何在失败和撤退中飙升的。

5、级联依赖失败

这个截图表示一个系统的故障(在本例中是高延迟)，该系统严重依赖于许多其他系统，因此故障也会波及到其他系统。Netflix API系统必须能够抵抗延迟和故障，而不仅仅是单一的根本原因，而是所有受其影响的系统。

下面的截图显示了代表三种不同系统的六个电路:

在这个事件发生的时候，Hystrix基本上还只是一个“netflix - api”的东西。随着 Hystrix 在越来越多的Netflix团队中运行，这进一步限制了级联故障的影响，如下图所示:

6、是你的问题，不是依赖性

如果所有的电路看起来都不好(仪表板都亮着)，那么很有可能问题出在你的系统上，而不是同时出在你所有的依赖项上。

两个可能导致这种情况的系统问题的例子是:

• 系统过载(高平均负载、CPU占用率等)
  这种情况可能发生的一个例子是，自动伸缩策略失败或伸缩速度不够快，导致流量激增，机器接收的流量超过了它们的处理能力。
• 内存泄漏最终导致GC抖动，GC抖动会窃取CPU并导致暂停，而暂停又会导致电路超时、备份和拒绝

原文地址：

• Hystrix Wiki – Operations