分布式系统Bulkhead与CircuitBreaker模式差异及常见问题解析

问题1：Bulkhead模式的必要性及相比CircuitBreaker的优势 #

首先明确结论：Bulkhead模式是不可替代的，和熔断器是互补关系而非竞争关系，核心原因是熔断器仅在依赖完全故障、达到熔断阈值后才会生效，无法覆盖故障前的性能异常场景。
Bulkhead相比熔断器的核心优势如下：

• 可应对非故障类的性能波动：当下游依赖没有完全故障，只是响应变慢、耗时变长但未达到熔断触发阈值时，熔断器不会介入，此时如果没有舱壁隔离，大量慢请求会占满整个服务的线程池，导致其他正常依赖的调用也无法执行。
• 填补熔断机制的生效空窗：熔断器触发后会进入冷却时间窗口，半开状态下需要发送探测请求验证依赖是否恢复，这个过程中如果没有舱壁隔离，仍可能有大量请求被阻塞占满资源。
• 多依赖场景下的资源隔离更稳定：如果服务同时调用多个下游依赖，舱壁可以给每个依赖分配独立的资源配额，任意一个依赖出现异常，只会影响自身分配的配额，完全不会影响其他依赖的调用，而熔断器仅能在单依赖故障后切断请求，无法阻止慢请求占用全局资源。
• 保障降级逻辑的可用：如果全局线程池被异常依赖的请求占满，就算熔断器触发，降级逻辑也没有可用线程执行，舱壁可以预留足够的资源给正常逻辑和降级逻辑使用。

问题2：Bulkhead模式的实现位置澄清 #

两种说法都成立，对应舱壁模式的两种不同应用场景，不存在冲突：

• 你理解的上游服务为下游依赖划分线程是客户端侧舱壁的实现，也是微服务跨服务调用场景下最常用的实现方式：上游调用方为每个不同的下游依赖分配独立的线程池/信号量配额，避免单个下游异常拖垮整个上游服务。
• 你看到的「故障服务为自身划分线程」是服务端侧舱壁的实现：被调用的服务自身也会做内部的资源隔离，比如一个服务同时提供查询、写入两类接口，服务端会给两类接口分配独立的线程池，避免查询接口耗时升高占满所有线程，导致写入接口完全不可用。

问题3：Bulkhead线程划分代码示例 #

以下以Java生态常用的Resilience4j组件为例，展示上游服务为不同下游依赖分配独立并发配额的实现：

第一步：定义不同下游对应的舱壁实例 #

import io.github.resilience4j.bulkhead.Bulkhead;
import io.github.resilience4j.bulkhead.BulkheadConfig;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.time.Duration;

@Configuration
public class BulkheadConfiguration {
    // 给下游用户服务分配独立舱壁，最大并发15
    @Bean
    public Bulkhead userServiceBulkhead() {
        BulkheadConfig config = BulkheadConfig.custom()
                .maxConcurrentCalls(15)
                .maxWaitDuration(Duration.ofMillis(100))
                .build();
        return Bulkhead.of("userService", config);
    }

    // 给下游订单服务分配独立舱壁，最大并发10
    @Bean
    public Bulkhead orderServiceBulkhead() {
        BulkheadConfig config = BulkheadConfig.custom()
                .maxConcurrentCalls(10)
                .maxWaitDuration(Duration.ofMillis(100))
                .build();
        return Bulkhead.of("orderService", config);
    }
}

第二步：使用舱壁包裹下游调用逻辑 #

import io.github.resilience4j.bulkhead.Bulkhead;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class RemoteInvokeService {
    @Autowired
    private Bulkhead userServiceBulkhead;
    @Autowired
    private Bulkhead orderServiceBulkhead;
    @Autowired
    private UserClient userClient;
    @Autowired
    private OrderClient orderClient;

    public User queryUser(Long userId) {
        // 调用用户服务时使用对应舱壁进行资源限制
        return Bulkhead.decorateSupplier(userServiceBulkhead, 
                () -> userClient.getUserById(userId)).get();
    }

    public Order queryOrder(Long orderId) {
        // 调用订单服务时使用对应舱壁进行资源限制
        return Bulkhead.decorateSupplier(orderServiceBulkhead, 
                () -> orderClient.getOrderById(orderId)).get();
    }
}

上述实现中，用户服务和订单服务的调用完全隔离，就算订单服务出现超时等异常，最多只会占用10个线程，不会影响用户服务的调用，也不会占满整个应用的全局线程池。

内容的提问来源于stack exchange，提问作者Shivanshu