面经策

调用第三方接口应注意哪些问题？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

调用第三方接口，我把要点按事前评估、调用防护、事后兜底组织——第三方是我们不可控的风险面，治理思路是把"信任"变成"验证"。

事前：接入评估

  • 明确对方 SLA（可用性承诺、限流配额、计费方式）并写进合同——出问题时这是索赔和免责依据
  • 确认数据合规（个人信息出境、敏感数据脱敏要求）
  • 验证幂等语义：重复请求对方会怎样？支付类接口不幂等就是资损定时炸弹

调用防护（技术核心）

  • 超时必须设：按对方 P99 设定，默认超时配置（几十秒）会把线程池拖死
  • 重试要克制：只重试幂等的读接口，带退避（1s/2s/4s），次数 ≤2；支付类用"查询补偿"代替盲目重试
  • 熔断隔离：第三方故障时快速失败，独立线程池/信号量隔离，不能让外部依赖拖垮主流程——第三方挂而我们全站挂，是最冤枉的事故
  • 配额管理：对方限流 100 QPS，我方用令牌桶控在 95，主动排队优于被动被打回

事后：兜底与对账（架构师最强调）

  • 异步化：非核心链路（通知、回填）MQ 异步，失败可补偿
  • 对账为准：资金类结果永远以对账文件为准，不信回调、不信接口返回，日终核对差异自动处理
  • 降级预案：对方不可用时返回兜底数据或转人工，提前定义业务能接受的最长不可用时间

收尾：我的经验法则是把第三方当成"随时会宕机的队友"设计隔离与兜底，同时把商务条款（SLA、赔付）当作技术方案的组成部分——技术防线和合同防线缺一不可。

🏗 系统架构师 ​

调第三方接口，我的原则是：把第三方当成最不可信、最不稳定的依赖来设计。按调用前、中、后讲。

调用前：契约与准入

  • 确认 SLA 与限流配额（QPS/日配额），我们的峰值流量是否在配额内；申请独立的 appKey/账号，权限最小化
  • 幂等设计：带唯一请求号（bizId/traceId），防止超时重试造成重复扣款/重复下单
  • 敏感数据传输确认加密方式（HTTPS、签名、脱敏），符合合规要求

调用中：防护三件套

  1. 超时必设：connect 与 read 超时分开，默认值不可接受；总预算小于上游留给我的时间
  2. 重试克制：只重试幂等接口、只在网络错误/5xx 时重试，指数退避 + 抖动，最多 2~3 次；4xx 不重试
  3. 熔断隔离：第三方错误率超阈值直接熔断快速失败，防止它的抖动拖垮我的线程池；用独立的连接池/信号量与主业务隔离（舱壁模式），绝不能第三方一慢我就全站雪崩

调用后：可观测与对账

  • 全链路 traceId 透传，出入参（脱敏后）落日志，故障时可凭流水与第三方扯皮
  • 监控成功率、P99 耗时、配额水位；重要资金类交互每日对账，单边账自动告警
  • 兜底降级：第三方不可用时的业务预案（缓存旧数据、排队异步化、人工介入队列）

一句话总结：超时、重试、幂等、熔断隔离、监控对账十字方针，缺一个都是生产隐患。

💻 全栈开发专家 ​

调第三方接口，我按"失败是常态"来设计，关注八点。

1. 超时必须显式设置

yaml
# RestTemplate/Feign 显式配置，禁止默认无限等待
connectTimeout: 1000   # 连不上=对方挂了，快速失败
readTimeout: 3000      # 按对方 SLA 定

2. 重试要克制：只重试幂等接口（查询类），写操作重试必须带唯一请求号让对方幂等；用指数退避（1s/2s/4s），最多 2~3 次。

3. 熔断降级：Resilience4j CircuitBreaker，失败率 50% 熔断 30s，熔断期间走降级（缓存旧值/默认值/友好提示），防止第三方抖动拖垮自己的线程池。

4. 幂等与防重：外部请求带 requestId，对方按它去重；自己侧对"回调 + 主动查询"做状态机保护。

5. 签名与安全：appKey/secret + HMAC 签名 + timestamp + nonce 防篡改防重放，密钥放配置中心不进代码库。

6. 对账：涉及资金/订单状态的对账是生命线——每日拉对方对账单核对，差异自动修复 + 告警。

7. 异步化：非实时依赖改为 MQ 异步 + 补偿表，别让第三方 RT 出现在用户请求路径上。

8. 可观测：调用日志带 traceId，打点成功率/RT/错误码分布；对接多渠道时留通道切换开关，一家故障切另一家。

踩坑 对方限流返回 200 + 业务错误码 body，看似成功实则失败——必须按业务错误码判断成败，不能只看 HTTP 状态码。