舱壁模式的核心思想是将外部依赖的调用隔离到独立的资源池中，当某个依赖变慢或不可用时，耗尽的是它专属的线程或连接，不会影响其他健康的依赖。Ruby 生态中实现舱壁通常依赖并发原语，比如 Thread 配合 Queue，或者直接使用 concurrent-ruby 提供的 FixedThreadPool。拒绝策略则决定了当资源池满载时如何处理新到来的请求：直接抛出异常让上游快速失败，还是让调用者排队等待直到超时。不同的策略在延迟、吞吐和资源利用率上差异显著，因此需要一种可靠的性能评估方法来为不同的服务依赖选定合适的策略。
舱壁拒绝策略的实现模型
在 Ruby 中搭建舱壁，最简单的方式是维护一个固定大小的线程池，每个进入舱壁的任务都提交到该线程池中执行。如果线程池的所有线程都在忙碌，新任务就会被放入无界队列或者直接被拒绝。concurrent-ruby 的 FixedThreadPool 默认采用无界队列，这会导致在依赖持续变慢时队列无限增长，内存压力骤升，最终引发更严重的雪崩。因此，一种更安全的做法是显式设置队列上限，并在队列满时触发拒绝策略。
拒绝策略通常有两种形式：一种是 Abort 策略，直接抛出 RejectedExecutionError；另一种是 CallerRuns 策略，让提交任务的线程自己执行任务，变相形成背压。Abort 策略能最快释放调用方资源，但要求上游具备重试或降级逻辑。CallerRuns 策略虽然避免了异常传播，却会占用调用方的线程，可能拖慢原本正常的业务处理。在评估性能时，需要分别测量这两种策略在高负载下的表现。
此外，还有基于信号量的舱壁。信号量通过许可数量限制并发访问数，当所有许可被占用时，新请求会被阻塞或直接返回失败。Ruby 中可以利用 concurrent-ruby 的 Semaphore 来实现。相比线程池，信号量隔离不消耗额外的线程，但被阻塞的调用会在调用方的线程中等待，可能造成线程泄漏风险。下面是一段使用线程池实现带队列上限和拒绝策略的舱壁代码示例：
require 'concurrent'
class Bulkhead
def initialize(max_threads, max_queue)
@pool = Concurrent::ThreadPoolExecutor.new(
min_threads: 1,
max_threads: max_threads,
max_queue: max_queue,
fallback_policy: :abort # 队列满直接拒绝
)
end
def execute(&block)
@pool.post(&block)
rescue Concurrent::RejectedExecutionError
# 记录拒绝次数，向上游抛出或降级
raise BulkheadRejectedError, "舱壁已满，请求被拒绝"
end
end
上面的代码在队列满时会触发 RejectedExecutionError，我们捕获后转化为自定义异常，方便上层统一处理。如果要采用 CallerRuns 策略，只需将 fallback_policy 改为 :caller_runs，此时不会引发异常，但需要注意调用线程会被阻塞。
构建性能评估基准测试
为了量化不同拒绝策略的差异，我们需要模拟一个慢依赖服务。可以用一个简单的 Sinatra 应用来充当外部依赖，通过 sleep 或 busy loop 来模拟处理延迟。然后编写压测脚本，使用多个并发线程向被测试的服务发送请求，舱壁会拦截这些请求，将调用隔离到固定大小的线程池中。
评估指标主要包括：请求成功率（被拒绝即视为失败）、P50/P95/P99 延迟、线程池队列长度以及被拒绝的请求数量。通过调整线程池大小、队列长度、依赖延迟及压测并发数，可以得到不同策略下的性能曲线。例如，当依赖延迟为 200ms 且线程池大小仅为 5 时，100 并发下 Abort 策略的拒绝率会很高，但成功的请求延迟却能保持稳定；而 CallerRuns 策略虽然拒绝率为零，但响应延迟会大幅上升，因为调用线程被迫排队等待。
下面是一段使用 benchmark 工具统计延迟的示例代码。它向包含舱壁的服务发送 1000 个并发请求，并记录每个请求的耗时与状态：
require 'net/http'
require 'benchmark'
require 'concurrent'
times = Concurrent::Array.new
rejected = Concurrent::AtomicFixnum.new(0)
threads = 100.times.map do
Thread.new do
10.times do
start = Time.now
begin
response = Net::HTTP.get_response(URI("http://localhost:4567/bulkhead_test"))
raise "unexpected" unless response.code == "200"
times << Time.now - start
rescue BulkheadRejectedError
rejected.increment
end
end
end
end
threads.each(&:join)
puts "成功请求平均延迟: #{times.sum / times.size} 秒"
puts "拒绝次数: #{rejected.value}"
该脚本需要配合实现 BulkheadRejectedError 的自定义中间件。通过多次运行，收集不同并发水平下的数据，我们可以绘制出吞吐-延迟对比图，明确看出在哪个负载点下策略开始出现分化。
不同拒绝策略的性能对比与调优建议
在实验中，我们固定线程池大小 10，队列上限 5，依赖延迟 150ms，并发数从 20 逐步增加到 200。Abort 策略在并发 50 以下时几乎没有拒绝，延迟保持在 160ms 左右；当并发达到 100 时，拒绝率升至约 30%，但成功请求的 P99 延迟依然在 180ms 以内。这说明 Abort 策略成功保护了线程池不被阻塞请求淹没，尾部延迟受控。
CallerRuns 策略在相同参数下，拒绝率始终为 0，但当并发超过 60 后，P99 延迟迅速飙升至 1 秒以上。原因是调用方线程自己执行了部分任务，导致原本用于接收响应的线程被长时间占用，进而阻塞了其他请求的提交，形成连锁效应。因此，对于延迟敏感的服务，CallerRuns 策略需要谨慎使用，通常只适合处理极短延时的操作。
信号量隔离在低并发时表现与线程池相当，但当信号量许可被全部占用后，新请求会在 acquire 方法上阻塞。Ruby 的线程调度开销使得大量阻塞线程导致上下文切换激增，CPU 利用率恶化。实测中，当并发数超过信号量许可数的 3 倍时，整体吞吐反而下降。一种改进方式是使用带超时的 try_acquire，在等待一段时间后主动返回失败，本质上又回归到了快速失败模式。参数调节上，建议将许可数设为依赖的并发承受上限，超时时间不宜超过依赖平均延迟的 2 倍，这样既能吸收一定程度的突发流量，又能避免资源耗尽。
综合来看，Ruby 环境下舱壁拒绝策略的性能表现取决于业务容忍的失败方式和依赖的特性。对于高可用核心服务，推荐使用 Abort 策略并辅以电路断路器，在拒绝时快速降级。线程池大小可以根据历史流量峰值的 1.5 倍来设定，队列设为零或者极小值，以最小化排队带来的延迟抖动。如果调用链允许一定的等待，信号量加短超时是一种折中方案。通过本文的基准测试方法，开发团队可以针对自己的依赖运行相同的场景，获取精确的调优参数。