General

一般来说，舱壁模式的目标是避免系统的一个部分出现故障，从而使整个系统瘫痪。这个术语来源于船舶被分隔在不同的防水隔间，以避免单个船体破裂淹没整艘船; 它只会淹没一个舱壁。

舱壁模式的实现可以采取多种形式，这取决于您希望保护系统不受哪种类型的故障的影响。在这个答案中，我将只讨论 Hystrix 处理的错误类型。

我认为舱壁模式是由迈克尔 · T · 奈加德的书 释放它！推广的。

Hystrix 能解决什么

Hystrix limits the number of concurrent calls to a component中的舱壁实现。这样，等待组件响应的资源(通常是线程)的数量是有限的。

假设您有一个基于请求的多线程应用程序(例如一个典型的 Web 应用程序) ，它使用三个不同的组件: A、 B和 C。如果对组件 C的请求开始挂起，最终所有处理请求的线程都将挂起，等待来自 C的答复。这将使应用程序完全没有响应。如果对 C的请求处理得很慢，那么如果负载足够高，我们也会遇到类似的问题。

Hystrix' implementation of the bulkhead pattern limits the number of concurrent calls to a component and would have saved the application in this case. Assume we have 30 request handling threads and there is a limit of 10 concurrent calls to C. Then at most 10 request handling threads can hang when calling C, the other 20 threads can still handle requests and use components A and B.

Hystrix 的到来

Hystrix 有两种不同的隔离方式: 线隔离和信号隔离。

线程隔离

标准的方法是将对组件 C的所有请求移交给一个单独的线程池，该线程池有固定数量的线程，没有(或者只有很小的)请求队列。

信号隔离

另一种方法是让所有调用方在请求 C之前获得许可(0超时)。如果不能从信号量获得许可，则不会传递对 C的调用。

差异

线程池方法的优点是传递给 C的请求可以超时，这在使用信号量时是不可能的。

这是受到 Netflix Hystrix 启发的 Resilience4j 舱壁 运行时解释的好例子。

下面的示例配置可能会提供一些明确的用法。

示例配置: 在任何给定时间允许最多5个并发调用。让其他调用等待，直到进程内5个并发调用中的一个完成，或者直到最多2秒钟。

我们的想法是不要让任何系统的负载超过它们所能消耗的。如果传入负载大于消耗，那么等待合理的时间或者只是超时并选择备用路径。

Bulkhead pattern is a design pattern for 隔离和容错.

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

You can refer to this: 舱壁模式