Rails中基于Savon实现多SOAP服务器实例故障转移的技术问询

首先明确一点：Savon本身没有内置多端点自动故障转移的配置项，需要我们自己实现重试和切换逻辑。先看看你现有方案的几个核心问题，再给出更简洁可靠的实现方案。

你现有方案的问题分析 #

1. 数据库状态标记的并发风险：用数据库字段标记活跃服务器，高并发场景下多个请求可能同时读取到同一个"活跃"服务器，随后同时执行切换操作，导致状态混乱，甚至出现多服务器被标记为活跃的情况。
2. 硬编码IP的扩展性差：shift_oms_server方法里把三个IP写死，后续新增或替换服务器必须修改代码，维护成本高。
3. 异常处理覆盖不全：你只捕获了HTTPServerException，但实际请求失败还可能出现连接超时（Timeout::Error）、连接被拒绝（Errno::ECONNREFUSED）、Socket错误等情况，这些异常不会触发你的切换逻辑。
4. 重试逻辑缺失：你只在异常后切换一次服务器，没有循环尝试所有可用端点，可能切换到的下一个服务器也不可用。

更简洁可靠的故障转移实现 #

我们可以抛弃数据库状态维护，直接维护一个可用服务器端点列表，在请求失败时按顺序尝试下一个端点，直到所有端点都尝试完毕。

步骤1：定义端点列表 #

把所有SOAP服务器的端点存到一个数组里，后续新增/修改只需要调整这个数组：

# 可放到config/initializers/savon.rb或业务模型中
SOAP_ENDPOINTS = [
  "http://XXX.XXX.XXX.1:15043/enmac/SOAP",
  "http://XXX.XXX.XXX.2:15043/enmac/SOAP",
  "http://XXX.XXX.XXX.3:15043/enmac/SOAP"
].freeze

步骤2：封装带故障转移的请求方法 #

写一个通用方法，负责遍历端点、初始化客户端、捕获异常并重试：

def with_soap_fault_tolerance
  retry_count = 0
  current_index = 0

  begin
    # 初始化当前端点的Savon客户端
    client = Savon.client(
      endpoint: SOAP_ENDPOINTS[current_index],
      namespace: '',
      convert_request_keys_to: :camelcase,
      env_namespace: 'SOAP-ENV',
      namespace_identifier: nil,
      log: true,
      log_level: :info,
      pretty_print_xml: true,
      read_timeout: 90,
      open_timeout: 90,
      headers: { "Accept-Encoding" => "gzip" }
    )

    # 将客户端传递给调用方，执行实际SOAP请求
    yield client

  rescue HTTPServerException, Timeout::Error, SocketError, Errno::ECONNREFUSED => e
    retry_count += 1
    current_index = (current_index + 1) % SOAP_ENDPOINTS.size

    if retry_count < SOAP_ENDPOINTS.size
      Rails.logger.warn("SOAP请求失败: #{e.message}, 切换到下一个端点: #{SOAP_ENDPOINTS[current_index]}")
      retry # 使用新端点重试
    else
      Rails.logger.error("所有SOAP端点均不可用: #{e.message}")
      raise # 所有端点失败，抛出异常让上层处理
    end
  end
end

步骤3：使用故障转移方法发起请求 #

在业务代码里调用这个方法，只需关注实际的SOAP操作：

# 示例：发起某个SOAP请求
response = with_soap_fault_tolerance do |client|
  client.call(:your_soap_operation, message: { 
    order_id: '12345',
    amount: 99.99
  })
end

# 处理响应数据
parsed_response = response.body[:your_operation_response][:result]

额外优化建议 #

1. 健康检查机制：如果服务器经常出现故障，可以定期（比如用Sidekiq Cron）探测所有端点的可用性，维护一个"可用端点列表"，请求时直接从可用列表选取，减少重试次数。
2. 指数退避重试：如果服务器是暂时不可用，可以在重试时加入短暂延迟（比如第一次等1秒，第二次等2秒），避免频繁请求加重服务器负担。
3. 客户端实例缓存：如果多个请求连续发起，可以缓存当前可用的客户端实例，直到它失败再切换，减少初始化开销。

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