备案站点的第三方服务依赖治理

你的可用性，等于自己的可用性乘以每一个强依赖

短信验证码、支付、地图定位、身份核验、对象存储、消息推送——一个普通站点接入五六个外部服务是常态。对方出故障时，用户不会说「短信服务商挂了」，只会说「你们网站坏了」。更常见的情况甚至不是对方完全不可用，而是变慢：接口从 200 毫秒劣化到 10 秒，你的线程池被占满，全站跟着一起慢。

关键要点

• 先给依赖分级：强依赖挂了核心流程不可用，弱依赖可降级。多数事故的根因是把弱依赖写成了强依赖。
• 每个外部调用都要有超时、资源隔离和事先写好的降级路径。
• 涉及计费和状态的依赖必须对账：同步返回失败，不代表对方没执行。
• 切换供应商的能力要平时留好，不是故障当天现写。

第一步：建依赖台账

记录项	为什么必须有
用途与调用场景	出事时立刻知道影响哪条业务
强依赖 / 弱依赖	决定是拦住流程还是直接降级
超时与重试配置	避免沿用「无超时」的默认值
失败时的降级行为	事前约定，不在故障当天临时讨论
备用供应商与切换方式	能不能切、多久能切完
额度与计费方式	额度用尽的表现和故障几乎一样
状态页与支持联系方式	故障时找谁、怎么升级

台账里最容易空着的是「降级行为」一栏——而这恰恰是故障当天唯一有用的那一栏。

把弱依赖写成强依赖：最常见的错误

典型现场：首页要展示一个第三方数据模块，代码里同步调用、没设超时。对方抖动一次，首页整体打不开。判断标准很简单：这个依赖不可用时，核心流程能不能继续走完？能，就必须做成弱依赖——异步加载、缓存兜底、失败即隐藏，绝不阻塞主流程。

隔离：别让一个依赖拖垮全站

• 独立资源池：每个外部依赖用独立的连接池或并发上限，避免一个慢依赖吃光全部线程。
• 超时与重试：显式配置，并纳入整体超时预算，见 超时设置与重试策略。
• 熔断：错误率超阈值就快速失败，别让请求堆积，见 限流、熔断与服务降级。
• 异步化：发短信、发推送、同步数据这类操作挪到队列里做，主流程不等它，见 消息队列与异步任务运维。

降级预案要提前写好

依赖	故障时的降级动作
短信验证码	切备用通道；仍失败则开放语音或邮箱验证
支付	保留订单，异步查询并补齐支付状态
地图 / 定位	改为手动填写地址
消息推送	进队列延迟补发
文件上传	暂存本地再异步转存，见 对象存储与静态资源托管
非核心数据模块	直接隐藏或展示缓存数据

预案的有效性要靠演练验证，不是写完就算数，方法见 故障演练与预案验证。

对账与补偿：超时不等于没执行

这是外部依赖治理里最容易出资损的一环。调用支付或扣费接口时超时，可能是请求没到、也可能是对方已经执行成功但回包丢了。只按「本次返回失败」处理，就会出现重复扣款或订单状态与对方不一致。

四条原则：

• 最终状态以对方的查询接口为准，不以本次调用的返回为准。
• 请求带幂等键，重试时对方能识别是同一笔，做法见 超时设置与重试策略。
• 定时对账任务扫描差异并自动补偿，任务要幂等可重入，写法见 定时任务运维：幂等、防重与补偿。
• 异步回调要验签、去重、幂等，并且不能假设回调一定送达——必须有主动查询兜底。

判定：到底是谁的问题

故障时最浪费时间的环节，是和对方来回确认「是不是你们的问题」。前提是你有自己的数据：按依赖分别打点成功率、P99 耗时、错误码分布，指标采集见 可观测性建设，告警配置见 备案网站监控告警体系。

只看对方状态页是不够的：状态页更新通常滞后，而且只反映他们认定的故障范围。自己的调用成功率曲线才是第一手证据，也是后续索赔和复盘的依据，复盘口径见 故障响应、复盘与 SLO 实践。

容易被忽略的两类「伪故障」

• 额度或余额用尽：短信包用完、云服务欠费，表现和服务故障一模一样。额度水位要纳入监控，别等用户反馈。
• 凭据过期：API 密钥轮换后没同步、证书到期、白名单 IP 变更，都会让调用突然全失败，凭据管理见 密钥与凭据管理；对接 SDK 的版本升级风险见 依赖升级与供应链安全。

常见坑

• 非核心功能同步调用且无超时：一个展示模块拖垮整个页面。
• 只信同步返回不做对账：超时场景下产生资损或状态不一致。
• 回调不验签不去重：既有安全风险，又会重复处理。
• 没有备用供应商：对方长时间故障时只能干等。
• 只看对方状态页：故障开始半小时后才被确认。

常见问题

第三方接口偶发超时，重试几次就好，需要治理吗？

需要。偶发超时说明链路本身不稳定，一旦对方发生真正的长时间故障，没有隔离和降级的系统会被直接拖垮。而且不加幂等的重试在计费类接口上会带来资损风险。

要不要给每个依赖都准备备用供应商？

按分级来：强依赖（如短信验证码、支付）值得准备备用通道，弱依赖有降级路径即可。关键是接口层做好抽象，切换靠配置而不是改代码发布。

对账任务多久跑一次合适？

资金类建议高频（如每几分钟扫一次近窗口数据）加每日全量对账；非资金类每日一次通常够用。对账要能自动生成差异清单，并对可自动补偿的部分直接补偿。

对方故障期间要不要对外公告？

影响到用户可感知功能时应当公告，说明受影响范围和预计恢复方式。公告口径与故障记录纳入统一的复盘流程，比事后解释更有效。

资料来源

主流云服务与支付、短信类开放平台公开文档中关于超时、幂等、回调验签与对账接口的说明，以及通用的依赖隔离与降级实践资料。本文为通用运维说明，仅供参考，具体以各服务商最新官方文档与合同约定为准。