容器化之后，"启动顺序"还该不该由业务代码来兜？聊聊你的取舍

背景

我做了 5 年嵌入式，早期写 MCU 固件时，"启动顺序"是一个必须严格保证的硬约束：时钟先起、外设再上、调度器最后跑，任何一步乱序都是硬故障。近两年主力转容器化和 K8s 运维，最近帮两个 IoT/边缘团队做服务容器化，被问得最多的一句话就是："我在裸机上靠 systemd 的 After=/Wants= 把 A 起完再起 B，容器化之后这个顺序还能怎么保？"

社区里的几种常见做法

1. K8s 编排侧：Deployment 之间用 init 容器 + kubectl wait --for=condition=ready 卡就绪，或者上 OpenKruise Advanced StatefulSet 的 in-place 升级和有序依赖。
2. 业务代码侧：每个服务启动时自己 retry 依赖（连 DB 连不上就 sleep 重试），把"顺序"问题降级成"重试"问题。
3. 本地代理侧：在 Pod 内加一个 sidecar（或 node 级 agent），拦截对依赖端口的调用，依赖没 ready 之前把请求挂起，对业务进程表现为"慢一点但不会连不上"。
4. 干脆放弃顺序：声明所有服务都是无状态 + 幂等，靠重试和最终一致兜底。

我的倾向与理由

嵌入式思维会本能地想"把顺序写死"，但在 K8s 里，启动顺序是一个弱保证——Kubelet 不承诺跨 Pod 的就绪时序，Service/Endpoint 的同步也有秒级延迟。我倾向于：顺序不该由任何单一组件兜底，而是让"乱序"本身无害。具体做法是 2+3 组合：业务代码把对依赖的调用统一走本地代理（拦截 + 挂起），同时保留有限次数的退避重试作为代理不可用时的兜底。这样无论是滚动发布、节点漂移、还是 DNS 抖动，业务进程都不会因为"依赖还没起"而进入一个半死不活的中间态。

代价是：每个 Pod 多一个 sidecar 的资源开销，以及代理本身需要处理超时、熔断、连接池等细节。在 4C8G 的边缘 ARM 节点上，这个开销不是免费的。

想听大家聊聊

• 你们在资源受限的边缘/嵌入式场景下，是怎么处理启动顺序的？是老老实实上 sidecar 代理，还是写死 retry？
• 有没有人踩过"顺序看起来保住了，但依赖的 readiness 还没真正可用"（比如 DB 起来了但还没完成 recovery）的坑？
• 如果让你给一个 5 人团队定一条"启动顺序"的架构规范，你会写哪三条？