容器化之后，"重启即恢复"这个假设在实时场景下还成立吗？

背景

我做了 15 年嵌入式，早期写 MCU 固件时，"崩溃"是一个必须严肃对待的事件：看门狗喂狗、状态机复位、外设寄存器回写、DMA 通道重初始化——"恢复"从来不等于"重新启动"，而是要回到一个可证明一致的状态。

后来转做容器化和 K8s 运维，发现社区对"恢复"的心智模型简化到了极致：进程挂了 → kubelet 检测到 → 拉个新容器 → 完事了。liveness probe 失败就 restart，crash loop backoff 兜底，preStop hook 里 flush 一下 buffer。表面上看，"重启即恢复"成立；但仔细看这个链条，里面藏了好几个默认假设，在嵌入式或准实时场景下未必成立。

几种常见做法与分歧

1. "K8s 重启就够了"派：无状态服务，进程内存里没有需要持久化的状态，重启就是恢复。liveness + restartPolicy=Always，最多加个 preStop 优雅关闭连接。这个派别在 API Gateway、Web 后端里确实工作良好。

2. "需要确定性恢复"派：进程内存里有本地状态——内存数据库（如 embedded Redis、Roaring Bitmap）、未 ack 的消息队列 offset、连接池里的长连接、正在进行的批量写入。这种场景下，"重启"之后进程是全新的，但外部世界不是：下游还等着你之前那笔事务的回应，缓存里还存着你 30 秒前写的脏数据。重启 ≠ 恢复，因为"恢复"需要回到一个一致状态，这不只是进程层面的事。

3. "干脆别让它 crash"派：在进程内部做 watchdog、健康自检、熔断降级，目标是永远不触发 K8s 层面的重启。这其实是嵌入式思维的直接迁移——在 MCU 上你不可能"重启整个板子"来解决问题，你必须在系统内部把异常消化掉。

我的倾向与理由

我的判断是：取决于负载是否持有"外部可见的本地状态"。

• 无状态、幂等、可重试的服务：K8s 的 restart 机制确实够用，"重启即恢复"成立。
• 有本地状态或外部副作用的服务：必须把"恢复"当作一个有界事务来设计——定义清楚哪些状态需要 checkpoint、哪些副作用可以幂等重放、哪些必须回滚。这时候 K8s 的 restart 只是"最后一道兜底"，真正的恢复逻辑在应用层。
• 准实时 / 控制类负载（比如我以前的电机控制、传感器采集）：30 秒的 terminationGracePeriodSeconds 可能已经意味着丢了一个控制周期。这种场景下，"重启"本身就是不可接受的，必须用进程内恢复（热备、状态迁移）来替代。

但我不想把这个话题变成"嵌入式比云原生高级"的拉踩。我想听的是：大家在什么具体场景下发现"重启即恢复"不够用了？你们最终的做法是什么？ 是写了 checkpoint 机制，是引入了外部状态存储，还是干脆换了架构？

尤其是那些"介于无状态和有状态之间"的灰色地带——比如内存里缓存了热点数据、本地文件做了写缓冲、连接池里维护着长连接——这些场景下，K8s 原生的 restart 语义和你们实际需要的"恢复"语义之间，差距到底有多大？