依赖外部服务 External dependencies (auth, billing, platform)

原因 ID in-external · 主责 外部·外部 · 配合研发团队·服务器开发

平台登录、支付、实名认证这类外部服务变慢或停摆时，流程会卡在那一步。

起因外部认证、支付服务故障或延迟 → 结果在该步骤等待响应 → 画面表现 无法登录，支付失败。已经在游戏中的人不受影响

症状: 连不上/无限加载, 吞操作/回档
因素: 停顿
谁会遇到: 全服, 仅特定功能
何时出现: 刚登录/维护结束后, 做特定操作时
负责方: 主责 外部·外部 · 配合研发团队·服务器开发
研发团队要做的事: 外部调用设超时并给出友好提示，缓存认证结果，支付重试与补偿流程。
外部要做的事: 向认证、支付、平台服务商确认故障并请求恢复，告知玩家是外部服务故障。
监控图上: 某一时刻起台阶式上升 · 外部调用响应时间、错误率，登录成功数
查看位置: 平台登录、支付、实名认证等各外部调用的响应时间、错误率、超时次数，以及服务商的状态页
确认依据: 从登录、支付失败集中出现的时刻起，只有某个外部调用的错误、超时上了一个台阶并停在那里，服务商状态页上同一时刻有故障
排除依据: 外部调用正常却登录不了，看登录服务器本身（线程池耗尽、DB）或操作系统的连接队列（backlog）
确认手段: 需要游戏服务器/客户端的日志和指标
真实案例: Fastly 2021: Fastly CDN 全球大面积报错
 AWS 2021: AWS us-east-1 内部网络拥塞
 AWS 2025: AWS us-east-1 DynamoDB DNS 故障与漫长的恢复

出处

Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library。等待响应期间会占用线程、连接等资源，所以要设超时；有副作用的 API 只在保证幂等时才重试
Circuit Breaker Pattern Microsoft Azure
很可能失败的调用不等到超时，直接拒绝，以保住响应时间
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected。依赖的服务故障时，即使用稍旧的数据也要保住核心功能（缓存认证结果的依据）