流量风暴导致接口超时

典型现象/特征

1. 前端报 /xxx/xxx 接口超时，并带有 TraceId
2. 前端报 Server_504

排查确认步骤

第一步，初步判断：

1. 1.可先做初步分类判断:如果是单服务、单接口偶发或持续报错，而其他接口和功能都正常，则更像单功能问题；
2. 2.如果是单服务所有接口偶发报错，则更像单个 pod 状态异常；
3. 3.如果是单服务所有接口持续报错，则可能是该服务全部 pod 或所在物理节点异常 硬件资源异常；
4. 4.如果是所有服务所有接口偶发报错，则优先怀疑 NG、网关或网络问题 网络导致的请求504；
5. 5.如果是所有服务所有接口持续报错，则需要优先考虑集群级问题。

第二步，确认：

1. 6.单功能问题可根据报错中的 TraceId 检查对应 NG 或 ctp_webapi_getway 网关日志，确认 request_time 是否显著偏高；
2. 7.单 pod 问题可确认相关服务多个 pod 中是否存在单个状态异常的实例；
3. 8.节点问题则需检查该节点 CPU、内存、磁盘是否正常，并从该节点发起到网关节点、数据库节点的连通性测试，确认是否存在丢包或高延迟。
4. 9.网络问题可通过 TraceId 核对 NG 日志是否存在对应请求，如果完全查不到日志，通常可支持网络问题判断。 网络导致的请求504
5. 10.集群问题则需要综合检查 K8S 面板中大量 pod 状态、集群节点资源、数据库状态，以及 Redis、消息队列、Nacos 等关键中间件是否异常。 核心中间件服务异常

分析工具

1. 一键采集工具
2. 一键巡检工具
3. 系统监控查看说明
4. 系统日志查看指引

常见应急恢复策略

问题确认后再执行对应处置措施。

1. 单功能问题通常按正常客户问题单流程处理；
2. 单 pod 问题可在 Nacos 中下线异常 pod，临时扩容同类服务 pod，并保留异常 pod 的 GC 日志、业务日志、数据库慢 SQL 日志和 K8S 事件日志，必要时手动生成 dump。
3. 节点问题需要第一时间通知客户，保留节点近期命令历史，并尽量将业务 pod 临时扩容到其他节点，同时下线问题节点上的相关 pod。
4. 网络问题应明确告知客户，联系客户运维处理。
5. 对于集群问题，如果是磁盘空间不足，可优先清理磁盘；
6. 如果是数据库状态异常，可考虑重启数据库；
7. 其他复杂场景应第一时间联系总部运维和相应架构师协同处理。