S情境 Situation
- SIP-MAC 为 23 个可部署服务的微服务单体仓，运行期强耦合于 Dubbo RPC（58 条调用边）。
- 滚动发布期间，网关（gateway）调用下游服务频繁出现
connection timed out（如 openapi 的 172.21.48.109:8119）。
- 实测基线：25 个含配置文件模块中，仅 16 个配
server.shutdown: graceful，9 个未配；Dubbo 提供方优雅停机全仓未显式配置；K8s 侧缺探针 / PreStop。
T任务 Task
- 定位部署期调用超时的真实根因，而非表面归因。
- 输出可落地的整改核对表与方案，推动乙方补齐。
- 消除发布期故障，收敛单点（如 sip-mac-data 被 21 服务依赖）爆炸半径。
A行动 Action
- ① 全量扫描：解析 25 模块嵌套 YAML，输出《优雅停机整改核对表》——✅16 / ❌9，标注红线服务（gateway、data、aw、dcenter、davinci、xxl-job、mysql-insert-demo、sip-mac-activity）。
- ② 根因定位：基于真实配置锁定 openapi 超时链（见下图）。
- ③ 三层整改：应用侧补
graceful+timeout:60s+Dubbo 优雅停机；部署侧补 preStop / terminationGracePeriod / readinessProbe / replicas≥2；消费侧调小 connect-timeout、非幂等 retries:0、加熔断。
R结果 Result
- 交付 2 份监理素材：①《优雅停机整改核对表》②《openapi 部署期超时排障剧本》。
- 预期成效：补齐后发布期陈旧 Provider IP 路由超时归零，网关日志不再出现死 Pod IP。
- 当前状态：应用侧 / 消费侧可在本仓库落地；部署侧（Deployment/探针）需乙方在 Helm/ArgoCD 补充——本仓库无 openapi 的 Deployment 清单，已标注待跟进。
根因链（openapi 部署期超时）
旧 Pod 被 SIGTERM 终止 → Web 优雅停机仅停 HTTP，Dubbo 8119 端口未主动 unexport → Nacos 注销滞后（心跳 TTL 残留）→ 旧 172.21.48.109:8119 仍挂网关 Dubbo 目录 → 网关向死 IP 建连 → connection timed out → 网关 retries:2 重试放大，单笔卡至 9s。