隔舱模式

将应用程序的元素隔离到池中，这样，如果一个元素发生故障，其他元素可继续工作。

此模式之所以称为“隔舱”(Bulkhead)，是因为它类似于船体的分段区。 如果船体受到破坏，只有受损的分段才会进水，从而可以防止船只下沉。

上下文和问题

基于云的应用程序可以包含多个服务，其中每个服务具有一个或多个使用者。 服务过载或发生故障会影响服务的所有使用者。

此外，一个使用者可以使用每个请求的资源同时向多个服务发送请求。 当使用者向配置不当或无响应的服务发送请求时，可能无法及时释放客户端请求所用的资源。 随着不断地向服务发送请求，这些资源可能会耗尽。 例如，客户端的连接池可能会耗尽。 此时，使用者向其他服务发出的请求会受到影响。 最终，使用者不再能够向其他服务（而不仅仅是原始的无响应服务）发送请求。

资源耗尽问题同样会影响具有多个使用者的服务。 源自一个客户端的大量请求可能耗尽服务中的可用资源。 其他使用者不再能够使用该服务，从而导致连锁故障效应。

解决方案

根据使用者负载和可用性要求，将服务实例分区成不同的组。 此设计有助于隔离故障，即使在发生故障期间，也能为某些使用者保留服务功能。

使用者也可以将资源分区，确保用于调用一个服务的资源不会影响用于调用另一个服务的资源。 例如，对于调用多个服务的使用者，可为其分配每个服务的连接池。 如果某个服务开始发生故障，只有分配给该服务的连接池才会受到影响，因此，使用者可继续使用其他服务。

此模式的优势包括：

• 隔离使用者和服务，防止发生连锁故障。 可在使用者或服务自身的隔舱中隔离对其造成影响的问题，防止整个解决方案发生故障。
• 在发生服务故障时，可以保留一部分功能。 应用程序的其他服务和功能可继续工作。
• 可以部署能够为使用方应用程序提供不同服务质量的服务。 可以配置高优先级使用者池来利用高优先级服务。

下图显示了围绕调用单个服务的连接池构建的隔舱。 如果服务 A 发生故障或导致其他某种问题，该连接池将被隔离，因此，只有使用分配给服务 A 的线程池的工作负荷才受影响。 使用服务 B 和 C 的工作负载不受影响，可继续工作而不会中断。

下图显示了调用单个服务的多个客户端。 为每个客户端分配了独立的服务实例。 客户端 1 发出了过多的请求，使其实例近乎瘫痪。由于每个服务实例相互隔离，其他客户端可继续发出调用。

问题和注意事项

• 围绕应用程序的业务和技术要求定义分区。
• 将服务或使用者分区到隔舱时，请考虑相应技术提供的隔离级别，以及成本、性能和可管理性方面的开销。
• 考虑将隔舱与重试、断路器和限制模式合并，提供更周密的故障处理。
• 将使用者分区到隔舱时，请考虑使用进程、线程池和信号灯。 Netflix Hystrix 和 Polly 等项目提供了一个框架用于创建使用者隔舱。
• 将服务分区到隔舱时，请考虑将这些服务部署到独立的虚拟机、容器或进程。 容器能够以相当低的开销合理平衡资源隔离。
• 使用异步消息通信的服务可以通过不同的队列集进行隔离。 每个队列可以包含专用的实例集用于处理该队列中的消息，或者包含单个实例组，以通过某种算法来取消排队和调度处理负载。
• 确定隔舱的粒度级。 例如，若要将租户分配到不同的分区，可将每个租户放入独立的分区，或者将多个租户放入一个分区。
• 监视每个分区的性能和 SLA。

何时使用此模式

使用此模式可以：

• 隔离使用一组后端服务所用的资源，尤其是应用程序可以提供某种功能级别时，即使某个服务未能响应。
• 将关键使用者与标准使用者相隔离。
• 防止应用程序发生连锁故障。

此模式可能不适用于以下情况：

• 项目中可能不接受资源的低效利用。
• 没有必要提高复杂性