103 lines
6.1 KiB
Markdown
103 lines
6.1 KiB
Markdown
---
|
||
tags: []
|
||
date created: 星期五, 十一月 21日 2025, 2:27:11 下午
|
||
date modified: 星期五, 十一月 21日 2025, 2:52:14 下午
|
||
---
|
||
|
||
# 2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)
|
||
|
||
遵循三阶段模型，我们深入探讨 **2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)**。
|
||
|
||
这是控制平面的核心业务流程。如果说事件总线是“电话线”，那么本节我们要规定的是“通话规矩”：调度器（指挥官）如何下达开机命令，模块（士兵）如何反馈执行结果，以及如何确保全员步调一致。
|
||
|
||
## 一、 约束输入与对齐 (Constraints & Alignment)
|
||
|
||
基于 `05_任务调度器设计.md` 和前序基线，我们面临以下硬性约束：
|
||
|
||
1. **决策权集中**：`TaskScheduler` 是唯一的生命周期决策者。模块严禁擅自启动或停止，必须响应调度器的指令。
|
||
2. **异步闭环**：由于模块的初始化（如 GPU 上下文创建、网络绑定）可能耗时较长（> 10ms），**严禁**在事件回调中阻塞执行。协议必须是 **“异步指令 -> 后台执行 -> 异步回执”** 的闭环模式。
|
||
3. **依赖有序**：启动必须遵循 `DependencyGraph` 的拓扑正序，停止遵循逆序。
|
||
4. **可观测性**：所有生命周期事件必须携带 `TraceID`，以便追踪“是谁触发了这次启动”。
|
||
|
||
---
|
||
|
||
## 二、 权衡分析与选项呈现 (Trade-off Matrix)
|
||
|
||
### 议题 1：指令交互模式 (Command Interaction Model)
|
||
|
||
|**选项**|**A. 同步调用 (Direct Method Call)**|**B. 异步事件 + 超时机制 (Async Event + Timeout) (推荐)**|
|
||
|---|---|---|
|
||
|**机制**|调度器直接调用 `module->start()`。|调度器发布 `StartModuleEvent`，启动定时器，等待 `ModuleRunningEvent`。|
|
||
|**阻塞性**|**高**。如果模块 `start()` 卡死，调度器也会卡死，导致整个控制面瘫痪。|**无**。调度器发完指令就去处理别的（如响应心跳），不会被卡住。|
|
||
|**超时处理**|困难。需要多线程强杀。|**简单**。定时器触发后，如果没收到回执，直接判定启动失败并回滚。|
|
||
|**适用场景**|简单的函数库调用。|**分布式/微服务架构的标准解**（即使是进程内）。|
|
||
|
||
### 议题 2：状态同步与一致性 (State Consistency)
|
||
|
||
|**选项**|**A. 乐观信任 (Trust Event)**|**B. 双重确认 (Event + Query) (推荐)**|
|
||
|---|---|---|
|
||
|**机制**|调度器只根据收到的 `ModuleRunningEvent` 更新内部状态表。|调度器收到 Event 更新状态，**同时**定期（如每 1 秒）调用 `module->getState()` 核对。|
|
||
|**风险**|**状态漂移**。如果 Event 丢失（极少见但可能），调度器会以为模块还在运行，实际上它可能已崩溃。|**健壮**。能自动修复“幽灵状态”，确保监控视图的真实性。|
|
||
|**开销**|零。|低（原子变量读取）。|
|
||
|
||
---
|
||
|
||
## 三、 基线确立与实施规范
|
||
|
||
为了确保系统在无人值守环境下的绝对可靠性，我们确立 **B. 异步事件 + 超时机制** 和 **B. 双重确认** 为基线。
|
||
|
||
### 1. 核心事件定义基线
|
||
|
||
所有事件必须继承自 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; }`
|
||
|
||
### 2. 握手协议时序基线 (Sequence Flow)
|
||
|
||
这是“启动一个模块”的标准操作流程（SOP）：
|
||
|
||
1. **指令下发**：调度器发布 `StartModuleEvent(Target="SignalProcessor")`，并将模块状态标记为 `STARTING`。同时，**启动一个 5 秒（可配置）的看门狗定时器**。
|
||
2. **异步执行**：`SignalProcessor` 收到事件，**不应在回调中直接干活**，而是将“启动任务”提交给自己的工作线程（或 `std::thread`），立即返回。这保证了调度器线程不被阻塞。
|
||
3. **任务执行**：`SignalProcessor` 的工作线程执行 `cudaFree(0)`、分配内存池等耗时操作。
|
||
4. **回执上报**：
|
||
|
||
- **成功**：发布 `ModuleRunningEvent`。
|
||
- **失败**：发布 `ModuleFailedEvent`。
|
||
|
||
5. **闭环确认**：
|
||
|
||
- **正常**：调度器收到 `ModuleRunningEvent`，取消定时器，将状态标记为 `RUNNING`，并触发下一个依赖模块的启动。
|
||
- **超时**：定时器先触发。调度器判定启动失败，发布 `StopModuleEvent(force=true)` 进行清理，并进入故障恢复流程。
|
||
|
||
### 3. 状态机一致性基线
|
||
|
||
- **双重账本**：
|
||
- **账本 A (调度器侧)**：`ModuleRegistry` 中的状态表，用于决策。
|
||
- **账本 B (模块侧)**：模块内部的 `std::atomic<State>`，用于执行。
|
||
- **同步规则**：
|
||
- **写操作**：必须通过“指令 - 回执”流程修改。
|
||
- **读操作**：调度器每秒执行一次 `SystemHealthCheck`，对比 账本 A 和 账本 B。如果发现不一致（如调度器认为 `RUNNING` 但模块是 `STOPPED`），触发 `StateMismatchEvent` 告警，并以**模块侧（真实世界）** 为准进行状态修正（Self-Healing）。
|
||
|
||
---
|
||
|
||
## 总结与下一步行动
|
||
|
||
我们确立了 **2.3.3 生命周期编排与状态同步协议** 的基线：
|
||
|
||
1. **协议**：**全异步 + 超时看门狗**。
|
||
2. **一致性**：**事件驱动更新 + 定期主动核对**。
|
||
3. **依赖**：严格遵循 DAG 拓扑序。
|
||
|
||
下一步建议：
|
||
|
||
模块启动之后，难免会遇到运行时错误。这就涉及到 2.3.4 故障传播与恢复信令 (Fault Propagation & Recovery Signaling)。我们需要定义：当一个模块“挂了”的时候，它怎么“优雅地”告诉调度器？调度器又如何指挥其他模块进行“无感恢复”？
|
||
|
||
**提问**：您是否确认 **“异步指令 + 超时闭环”** 的生命周期协议基线？确认后我们将深入 2.3.4。
|