Hystrix中使用的Bulkhead Pattern是什么？

Question

126

Hystrix是Netflix用于复杂分布式系统中处理延迟和容错的API，使用隔板模式技术进行线程隔离。能否有人对此进行详细说明。

- Sashank

3个回答

5

以下是内容翻译的结果：

这里有一个关于Resilience4j中bulkhead的运行时解释的好例子，它受到Netflix Hystrix的启发。

下面的示例配置可能会让使用更加清晰。

示例配置：允许同时最多5个并发调用。等待其他调用，直到其中一个正在进行的5个并发完成或达到2秒的最大时间限制。

思路是不要使任何系统承受超过其可消耗的负载。如果输入的负载大于消耗，那么请等待合理的时间或仅超时并选择替代路径。

- Ravi K

1

这真是一篇好文章。 - Gabriel Aramburu

0

隔板模式是一种用于隔离和容错的设计模式。

在微服务中，一个服务可能依赖于许多其他服务。如果其中一个依赖服务崩溃或访问超时，调用者可能会耗尽资源，然后无法调用其他正常服务；如果我们使用隔板模式通过不同的线程池对服务进行分组和隔离，那么当一个线程池耗尽资源时，其他线程组的资源不会受到影响，并且其他服务的正常调用也不会受到影响。

您可以参考这个链接：隔板模式

- formerly1

2

这真的比非常全面的被接受答案增加了价值吗？ - Jeremy Caney

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- K Erlandsson · Accepted Answer

概述

通常，舱壁模式的目标是避免系统中的某个部分出现故障导致整个系统崩溃。该术语来自于船只，在船只上分割成独立的密封舱室以避免单个船体破裂会淹没整个船只；只会淹没一个舱壁。

实现舱壁模式可以采取多种形式，具体取决于要保护系统免受哪种类型的故障。本答案仅讨论Hystrix处理的故障类型。

我认为这个模式的普及来源于Michael T. Nygard的书《Release It！》。

Hystrix中的舱壁实现限制对组件的并发调用数量。这样，等待从组件返回的答复的资源（通常是线程）的数量也被限制了。

假设您有一个基于请求的多线程应用程序（例如典型的Web应用程序），它使用三个不同的组件A、B和C。如果对组件C的请求开始挂起，则最终所有请求处理线程都将挂起等待来自C的回答。这将使应用程序完全无响应。如果对C的请求处理缓慢，当负载足够高时，我们也有类似的问题。

Hystrix对舱壁模式的实现限制了对组件的并发调用数量，并在这种情况下拯救了应用程序。假设我们有30个请求处理线程，并且对C有10个并发调用限制。那么最多只有10个请求处理线程在调用C时会挂起，其他20个线程仍然可以处理请求并使用A和B组件。

Hystrix有两种不同的舱壁方法：线程隔离和信号量隔离。

标准方法是将所有对组件C的请求都交给一个具有固定线程数和无（或小）请求队列的单独线程池处理。

另一种方法是让所有调用者在请求C之前获取许可证（超时为0）。如果不能从信号量中获取许可证，则不会传递对C的调用。

线程池方法的优点是可以设置传递给C的请求超时时间，而使用信号量时则不可能实现此操作。