第三方集成项目怎么讲接口契约和异常兜底
业务流程
- 接口对接、契约确认、联调测试。
- 正常调用、响应处理、状态同步。
- 异常重试、补偿调用、对账核对。
详细流程说明
第三方集成项目的核心是”契约精神”和”异常兜底能力”：
- 接口对接阶段：获取第三方 API 文档 → 确认接口契约（请求格式、响应格式、错误码） → 申请测试环境 → 联调测试 → 验收通过。
- 正常调用阶段：构造请求 → 签名验签 → 发送请求 → 处理响应 → 更新业务状态 → 记录调用日志。
- 异常处理阶段：调用失败 → 判断失败类型（网络/业务/第三方） → 重试或降级 → 补偿调用 → 对账核对 → 人工介入（如需要）。
风险点
- 接口契约变更、字段不兼容和版本不一致。
- 调用超时、限流拒绝和服务不可用。
- 响应异常、状态丢失和对账差异。
风险点详解
接口契约变更：
- 第三方未通知直接变更接口，如字段名修改、字段类型变化、新增必填字段。
- 版本升级不兼容，如 V1 废弃但系统仍在调用。
- 文档与实际接口不一致，联调时才发现字段缺失或格式不同。
调用异常：
- 超时：第三方响应慢导致超时，需要设置合理的超时时间（连接超时、读取超时）。
- 限流：超过第三方调用频率限制被拒绝，需要控制调用节奏。
- 服务不可用：第三方服务宕机或维护，需要有降级方案。
数据一致性：
- 调用成功但响应丢失（网络问题），导致本地状态未更新。
- 第三方状态与本地状态不一致，需要定期对账。
- 补偿调用失败，导致业务卡在一个中间状态。
测试策略
- 接口契约做字段比对、版本兼容和变更预警。
- 异常场景做超时、限流、错误码和降级验证。
- 补偿链路做重试、补单和对账闭环。
接口契约测试
- 字段比对：用自动化脚本比对实际响应与文档定义，检测字段增删改。
- 版本兼容：同时测试 V1 和 V2 接口，确保升级平滑过渡。
- 变更预警：每次发版前自动跑契约测试，有变更立即告警。
- Mock 服务：搭建第三方 Mock 服务，不依赖第三方环境即可测试。
异常场景测试
| 异常类型 | 测试方法 | 预期行为 |
|---|---|---|
| 超时 | Mock 延迟响应 | 触发超时处理，记录日志，进入重试队列 |
| 限流 | 短时间内大量请求 | 触发限流保护，排队等待或降级 |
| 500 错误 | Mock 服务端错误 | 重试 N 次后进入补偿队列 |
| 网络断开 | 断网模拟 | 连接失败，快速失败或等待恢复 |
| 签名失败 | 篡改签名参数 | 拒绝请求，记录安全日志 |
补偿与对账测试
- 重试机制：验证重试次数、间隔策略（固定间隔/指数退避）、最大重试时间。
- 补偿调用：模拟调用成功但状态未同步的场景，验证补偿任务能正确执行。
- 对账机制：每日定时对账，比对第三方数据与本地数据，发现差异自动告警或修复。
- 死信处理：重试 N 次仍失败的请求进入死信队列，支持人工介入处理。
可讲成果
- 接口契约校验自动化后，变更对接风险降低。
- 异常场景回归覆盖后，外部服务故障影响可控。
- 对账自动化后，第三方数据差异及时发现。
面试表达示例
项目背景：“我们系统集成了支付、短信、物流等 5 个第三方服务。早期经常出现第三方接口变更导致线上故障，或者第三方服务宕机时我们没有降级方案，影响用户体验。”
我的方案：“我建立了接口契约自动化校验体系，每次发版前自动比对第三方接口变更。同时推动所有第三方调用加入重试、降级和对账机制，确保外部服务故障时业务不中断。”
项目成果：“第三方接口变更导致的线上故障从每月 2-3 次降到零。支付服务宕机时自动降级到备用通道，用户无感知。每日对账能及时发现数据差异，资金安全问题零发生。“
高频追问准备
- 第三方不配合联调怎么办？ 先用 Mock 服务完成内部测试，基于文档定义契约。联调时主要验证真实环境的连通性和签名验证。
- 怎么选择合适的超时时间？ 参考第三方 SLA 和历史响应数据，一般设置为 P99 响应时间的 2-3 倍。同时区分连接超时和读取超时。
- 对账发现差异怎么处理？ 自动对账脚本发现差异后，先尝试自动修复（如重新查询状态）。无法自动修复的生成差异报告，通知人工介入。