类型：报告 · 建档：2026-08-04 ｜ 时效性文档，引用前请核对正文的数据截止日

汇报 - SIP-MAC 优雅停机专项（STAR）

微服务单体仓部署期网关调用超时的根因分析与整改汇报，基于全量真实配置扫描，采用 STAR 模型组织。

关键指标

指标	数值	状态
可部署服务	23	—
已配 server.shutdown: graceful	16	✅
未配 graceful（红线）	9	❌
Dubbo 提供方优雅停机	0	❌

根因链（openapi 部署期超时）

旧 Pod 被 SIGTERM 终止
  → Web 优雅停机仅停 HTTP，Dubbo 8119 端口未主动 unexport
    → Nacos 注销滞后（心跳 TTL 残留）
      → 旧 172.21.48.109:8119 仍挂网关 Dubbo 目录
        → 网关向死 IP 建连 → connection timed out
          → 网关 retries:2 重试放大，单笔卡至 9s

STAR 模型

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

1. 全量扫描：解析 25 模块嵌套 YAML，输出《优雅停机整改核对表》——✅16 / ❌9，标注红线服务（gateway、data、aw、dcenter、davinci、xxl-job、mysql-insert-demo、sip-mac-activity）。
2. 根因定位：基于真实配置锁定 openapi 超时链（见上方根因链）。
3. 三层整改：
   • 应用侧：补 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 清单，已标注待跟进。

---

交互式汇报卡片

下方为原始 STAR 汇报 HTML，可查看完整视觉效果。