SOAP协议诞生至今已有二十多年，凭借严格的WSDL契约、内建的安全规范和跨平台特性，仍然在金融、电信、政务等对稳定性要求极高的领域占据重要地位。然而SOAP通常构建在HTTP之上，而HTTP本质上是一个无状态、不保证送达的协议，网络抖动、服务端重启、超时丢包都可能让一次SOAP调用悄无声息地失败。要让SOAP消息真正可靠，必须在应用层引入重试机制，并配合幂等性控制，才能做到消息不丢、不重、不乱序。本文将从原理到代码，完整拆解这套机制的设计思路。
一、SOAP消息为什么会失败：先搞清楚重试的对象
在动手写重试代码之前，需要先理解SOAP消息在传输链路上可能遭遇的失败类型，因为不同类型的失败对应完全不同的处理策略。盲目重试不仅浪费资源，还可能引发业务数据错乱。
第一类是瞬时性失败，比如网络闪断、DNS解析抖动、服务端线程池打满导致的临时拒绝。这类失败的特点是过一会儿再试大概率能成功，正是重试机制的用武之地。第二类是持久性失败，比如WSDL契约不匹配、SOAP Fault中返回的业务错误（余额不足、参数非法），这类问题重试一万次也不会成功，应该立刻失败并进入异常处理流程。第三类是结果不确定失败，典型场景是客户端发出请求后网络超时，但服务端可能已经处理成功。这是最危险的一类，因为它直接威胁到幂等性，也是重试机制设计的核心难点。
区分这三类失败的依据主要是异常类型和SOAP Fault的content。HTTP层面的ConnectException、503状态码基本可以判定为瞬时性失败；而收到了正常的SOAP响应、其中带有业务错误码的Fault，则属于持久性失败，必须排除在重试范围之外。很多初级开发者把所有异常一股脑塞进重试循环，结果业务故障期间系统疯狂空转，反而放大了问题。
二、幂等性是重试的前提：没有幂等就没有资格重试
重试机制有一条铁律：只有幂等操作才允许自动重试。所谓幂等，指的是同一个操作执行一次和执行多次，对系统状态产生的影响完全一致。举个典型例子，一个扣款接口如果不做幂等控制，第一次请求超时后客户端重试，服务端执行了两次扣款，用户就会被扣两次钱，这类事故在生产环境并不罕见。
在SOAP体系中实现幂等，最常用的方案是消息唯一标识，也就是在SOAP Header中携带一个全局唯一的MessageID。服务端接收到消息后，先根据这个ID查询是否已经处理过，处理过则直接返回上次的处理结果，不再执行业务逻辑。下面是一个携带幂等标识的SOAP消息示例：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:MessageID>urn:uuid:550e8400-e29b-41d4-a716-446655440000</wsa:MessageID>
<wsa:To>http://service.example.org/PaymentService</wsa:To>
<wsa:Action>http://service.example.org/deduct</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<deduct xmlns="http://service.example.org/">
<accountId>A10086</accountId>
<amount>500.00</amount>
</deduct>
</soapenv:Body>
</soapenv:Envelope>
服务端通常会用数据库唯一索引配合Redis缓存来记录已处理的MessageID。收到请求先查缓存，命中则返回缓存的响应；未命中则加分布式锁执行业务，处理完成后写入记录再返回。这个去重层的存在，使得客户端可以放心大胆地重试，而不必担心副作用被重复执行。
三、重试策略核心算法：指数退避与抖动
确定了可以重试之后，下一个问题是多久重试一次、重试几次。固定间隔重试是最朴素的方案，比如失败后等3秒再试。但在高并发场景下，如果服务端因过载而拒绝请求，所有客户端都在同一时刻重试，会形成重试风暴，把还没恢复的服务再次打垮。
业界标准做法是指数退避加随机抖动。每次重试的等待时间按指数增长，比如第一次等1秒、第二次2秒、第四次8秒，同时叠加一个随机偏移量，让各个客户端的重试时刻分散开。此外必须设置最大重试次数上限，超过上限后进入死信处理，由人工介入或补偿任务接管。下面是基于Java实现的完整重试工具类：
public class SoapRetryExecutor {
private static final int MAX_RETRIES = 5;
private static final long BASE_DELAY_MS = 1000;
private static final Random RANDOM = new Random();
public static String executeWithRetry(SoapCallTask task) throws Exception {
Exception lastException = null;
for (int attempt = 0; attempt <= MAX_RETRIES; attempt++) {
try {
return task.call();
} catch (SoapRetryableException e) {
// 只重试瞬时性异常，业务Fault直接抛出
lastException = e;
if (attempt == MAX_RETRIES) {
break;
}
long backoff = (long) (BASE_DELAY_MS * Math.pow(2, attempt));
// 叠加0到500毫秒的随机抖动，避免重试风暴
long jitter = RANDOM.nextInt(500);
Thread.sleep(backoff + jitter);
}
}
throw new Exception("重试次数耗尽，消息进入死信队列", lastException);
}
@FunctionalInterface
public interface SoapCallTask {
String call() throws Exception;
}
}
这段代码的关键点有两个。一是异常分类，SoapRetryableException只包装连接超时、503这类瞬时异常，SOAP Fault业务异常在底层就直接终止重试。二是退避公式BASE_DELAY_MS * 2^attempt + jitter，按照这个公式，五次重试的总耗时约为31秒，既能给服务端足够的恢复时间，又不会让用户等待过久。如果业务对时效敏感，可以把退避上限封顶在某个值，避免等待时间无限膨胀。
四、借助WS-ReliableMessaging实现协议级保障
如果自己造轮子的成本太高，可以直接采用OASIS标准的WS-ReliableMessaging规范，它是专门为SOAP设计的可靠传输协议，在SOAP Header中定义了一套标准的消息确认与重传机制。Apache CXF和Metro都对其提供了开箱即用的支持。
WS-ReliableMessaging的核心思想是消息序列化：客户端把一批消息归入一个Sequence，服务端每收到一条消息就回送一个Acknowledgement。客户端检测到某条消息长时间没有收到确认，便自动重发。规范还提供顺序保证，确保消息按发送顺序到达。在CXF中启用它只需要几个配置项：
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:wsrm="http://cxf.apache.org/ws/rm/manager"
xmlns:cxf="http://cxf.apache.org/core">
<cxf:bus>
<cxf:features>
<wsrm:reliableMessaging>
<wsrm:retransmission>
<wsrm:RetransmissionInterval>2000</wsrm:RetransmissionInterval>
<wsrm:ExponentialBackoff/>
<wsrm:MaxRetransmissions>5</wsrm:MaxRetransmissions>
</wsrm:retransmission>
<wsrm:reliableMessaging>
</cxf:features>
</cxf:bus>
</beans>
注意配置中的ExponentialBackoff元素，说明框架内部同样采用指数退避，与我们手写方案的思路是一致的。WS-ReliableMessaging的优势在于标准化和透明性，业务代码完全不用感知重试逻辑；不足是它只解决传输层面的送达确认，服务端业务处理是否幂等仍需开发者自行保证，而且要求通信双方都支持该规范，在对接第三方老旧系统时未必可用。
五、架构层面的补充：重试之外的兜底手段
再完善的重试机制也有覆盖不到的场景，比如服务端宕机时间超过重试窗口，或者消息必须在稍后处理。此时需要在架构上引入持久化队列做兜底：客户端先把SOAP消息落库或写入消息队列，再由后台任务异步投递，投递成功后标记完成。这样即使应用重启，未完成的消息也不会丢失。
落地时要重点设计三张表：待发送表、已发送表和死信表。后台任务轮询待发送表，调用成功后搬运到已发送表，重试耗尽则进入死信表并触发告警。再配合定时对账任务，比对已发送消息与服务端的处理记录，可以兜住结果不确定失败造成的最终不一致。这一套组合拳打下来，SOAP消息的可靠性就能达到金融级的要求，即使在网络环境糟糕的跨机构对接场景中也能稳定运行。