4. 舱壁隔离模式（Bulkhead）：线程池隔离与信号量隔离的原理

舱壁隔离模式（Bulkhead Pattern）源自船舶设计——将船体分隔成多个独立水密隔舱，单个隔舱进水不会导致整船沉没。在分布式系统中，该模式用于限制故障传播范围：防止一个下游服务的延迟或崩溃，耗尽整个应用线程池，导致所有服务不可用。

4.1 为什么需要舱壁隔离？

在未隔离的架构中，所有下游调用共享同一个线程池。当某个下游服务响应变慢（例如从 5ms 飙升至 5s），调用线程会被长时间阻塞。一旦并发请求数超过线程池上限，新请求将排队等待，最终导致：

• 线程池耗尽：所有工作线程被慢调用占据，无法处理其他健康服务的请求。
• 资源竞争加剧：CPU 上下文切换飙升，内存中积压大量等待任务。
• 级联故障：本服务不可用，进而影响上游调用方。

4.2 两种隔离策略：线程池隔离 vs 信号量隔离

主流实现（如 Hystrix、Resilience4j）提供两种隔离机制，它们在资源管理方式和适用场景上存在显著差异：

4.3 线程池隔离原理

线程池隔离为每个下游依赖（或依赖组）分配一个独立的线程池。请求线程将任务提交到对应线程池后立即返回，由线程池中的工作线程执行实际调用。即使某个下游线程池被慢调用填满，其他线程池仍可正常处理请求。

4.4 信号量隔离原理

信号量隔离不创建独立线程，而是通过计数器限制对下游服务的最大并发请求数。请求线程直接执行调用，仅在获取信号量时可能阻塞。信号量隔离的开销远低于线程池隔离，但无法提供独立的超时控制和线程上下文。

4.5 如何选择隔离策略？

选择策略时需权衡隔离强度与性能开销。以下决策树可辅助判断：

1. 调用是否为网络 I/O？（HTTP、RPC、数据库）→ 是，优先考虑线程池隔离；否，进入下一步。
2. 是否需要独立超时控制？→ 是，选择线程池隔离；否，进入下一步。
3. 调用延迟是否极低（< 1ms）且吞吐要求极高？→ 是，选择信号量隔离；否，线程池隔离更安全。
4. 线程资源是否受限？（如容器内存较小）→ 信号量隔离更轻量。

4.6 实战配置示例（Resilience4j）

以下展示 Resilience4j 中线程池隔离与信号量隔离的典型配置：

// 线程池隔离配置
ThreadPoolBulkheadConfig config = ThreadPoolBulkheadConfig.custom()
    .maxThreadPoolSize(10)          // 最大线程数
    .coreThreadPoolSize(5)          // 核心线程数
    .queueCapacity(5)               // 等待队列容量
    .keepAliveDuration(Duration.ofSeconds(30))
    .build();

// 信号量隔离配置
SemaphoreBulkheadConfig semaphoreConfig = SemaphoreBulkheadConfig.custom()
    .maxConcurrentCalls(20)         // 最大并发数
    .maxWaitDuration(Duration.ofMillis(500))  // 等待超时
    .fair(true)                     // 公平模式
    .build();

// 创建舱壁实例
BulkheadRegistry registry = BulkheadRegistry.ofDefaults();
Bulkhead bulkhead = registry.bulkhead("serviceA", semaphoreConfig);

4.7 舱壁隔离的监控与调优

部署后需持续监控以下指标，及时调整隔离参数：