第 5 篇：节点重启自愈——两阶段模块恢复机制

边缘节点的宿命就是随时断电。重启后如果 50 个模块要人工逐个启动，那边缘计算就是伪命题。本文设计一套"先打扫战场、再从权威数据源重建"的两阶段恢复机制，让节点重启后全自动回到正确状态。

一、开篇场景：凌晨三点的工厂

凌晨 3 点，工厂的电力维护人员拉错了电闸。整个车间断电 5 分钟，包括你的边缘网关。5 分钟后电力恢复，网关自动重启。

你被手机告警吵醒——“所有设备离线”。

你怎么做？

• 方案 A：穿衣服开车去工厂，SSH 进去查看哪些模块挂了，逐个重启。到工厂已经 4 点了。
• 方案 B：你的 NodeCore 在启动时自动完成了模块恢复，30 秒后所有模块正常运行。你翻个身继续睡。

方案 B 就是本文要做的事。但设计一套可靠的启动恢复机制，远没有"重启时把上次跑的模块再启动一遍"这么简单。

真正的挑战：

• 上次断电时，Docker 可能留下了状态异常的残畲容器，直接启动会失败
• 进程模块的 PID 已经无效了，需要重建
• 某些模块需要优先启动（比如 DeployMaster 必须先于业务模块）
• 如果有模块正在升级过程中断电，重启后是恢复旧版本还是新版本？

二、概念铺垫：恢复的本质是"声明式"

2.1 命令式 vs 声明式

命令式：systemctl restart moduleA——告诉系统"把这个模块重启"，依赖的是操作序列。断电后操作序列丢了，系统不知道上次执行到哪一步。

声明式：我希望模块 A 是 Running 状态——告诉系统"最终状态是什么"，不关心中间怎么达到。系统自己去找从当前状态到目标状态的路径。

2.2 恢复的数据源：SQLite

NodeCore 在运行期间，把所有模块的定义信息持久化在本地 SQLite 数据库里。这张表的每行记录描述了一个模块"应该长什么样子"：

关键设计：这张表不是"运行时状态的快照"，而是模块的完整定义。即使节点坏了、换个新硬盘，只要把这张表的数据恢复，模块就能重建。

本文涉及的 Go 包："sort""syscall""time""fmt""encoding/json"
"github.com/docker/docker/client""github.com/docker/docker/api/types"

三、方案设计：两阶段恢复

3.1 阶段一：Clean（清理残留）

先别急着恢复——上次断电留下的状态大概率是脏的。Docker 可能残留容器、进程可能残留僵尸、网络配置可能不完整。

Clean 阶段做什么： ├── 1. 通过 Docker API 列出所有容器 │ └── 逐个删除（Force=true，不优雅停止） ├── 2. 通过 /proc 遍历所有子进程 │ └── 杀掉属工作目录在 NodeCore 管辖范围内的进程 ├── 3. 清理 cgroup 残留配置 ├── 4. 检查 Docker bridge 网络是否存在 │ └── 网络被删就重建 └── 5. 清理临时文件、锁文件

为什么用 Force=true 删除容器？因为残留容器状态不确定（可能卡在 restarting），优雅停止要等它响应——它根本不会响应。Force 删除跳过优雅期，直接拿掉。

3.2 阶段二：Recover（重建）

清理干净后，从 SQLite 读出模块定义，按正确的顺序重建：

Recover 阶段做什么： ├── 1. 从 SQLite 读取所有模块定义 ├── 2. 按依赖排序——DeployMaster 排到最后 ├── 3. 逐个重建模块： │ ├── 优先使用 update_body（如果有正在进行的升级） │ ├── 其次使用 create_body │ ├── Docker 模块：先删除可能残留的同名容器，再创建 + 启动 │ └── Process 模块：直接创建 + 启动 └── 4. 最后一个启动 DeployMaster

关键设计：update_body 优先于 create_body。如果节点在升级过程中断电，update_body 保存了新版本的定义。重启后应该用新版本恢复，而不是倒退回旧版本。当然，如果这个新版本启动后发现有问题，DeployMaster 的健康检查机制会自动回滚——这个在第 6 篇讲。

3.3 为什么 DeployMaster 要最后启动？

这是一个从血泪中总结的经验。DeployMaster 启动后会做三件事：

1. 从云端拉取最新部署清单
2. 对比上次的清单，生成需要创建/更新/删除的模块列表
3. 通过状态机驱动模块生命周期变更

如果 DeployMaster 先启动，它正在"拉取清单→对比→决策"，而 NodeCore 还在恢复其他模块——两边同时在操作模块，导致状态冲突。所以 NodeCore 先静默恢复所有模块（不动用部署清单，只用 SQLite），最后再启动 DeployMaster 让它接管控制权。

四、Go 核心骨架

// ========== NodeCore 启动入口 ==========func(nc*NodeCore)Start()error{// ===== 阶段一：Clean =====iferr:=nc.cleanupAll();err!=nil{returnfmt.Errorf("清理阶段失败: %w",err)}// ===== 阶段二：Recover =====iferr:=nc.recoverModules();err!=nil{returnfmt.Errorf("恢复阶段失败: %w",err)}// 启动模块健康监控（第 6 篇细讲）gonc.monitorModules()returnnil}// ========== 阶段一：Clean ==========func(nc*NodeCore)cleanupAll()error{// 1. 清理所有 Docker 容器containers,_:=nc.dockerClient.ContainerList(ctx,types.ContainerListOptions{All:true})for_,c:=rangecontainers{// Force 删除，不容有丝毫犹豫nc.dockerClient.ContainerRemove(ctx,c.ID,types.ContainerRemoveOptions{Force:true})}// 2. 清理残留进程：拿到 NodeCore 下所有子进程// 用 gopsutil 或直接读 /proc，根据 CWD（工作目录）判断是否归 NodeCore 管辖childProcs:=nc.findChildProcesses(nc.runtimeHome)for_,proc:=rangechildProcs{// 杀整个进程组，防止残留子进程syscall.Kill(-proc.PGID,syscall.SIGKILL)}// 3. 清理 cgroupnc.cgroupMgr.CleanupStaleCgroups()// 4. 确保 Docker bridge 网络存在if!nc.networkMgr.NetworkExists("iot-edge-bridge"){nc.networkMgr.CreateNetwork("iot-edge-bridge","169.254.254.0/24")}returnnil}// ========== 阶段二：Recover ==========func(nc*NodeCore)recoverModules()error{// 从加密 SQLite 读出所有模块定义modules,err:=nc.db.FindAllModules()iferr!=nil{returnerr}// 关键排序：非 DeployMaster 的排前面，DeployMaster 排最后sort.Slice(modules,func(i,jint)bool{iIsMaster:=modules[i].ModuleID=="deploy-master"jIsMaster:=modules[j].ModuleID=="deploy-master"// 把 DeployMaster 排到最后ifiIsMaster!=jIsMaster{returnjIsMaster// 当 j 是 master 时返回 true，让它排后面}returnmodules[i].LastStartTime<modules[j].LastStartTime})for_,mod:=rangemodules{// 选择用哪个 body：有 updateBody 说明正在升级，优先用它bodyJSON:=mod.CreateBodyifmod.UpdateBody!=""{bodyJSON=mod.UpdateBody}varreq ModuleDeployRequest json.Unmarshal([]byte(bodyJSON),&req)// 先拉取镜像/包（如果有新版本的话）nc.packageMgr.PullPackage(&req)ifmod.Type=="docker"{// Docker：先删再建，防止残留容器名冲突nc.proxy.RemoveModule(mod.ModuleID,"docker")nc.proxy.CreateModule(&req,"docker")}else{// Process：直接创建nc.proxy.CreateModule(&req,"process")}// 启动nc.proxy.StartModule(mod.ModuleID,mod.Type)// 更新启动时间戳nc.db.UpdateLastStartTime(mod.ModuleID,time.Now().UnixMilli())}returnnil}

五、边界与反模式

反模式一：用 Clean 不干净、Recover 也不全

错误做法：只删除容器，不清残留进程。

为什么错：进程模块的 PID 已经变了，但残留进程还在占用端口。新进程启动时端口被占用，启动失败。更隐蔽的是残留 cgroup 配置，新的 cgroup 没法创建，资源隔离失效。

反模式二：恢复时直接复用上次的容器

错误做法：Docker 重启后容器还在（因为容器设置了--restart=always），直接复用上次的容器，改改状态就行。

为什么错：Docker 重启后，容器的网络命名空间可能变了，IP 地址变了，挂载的卷可能状态异常。更致命的是——你怎么知道这个容器在断电瞬间是不是正在写入关键数据？文件系统可能损坏。

正确做法：直接删掉重建。重建的成本（拉镜像、创建容器）跟排查"残留容器为什么不工作"的成本比，不值一提。

反模式三：恢复时不检查 updateBody

错误做法：恢复时只看 createBody，忽略 updateBody。

为什么错：如果节点在升级过程中断电，下次启动应该用新版本。如果你用 createBody（旧版本）恢复，这个节点就永远卡在了旧版本上。云端以为节点已经升级成功，不再下发升级指令，节点也就永远失去了升级机会。

正确做法：body = updateBody != "" ? updateBody : createBody，确保升级不会因为断电而丢失。

反模式四：所有模块平等启动，不排依赖

错误做法：从数据库读出来的模块顺序随机，直接按数据库返回的顺序创建启动。

为什么错：DeployMaster 可能在 MessageHub 还没起来时就启动了。DeployMaster 启动后尝试 MQTT 连接云端，但 MessageHub 还没起来——连接失败。DeployMaster 可能认为"网络不通"而进入离线模式，但实际上只是 MessageHub 慢了 2 秒。

正确做法：明确依赖拓扑，底层服务先启动，控制面最后启动。

补充：恢复的性能考虑

如果节点上有 50 个 Docker 模块，每个镜像是 200MB，全部重新拉取需要多长时间？

答案是——一般不需要重新拉取。Docker 的镜像分层存储在宿主机上，断电不会丢失。ContainerCreate只是基于本地已有的镜像创建一个新容器实例，耗时通常是毫秒级。只有 updateBody 引用了新版本镜像才需要重新拉取。

六、小结

节点恢复不是"把模块启动一下"——它是一套严谨的工程流程：

清理（干净的起点）→ 重建（权威的数据源）→ 排序（正确的依赖）→ 升级感知（updateBody 优先）

两阶段恢复的设计思想可以提炼为一句话：先确保世界上没有你认识的东西，再从你唯一相信的地方开始重建。

下一篇，我们探讨一个更刺激的话题：一个运行中的模块，怎么安全地升级到新版本，失败了怎么自动滚回去——“空中换引擎”。

本文是《边缘平台架构沉思录：Go 架构推演与工程决策》系列的第 5 篇。