第三方服务故障场景题回答骨架
场景背景
现代系统大量依赖第三方服务，如支付渠道、短信服务、物流查询、身份验证、AI 接口等。第三方服务的稳定性不在我们控制范围内，但故障会影响我们的业务。面试高频的原因有三：
第一，第三方服务故障是生产环境的常见问题，测试策略的完备性直接影响系统可用性。
第二，降级和熔断机制的设计与验证是分布式系统测试的核心能力。
第三，故障发生时的用户体验和数据一致性是面试官关注的重点。
标准回答框架
- 先讲处理目标：业务不中断、用户感知可控、故障可恢复。
- 再讲风险点：服务超时、响应错误、熔断触发、数据不一致。
- 然后讲测试策略：故障注入、超时降级、熔断恢复、补偿重试。
- 最后补监控兜底：服务健康监控、熔断状态告警、补偿队列和人工干预。
处理目标详解
- 业务不中断：第三方服务故障时，核心业务仍能正常运行，如支付渠道 A 不可用时切换到渠道 B。
- 用户感知可控：用户收到友好的错误提示和重试引导，而不是系统报错或白屏。
- 故障可恢复：第三方服务恢复后，系统能自动恢复正常，积压的请求能自动处理。
风险点详解
服务超时：
- 第三方服务响应慢，导致请求超时。
- 超时时间设置不合理，太短导致误判，太长导致资源占用。
- 超时后重试策略不当，加重第三方服务负担。
响应错误：
- 第三方服务返回错误码（500、503），业务系统未正确处理。
- 错误码含义不明确，无法区分是临时故障还是永久故障。
- 错误响应格式变更，导致解析失败。
熔断触发：
- 熔断阈值设置不合理，太敏感导致频繁熔断，太迟钝导致故障扩散。
- 熔断后没有降级方案，用户请求直接失败。
- 熔断恢复后没有半开状态验证，直接全量请求可能再次触发熔断。
数据不一致：
- 熔断期间部分请求成功、部分失败，导致数据状态不一致。
- 补偿机制不完善，故障恢复后数据无法自动修复。
- 对账机制缺失，无法发现第三方数据与本地数据的差异。
测试策略
故障注入测试
| 故障类型 | 注入方法 | 验证要点 |
|---|---|---|
| 超时 | Mock 服务延迟响应（如 10s） | 超时处理触发、降级逻辑生效、用户收到友好提示 |
| 500 错误 | Mock 服务返回 500 | 重试机制触发、达到最大重试后降级、错误日志记录 |
| 服务不可用 | Mock 服务拒绝连接 | 快速失败或切换备用服务、熔断器打开 |
| 响应格式错误 | Mock 服务返回异常格式 | 异常捕获、降级处理、不影响其他请求 |
降级策略测试
- 功能降级：非核心功能暂时关闭，如推荐服务不可用时展示默认推荐。
- 数据降级：使用缓存数据或默认数据，如用户画像服务不可用时使用默认画像。
- 路由降级：切换到备用服务，如主支付渠道不可用时切换到备用渠道。
- 限流降级：限制请求频率，保护第三方服务恢复，如每秒只允许 10 个请求。
熔断机制测试
熔断器三状态：
- 关闭状态：正常请求，错误率低于阈值。
- 打开状态：错误率超过阈值，请求直接拒绝，走降级逻辑。
- 半开状态：熔断一段时间后，允许少量请求通过，验证服务是否恢复。
测试要点：
- 验证熔断阈值触发条件（如 50% 请求失败、连续 10 次超时）。
- 验证熔断打开后请求快速失败，不等待超时。
- 验证半开状态下成功请求后熔断器关闭，失败则重新打开。
监控兜底
- 服务健康监控：实时监控第三方服务的响应时间、错误率、可用性。
- 熔断状态告警：熔断器状态变化时告警，通知运维和开发。
- 补偿队列：失败的请求进入补偿队列，定时重试或人工处理。
- 人工干预：提供管理界面，支持手动触发重试、切换服务、修改配置。
高频追问
第三方服务超时你怎么测降级逻辑？
通过模拟超时和错误响应，验证降级策略是否正确触发、用户体验是否可控。
测试方法：
- 用 Mock 工具（如 WireMock、MockServer）模拟第三方服务延迟响应。
- 设置不同的超时时间（如 1s、3s、5s），验证超时处理逻辑。
- 验证降级逻辑：返回缓存数据、默认数据、友好错误提示。
- 验证用户体验：页面不白屏、有明确提示、可重试操作。
熔断恢复后数据不一致怎么办？
测试要覆盖熔断期间数据补偿、恢复后数据比对和人工修复机制，确保最终一致。
补偿策略：
- 自动补偿：熔断期间失败的请求进入补偿队列，服务恢复后自动重试。
- 对账修复：定时对账发现数据差异，自动或人工修复。
- 人工介入：提供管理界面，支持手动触发补偿、修改数据状态。
测试验证：
- 模拟熔断期间产生数据差异，验证补偿机制是否能自动修复。
- 验证对账任务能发现差异并生成差异报告。
- 验证人工介入流程的完整性和可追溯性。
怎么选择合适的超时时间？
选择原则：
- 参考第三方 SLA 和历史响应数据，一般设置为 P99 响应时间的 2-3 倍。
- 区分连接超时（建立连接的时间）和读取超时（等待响应的时间）。
- 考虑业务场景：核心业务超时时间可以稍长，非核心业务快速失败。
测试验证：
- 压测验证超时时间设置是否合理，太短导致误判，太长导致资源占用。
- 监控线上超时率，持续优化超时配置。
第三方服务挂了有没有备用方案？
备用方案：
- 多供应商：接入多个第三方服务，如多个短信供应商、多个支付渠道。
- 自动切换：主服务不可用时自动切换到备用服务。
- 降级处理：没有备用服务时，降级到默认行为或提示用户稍后重试。
测试验证：
- 模拟主服务不可用，验证自动切换逻辑和切换时效。
- 验证备用服务的功能和性能是否符合要求。
- 验证切换过程中的用户体验和数据一致性。