优雅停机时，应用内资源的关闭顺序，该不该有一套强制约定？

背景 社区里 K8s 侧的「优雅停机」已经讲得很透了——preStop、terminationGracePeriodSeconds、摘流量时序、in-flight 排空，好几篇都在讲「编排层怎么给窗口」。但我最近在一个组里发现，真正翻车的往往不是 K8s 那几秒窗口，而是进程收到 SIGTERM 之后、应用内部把资源一个个关掉的那个顺序——这块几乎没人写进规范，全靠人记。

我 3 年里被「关闭顺序」坑过三次，都是同一类：窗口给了、流量也摘了，但进程内部把资源关反了，于是「优雅停机」变成「优雅地把 in-flight 请求/任务/消息干掉」。比如：

• 连接池（HikariCP）在 in-flight 请求还没跑完时就 close()，剩下的请求拿不到连接直接抛，监控上一道 5xx 尖峰，长得跟「没做优雅停机」一模一样；
• 异步线程池被 shutdownNow()，队列里没跑完的任务被丢，而且那个返回的 List 根本没人接，任务静默丢失——没有任何日志能证明它存在过；
• Kafka consumer 在分区 offset 还没 commit 前就 close，触发一次整组 rebalance，别的实例跟着抖。

三种常见做法（也是三种立场）

1. 靠「文档约定 + 人肉遵守」：写一份「停机顺序清单」贴 wiki，靠每个人记。灵活，但漏记/改代码时顺序被改乱是常态，我见过的坑里有两次是「重构 shutdown hook 时把顺序悄悄改了」。
2. 靠「框架强制」：用 Spring 的 SmartLifecycle phase、或自定义 shutdown hook 链，让框架按 phase 排好顺序，业务无感。可维护，但黑盒——一旦升级版本 phase 语义变了、或自定义 phase 和框架内置的撞了，顺序就悄悄变了，review 时几乎看不出来。
3. 靠「显式编排」：应用里放一个 ShutdownCoordinator，把每个资源的 stop 动作、超时、是否可重入，显式声明成一条链，按声明顺序执行。可控、可审计，但每个资源都要接一次。

我的倾向与理由 我站 3（显式编排 + 可重入前置），并且把「顺序」和「每步超时」绑死，理由：

• 顺序错了的症状（5xx 尖峰、任务静默丢失、rebalance 抖动）和「没做优雅停机」长得一模一样，事后定位成本极高；把顺序做成一处声明、可审计的链，比靠文档和靠框架黑盒都稳。
• 「可重入/幂等」要前置：每个 stop 动作必须能被安全地重复执行（SIGTERM 后超时被 SIGKILL 前，可能已经跑了一半），否则窗口再长也救不回来。这和「幂等是重试的前提」一个道理——安全侧的默认值，比「指望大家别配错」成本低得多。
• 每步要有独立超时 + 总窗口预算：摘流量 → 等 in-flight（含异步 drain）→ 关 consumer（提交 offset）→ 关线程池（drain）→ 关连接池 → 关 DB，每一步超时加起来必须 < terminationGracePeriodSeconds，否则最后还是被 SIGKILL 兜底。

想听大家

• 你们团队优雅停机时，应用内资源的关闭顺序是靠文档、靠框架 phase，还是显式编排？
• 有没有踩过「顺序关反 → 任务/消息/连接静默丢失」的坑？事故长什么样，最后怎么定位到的？
• 你们怎么保证「每步超时之和 < K8s 总窗口」？有没有把它做成 CI 里的校验项？
• 异步任务 drain 你们用 shutdown() + awaitTermination，还是直接 shutdownNow()？队列里没跑完的任务要不要落盘兜底？

欢迎贴你们的具体配置、shutdown hook 链或踩坑记录，我这边可以补一份「显式编排 + 可重入前置 + 超时预算」的落地清单。