Day34-09｜15.4.3 SOAP 协议：面向企业级消息交换的标准化通信机制

一、教材定位与学习目标

15.4.3“SOAP 协议”介绍 Web Service 体系中用于消息封装和交换的标准协议。SOAP 通过 XML 信封组织消息，能够在不同语言、平台和组织之间传递结构化信息，并支持故障、扩展头、身份认证、可靠消息和事务等企业级能力。

高级系统架构设计师考试不会只考 SOAP 的全称和 XML 标签，更常考它的消息模型、协议扩展、传输方式、异常处理、性能代价以及与 REST 的选型差异。学习本篇需要掌握一个原则：SOAP 是通信和消息协议，不是完整的业务架构；它可以支撑 SOA 服务，但服务边界、契约、治理和流程仍需单独设计。

二、SOAP 解决什么问题

企业应用经常跨越不同操作系统、编程语言、网络区域和组织边界。二进制协议和平台专用组件难以实现稳定互操作，SOAP 通过标准化 XML 消息和扩展机制提供相对统一的通信基础。

SOAP 的基本链路可以表示为：

服务消费者 → SOAP 客户端 → SOAP 消息 → 传输协议
                                         ↓
                                  SOAP 服务端

SOAP 不限制必须使用 HTTP，也可以承载在其他传输协议上。消息中可以包含业务数据、路由信息、安全令牌、可靠性信息和故障描述。WSDL 负责描述服务契约，SOAP 负责消息交换，二者通常配合使用。

三、SOAP 消息结构

SOAP 消息通常由 Envelope、Header、Body 和 Fault 等部分组成。

部分	作用	设计关注点
Envelope	消息根元素，标识 SOAP 消息边界	版本和命名空间
Header	扩展信息和控制信息	安全、路由、事务、可靠性
Body	业务请求、响应或故障内容	数据契约和业务语义
Fault	处理失败时的标准故障信息	错误分类和可处理性

3.1 Envelope

Envelope 是 SOAP 消息的根，声明 SOAP 命名空间和版本。消费者和服务端通过它识别消息格式。SOAP 1.1 与 SOAP 1.2 在媒体类型、错误表示和 HTTP 绑定等方面存在差异，版本兼容需要明确。

Header 是可选扩展区域，可以携带安全令牌、消息标识、路由信息、事务上下文和可靠性信息。Header 中的角色、mustUnderstand 和处理顺序可以帮助中间节点处理扩展。扩展设计要控制复杂度，未理解且被要求处理的头不能被静默忽略。

3.3 Body

Body 保存业务消息，如订单查询、支付请求、审批结果或设备上报。消息结构由 WSDL 和 XML Schema 定义，字段语义、精度、时间、状态和错误要清楚。Body 不应直接暴露数据库表结构。

3.4 Fault

Fault 以标准结构表达版本错误、处理方错误、客户端错误和业务或服务端错误。系统还可以在详细信息中携带业务错误码和关联标识。消费者应根据错误类别决定提示、重试、补偿或人工处理。

四、SOAP 的消息交换模型

4.1 请求—响应

客户端发送请求，服务端返回响应，适合查询、校验和同步操作。由于远程调用可能超时或响应丢失，客户端仍需设置截止时间和幂等策略。

4.2 单向消息

客户端只发送消息，服务端不返回业务响应，适合事件、日志和异步通知。传输成功不等于业务处理成功，需要可靠消息、回执、查询或补偿机制。

4.3 异步回调

服务端或第三方在处理完成后向消费者发送结果。回调需要稳定的业务关联键、签名、授权、幂等和防重放。支付成功、审批完成和长任务结果都常采用这种方式。

五、SOAP 与传输协议

SOAP 可以使用 HTTP、SMTP、TCP 或消息中间件承载。HTTP 是常见方式，便于穿越网络和使用现有基础设施；其他传输方式适合特定可靠性、异步或企业内部场景。

传输协议只解决消息到达或承载问题，不能自动保证业务消息不重复、不丢失和按序处理。网络成功、HTTP 成功和业务成功是三个不同层次，系统应在契约中明确每个层次的语义。

六、SOAP Header 与可扩展性

SOAP Header 允许不同规范在不改变业务 Body 的情况下增加横切能力。常见扩展方向包括：

安全：消息签名、加密、令牌和时间戳。
可靠消息：消息编号、确认、重传和顺序。
事务：事务上下文传播和协调。
寻址：消息目标、回复地址和关联标识。
路由：中间节点和最终接收者处理信息。

扩展信息必须有命名空间、处理角色和版本。中间节点只处理自己负责的头，最终接收者处理业务 Body。安全扩展不能替代业务授权，可靠消息也不能替代业务幂等。

七、WS-* 企业级扩展

SOAP 生态中常见 WS-* 规范为企业级服务提供补充能力：

扩展方向	主要能力	典型问题
WS-Security	消息完整性、机密性、身份令牌	密钥、证书和性能
WS-ReliableMessaging	消息确认、重传和顺序	重复、过期和资源管理
WS-Addressing	消息地址、回复和关联	异步和中间节点路由
WS-Coordination	协调上下文	分布式事务复杂度
WS-Policy	声明服务策略和要求	策略兼容和治理

这些扩展有助于跨组织企业集成，但规范栈复杂、工具依赖和性能开销较高。使用时要根据业务必要性选择，不要为简单查询引入不必要的扩展。

八、SOAP 安全设计

8.1 传输安全

HTTPS 可以保护客户端到传输终点之间的通道，适合大多数单跳通信。如果消息经过多个中间节点，单纯传输加密可能无法保证消息在中间处理后的完整性和机密性。

8.2 消息安全

消息级安全可以对 Body 或 Header 进行签名和加密，并携带用户名、证书或令牌。它支持消息存储、转发和多跳，但处理开销、密钥管理和配置复杂度更高。

8.3 授权与审计

身份认证只说明调用者是谁，授权还要判断它能否执行某项操作。支付、订单、合同和客户数据要按组织、角色、资源和操作控制。安全事件、策略变化、签名失败和敏感数据访问要审计。

九、可靠性、幂等与故障处理

SOAP Fault 能表达处理失败，但不能自动恢复业务。系统需要结合消息标识、确认、重试、幂等、状态机和补偿处理真实故障。

重试适合暂时网络故障和服务过载，但必须有限、退避并设置整体截止时间。创建订单、扣款和扣库存等写操作要带业务幂等键；消息确认丢失时，重复到达应返回原结果或忽略副作用；长流程要持久化状态，失败后能够查询真实状态，而不是根据超时直接判定失败。

十、SOAP 的性能与运维成本

XML 文本具有可读性和跨平台优势，但消息冗长、解析和序列化成本高。大消息、深层嵌套和复杂扩展可能增加 CPU、内存和网络压力。可以通过压缩、合理设计消息、批量接口和缓存改善，但不能忽略端到端压测。

运维方面，需要管理 WSDL、XML Schema、命名空间、证书、策略、端点和版本。故障排查要关联消息 ID、业务号、服务版本和中间节点；敏感 Body 不应全部写入日志。不同平台生成代码的差异也需要互操作测试。

十一、SOAP 与 REST 的比较

维度	SOAP	REST
主要抽象	消息和操作	资源和统一接口
契约	WSDL、XML Schema	OpenAPI 等，可强可弱
扩展	WS-* 规范较丰富	多依赖 HTTP、网关和应用约定
安全可靠	支持消息级安全和可靠扩展	常用 HTTPS、令牌、消息和应用机制
消息格式	常见 XML	JSON、XML 等
复杂度	协议栈较重	通常较轻量
适用场景	企业集成、强契约、多跳消息	Web、移动端、轻量 API

二者没有绝对优劣。银行跨组织支付、复杂合同和需要消息级扩展的场景可能适合 SOAP；移动应用查询和互联网开放 API 可能更适合 REST。选择依据是互操作、可靠性、安全、性能、团队能力和现有生态。

十二、案例分析：跨组织保险理赔服务

保险公司需要与医院、合作机构和监管平台交换理赔申请、病历摘要、审核结果和支付通知。消息跨越多个网络区域，要求强契约、签名、审计和可追踪，部分流程持续数天。

可以用 WSDL 和 XML Schema 定义理赔请求、响应、故障和异步回调；SOAP Body 传递业务数据，Header 携带消息 ID、时间戳、身份和签名；经过安全网关和适配器转发，使用消息级签名保证多跳完整性；流程服务保存理赔实例，医院回执和审核结果通过关联键匹配；临时失败有限重试，重复申请使用理赔号和请求号幂等；审核超时进入人工处理；跨系统不能使用长数据库事务，而采用状态机、补偿和对账。

同时，服务应对不同合作机构提供兼容绑定，限制敏感病历访问，日志脱敏，证书轮换，WSDL 和策略版本化。若某一合作方只支持 REST，可以通过适配器转换，不把外部协议差异泄露到核心理赔流程。

十三、课后练习

练习一：选择题

SOAP 消息中主要承载业务请求和响应内容的部分是（）。

A. Envelope

B. Header

C. Body

D. 注册中心

答案：C。 Header 主要携带扩展和控制信息，Body 携带业务内容或 Fault。

练习二：简答题

为什么 SOAP 的 HTTP 成功不能等同于业务处理成功？

参考答案： HTTP 成功只说明传输层或协议层返回了响应，服务可能只是受理请求，业务处理可能尚未完成、已经失败或结果未知。异步流程需要状态查询或回调，写操作需要业务流水和幂等；系统应区分传输成功、消息接收成功、业务受理成功和最终业务成功。

练习三：案例题

某企业使用 SOAP 对接多个合作机构，部分机构网络不稳定，重复理赔和消息丢失频发。请提出改进方案。

参考答案： 应为每条业务消息分配全局消息号和业务请求号，使用 WSDL 和 XML Schema 统一字段、金额、时间、状态和错误契约；在 SOAP Header 中传递消息 ID、时间戳、版本和必要安全信息，采用 HTTPS 或消息级签名保护；对临时网络错误进行有限重试和退避，对重复请求使用业务幂等键、理赔号和唯一约束；可靠消息记录发送、接收、处理和确认状态，确认丢失时查询真实状态，不能无条件重新执行业务；失败消息进入延迟重试和死信，支持修复后重新投递；长流程由状态机持久化并提供人工处理和对账；合作机构通过适配器隔离协议差异，证书和权限集中管理，日志关联消息号并脱敏。通过网络分区、重复消息、超时和故障恢复演练验证。

十四、论文写作素材

本节适合写“论 SOAP 在企业级系统集成中的应用”“论跨组织服务的消息安全与可靠性”或“论 SOA 通信协议选型”。论文可围绕消息结构、WSDL 契约、Header 扩展、安全、可靠消息、异步流程和适配器展开。

写作时要说明 SOAP 适合强契约、跨组织和企业级扩展场景，同时承认 XML 和协议栈带来的性能与治理成本；REST 适合轻量 Web API，但不代表在所有安全和可靠性场景下都更优。最终通过签名失败率、重复率、处理时延、故障恢复时间和对账差异验证方案。

十五、今日复盘清单

我能否说出 SOAP Envelope、Header、Body 和 Fault 的作用？
我能否区分传输成功、消息接收成功和业务成功？
我能否解释 SOAP Header 的安全、可靠性和路由扩展？
我能否设计消息级安全、幂等、重试、死信和补偿？
我能否比较 SOAP 和 REST 的适用场景与代价？
我能否在跨组织案例中写出契约、适配器、审计和版本治理？

本节的核心结论是：SOAP 通过标准化 XML 信封和可扩展消息头，为跨平台、跨组织的企业服务提供强契约、消息安全、可靠传输和事务扩展基础。它不能替代业务边界和治理，实际应用必须结合 WSDL、身份授权、幂等、状态机、补偿、审计和性能优化进行整体设计。