2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)

遵循三阶段模型，我们深入探讨 2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)。

这是控制平面的核心业务流程。如果说事件总线是“电话线”，那么本节我们要规定的是“通话规矩”：调度器（指挥官）如何下达开机命令，模块（士兵）如何反馈执行结果，以及如何确保全员步调一致。

一、约束输入与对齐 (Constraints & Alignment)

基于 05_任务调度器设计.md 和前序基线，我们面临以下硬性约束：

决策权集中：TaskScheduler 是唯一的生命周期决策者。模块严禁擅自启动或停止，必须响应调度器的指令。
异步闭环：由于模块的初始化（如 GPU 上下文创建、网络绑定）可能耗时较长（> 10ms），严禁在事件回调中阻塞执行。协议必须是 “异步指令 -> 后台执行 -> 异步回执” 的闭环模式。
依赖有序：启动必须遵循 DependencyGraph 的拓扑正序，停止遵循逆序。
可观测性：所有生命周期事件必须携带 TraceID，以便追踪“是谁触发了这次启动”。

选项	A. 同步调用 (Direct Method Call)	B. 异步事件 + 超时机制 (Async Event + Timeout) (推荐)
机制	调度器直接调用 `module->start()`。	调度器发布 `StartModuleEvent`，启动定时器，等待 `ModuleRunningEvent`。
阻塞性	高。如果模块 `start()` 卡死，调度器也会卡死，导致整个控制面瘫痪。	无。调度器发完指令就去处理别的（如响应心跳），不会被卡住。
超时处理	困难。需要多线程强杀。	简单。定时器触发后，如果没收到回执，直接判定启动失败并回滚。
适用场景	简单的函数库调用。	分布式/微服务架构的标准解（即使是进程内）。

选项	A. 乐观信任 (Trust Event)	B. 双重确认 (Event + Query) (推荐)
机制	调度器只根据收到的 `ModuleRunningEvent` 更新内部状态表。	调度器收到 Event 更新状态，同时定期（如每 1 秒）调用 `module->getState()` 核对。
风险	状态漂移。如果 Event 丢失（极少见但可能），调度器会以为模块还在运行，实际上它可能已崩溃。	健壮。能自动修复“幽灵状态”，确保监控视图的真实性。
开销	零。	低（原子变量读取）。

为了确保系统在无人值守环境下的绝对可靠性，我们确立 B. 异步事件 + 超时机制 和 B. 双重确认 为基线。

所有事件必须继承自 2.3.2 确立的 BaseEvent 以携带 TraceID。

指令事件 (Commands) - 由调度器发布，模块订阅：
- StartModuleEvent { string module_name; Config config_patch; }
- StopModuleEvent { string module_name; bool force; }
- PauseModuleEvent { string module_name; }
回执事件 (Feedbacks) - 由模块发布，调度器订阅：
- ModuleRunningEvent { string module_name; }
- ModuleStoppedEvent { string module_name; }
- ModuleFailedEvent { string module_name; ErrorCode code; }

这是“启动一个模块”的标准操作流程（SOP）：

指令下发：调度器发布 StartModuleEvent(Target="SignalProcessor")，并将模块状态标记为 STARTING。同时，启动一个 5 秒（可配置）的看门狗定时器。
异步执行：SignalProcessor 收到事件，不应在回调中直接干活，而是将“启动任务”提交给自己的工作线程（或 std::thread），立即返回。这保证了调度器线程不被阻塞。
任务执行：SignalProcessor 的工作线程执行 cudaFree(0)、分配内存池等耗时操作。
回执上报：
- 成功：发布 ModuleRunningEvent。
- 失败：发布 ModuleFailedEvent。
闭环确认：
- 正常：调度器收到 ModuleRunningEvent，取消定时器，将状态标记为 RUNNING，并触发下一个依赖模块的启动。
- 超时：定时器先触发。调度器判定启动失败，发布 StopModuleEvent(force=true) 进行清理，并进入故障恢复流程。

双重账本：
- 账本 A (调度器侧)：ModuleRegistry 中的状态表，用于决策。
- 账本 B (模块侧)：模块内部的 std::atomic<State>，用于执行。
同步规则：
- 写操作：必须通过“指令 - 回执”流程修改。
- 读操作：调度器每秒执行一次 SystemHealthCheck，对比账本 A 和账本 B。如果发现不一致（如调度器认为 RUNNING 但模块是 STOPPED），触发 StateMismatchEvent 告警，并以模块侧（真实世界） 为准进行状态修正（Self-Healing）。

我们确立了 2.3.3 生命周期编排与状态同步协议 的基线：

下一步建议：

模块启动之后，难免会遇到运行时错误。这就涉及到 2.3.4 故障传播与恢复信令 (Fault Propagation & Recovery Signaling)。我们需要定义：当一个模块“挂了”的时候，它怎么“优雅地”告诉调度器？调度器又如何指挥其他模块进行“无感恢复”？

提问：您是否确认 “异步指令 + 超时闭环” 的生命周期协议基线？确认后我们将深入 2.3.4。