缺陷分析与未来发展路线图

概述

本章坦诚地分析当前系统存在的 4 个 Critical 级缺陷，并为每个缺陷提出分阶段的改进方案。这些缺陷不影响系统作为原型验证平台的价值，但在向生产级系统演进时必须逐一解决。

Critical 缺陷分析

C-1: 时间同步空壳

现象：系统预留了 barrier.py 和 clock.py 两个同步模块，但均未被 runner.py 的主循环调用。

代码证据：

• orchestrator/barrier.py:7-12：BarrierState 仅定义了 step_id 和 dt_seconds 两个字段以及 next_step() 方法，无任何同步逻辑
• orchestrator/clock.py:6-7：now_ms() 基于 time.time() 返回墙钟毫秒值，但未被任何模块 import
• metrics/compute.py:64：sync_error_ms 硬编码为 0.0，不反映任何真实度量

根本原因：当前为单机单进程架构，所有时间戳由 runner.py:537-540 中的 perf_counter_ns 统一生成，不存在需要同步的多个时钟源。barrier 和 clock 模块是为未来分布式扩展预留的接口骨架。

影响范围：

• 实验数据中的 sync_error_ms 列始终为 0，无法作为论文中同步性能分析的依据
• 无法模拟真实水声网络中各节点时钟独立漂移的场景
• 步推进纯靠 time.sleep() 的 wall-clock 等待，不保证所有 RX 事件已收集完毕

C-2: 资源分配过简

现象：两种调度策略（RoundRobin、AdaptiveQoS）的 quota_frames 均硬编码为 1。

代码证据：

• scheduler/round_robin.py:23：quota = {node_id: 1 for node_id in active}
• scheduler/adaptive_qos.py:29：quota = {node_id: 1 for node_id in active}
• runner.py:649-650：StepContext 的 queues 和 link_hints 始终传入 {}

根本原因：

• 水声信道的低带宽（通常 <10 kbps）和长传播延迟使得"每步每节点 1 帧"在多数场景下是合理的保守默认值
• 动态 quota 计算需要可靠的链路容量估计（link_hints），而当前系统不维护此信息
• AdaptiveQoS 的自适应维度仅限于活跃节点数量的扩缩，未涉及配额量化

影响范围：

• 在信道质量良好的时间窗口内，每步仅发送 1 帧浪费了可用带宽
• 无法观察到"配额动态调整对吞吐量的影响"这一重要实验变量
• queues 空字典意味着策略无法感知各节点的发送积压状况

C-3: 信道建模缺失

现象：Mock 模式使用固定参数的伯努利丢包 + 均匀延迟，不包含任何水声信道物理模型。

代码证据：

• runner.py:93-95：loss_rate=0.05、min_delay_ms=50、max_delay_ms=200 均为硬编码默认值
• runner.py:109：received = rng.random() >= loss_rate——各帧独立同分布，不模拟突发丢包
• runner.py:110：delay_ms = rng.randint(min_delay_ms, max_delay_ms)——均匀分布，不反映多径功率时延谱

根本原因：

• 系统的定位是"数字孪生调度平台"而非"信道仿真器"，信道行为由外部 UNetStack 提供
• Mock 模式的设计目的是在无 UNetStack 环境下快速验证调度逻辑和数据管线，不追求信道真实性
• 集成真实声学模型（如 Bellhop）需要大量海洋环境参数，超出了当前原型阶段的范围

影响范围：

• Mock 模式下的实验结果不具备水声信道特性的代表性
• 无法研究多径效应、多普勒频移等物理因素对调度策略性能的影响
• Mock 与 gateway 模式的实验结果不可直接对比

C-4: 非分布式架构

现象：系统为单机单进程架构，Orchestrator、Scheduler、MetricsCompute 全部在同一进程内运行。

代码证据：

• runner.py:641-791：整个步循环为单线程顺序执行（RX 订阅虽在独立线程，但 TX 和指标计算在主线程）
• service/execution_worker.py：运行任务在 ThreadPoolExecutor 中执行，但仍限于单机
• 无任何进程间通信（IPC）或远程过程调用（RPC）机制

根本原因：

• 原型阶段优先验证端到端数据流通，分布式架构的复杂性会显著增加开发和调试成本
• UNetStack 仿真器通常部署在单机上，通过不同端口模拟多节点，天然适配单进程 Orchestrator
• 系统尚未需要处理真正的大规模节点部署（当前场景通常 2-4 节点）

影响范围：

• 无法扩展到物理分布式部署场景（如多台主机各运行一个仿真节点）
• 单进程的 GIL 限制了 CPU 密集型计算的并行度
• 单点故障——Orchestrator 进程崩溃导致整个运行终止

缺陷严重度与优先级矩阵

缺陷	严重度	修复难度	对论文价值	建议优先级
C-1 时间同步空壳	High	Low	High	P0
C-2 资源分配过简	Medium	Medium	High	P1
C-3 信道建模缺失	Medium	High	Medium	P2
C-4 非分布式架构	Low	Very High	Low	P3

短期改进方案

以下改进可在现有架构上增量实施，不涉及根本性重构。

S-1: 激活 barrier + clock ✅ 已完成

目标：使 sync_error_ms 和 overhead_ms 输出真实度量值。

完成状态：已于 2026-02-28 实现并验证。

实际实现：

1. 新增 MonoClock 类（clock.py）：封装 perf_counter_ns 单调时钟和 time_ns 墙钟，通过 drift_ms() 计算两者漂移作为 sync_error_ms 的代理指标
2. 新增 StepTiming（frozen dataclass）和 StepBarrier（per-step timing 采集器），在每步的 begin_step()/end_step() 之间测量 overhead_ms，并校验 expected_tx vs actual_tx
3. compute_window_metrics 新增可选参数 step_timings，向后兼容
4. runner.py 的 gateway 模式和 mock 模式均已接入 StepBarrier，metrics.csv 输出真实的 overhead_ms 和 sync_error_ms 值

验证：11 项单元测试通过 + mock 模式集成测试确认 overhead_ms > 0

S-2: quota 动态化

目标：根据帧大小和步长计算合理的 quota 上界。

实现路径：

1. 在 StepContext 中增加 frame_size_bytes 字段（来自场景定义）
2. RoundRobin 策略根据 dt_seconds * estimated_bps / (frame_size_bytes * 8) 计算 quota
3. AdaptiveQoS 策略在丢包率低时增加 quota，丢包率高时减少

S-3: Mock 参数可配置化

目标：允许通过场景 YAML 自定义 Mock 信道参数。

实现路径：

1. 在场景 YAML 的 run 节新增 mock_loss_rate、mock_min_delay_ms、mock_max_delay_ms 字段
2. _generate_mock_traces() 从配置读取参数而非使用默认值

中期演进方案

M-1: WebSocket 替代轮询

现状：前端通过定时 REST 轮询获取运行状态和指标。

改进方案：

1. 利用 FastAPI 原生 WebSocket 支持，在 step_callback 中直接推送实时指标
2. 前端建立 WebSocket 连接后，无需轮询即可获得步级别的实时更新
3. 减少 HTTP 请求开销，降低仪表盘的延迟感知

M-2: A/B 对比实验框架

目标：支持在相同场景下对比不同策略的性能。

实现路径：

1. 增加"对比运行"API，接受多个 strategy_id，依次执行并共用相同的随机种子
2. 指标导出增加策略标签，前端支持多运行叠加对比图表
3. 自动生成对比报告，包含各策略在吞吐量/丢包率/延迟维度的排名

M-3: 多维 QoS 策略

目标：替代当前仅基于 loss_rate 的单维度自适应。

设计：

多维效用函数:
U(n, t) = w_throughput * T(n,t)/T_max
         - w_loss * L(n,t)
         - w_delay * D(n,t)/D_max
         + w_fairness * F(n,t)

其中:
  T(n,t) = 节点 n 在步 t 的吞吐量
  L(n,t) = 节点 n 在步 t 的丢包率
  D(n,t) = 节点 n 在步 t 的 P95 延迟
  F(n,t) = Jain's fairness index 在节点 n 的贡献
  w_* = 可配置权重

长期愿景

V-1: 分布式多 Orchestrator 架构

架构设想：

                 +-------------------+
                 |  Coordinator      |
                 | (全局步同步)       |
                 +---+-------+-------+
                     |       |
          +----------+       +----------+
          |                             |
+---------v---------+       +-----------v---------+
| Orchestrator-A    |       | Orchestrator-B      |
| (管理 node 1,2)   |       | (管理 node 3,4)     |
+---------+---------+       +-----------+---------+
          |                             |
    +-----v-----+               +-------v-----+
    | UNetStack  |               | UNetStack   |
    | (节点 1,2)  |               | (节点 3,4)  |
    +------------+               +-------------+

技术要点：

• Coordinator 负责全局步同步（基于 barrier 协议）
• 各 Orchestrator 独立管理本地节点子集
• 引入 gRPC 或 NATS 作为进程间通信机制
• Vector Clock 维护跨 Orchestrator 的事件因果序

V-2: Bellhop 声线追踪模型集成

集成方案：

1. 封装 Bellhop 为 Python 子进程调用，输入声速剖面（SSP）和海底参数
2. 输出 arrival structure（多径到达时间和幅度），转换为延迟分布和丢包概率
3. 场景 YAML 增加 environment 节，定义水深、海底类型、声速剖面
4. Mock 模式升级为"参数化信道模型"，替代简单伯努利模型

V-3: Kubernetes 容器化部署

部署架构：

• FastAPI 后端和前端分别作为独立 Pod
• Orchestrator 实例作为 Job 或 StatefulSet 运行
• UNetStack 仿真器容器化，通过 Service 暴露 Gateway 端口
• MySQL/PostgreSQL 持久化存储迁移到 PersistentVolume
• Prometheus + Grafana 替代自建指标系统

技术路径总结

当前状态                    短期 (S)                中期 (M)              长期 (V)
─────────────────────────────────────────────────────────────────────────────────
sync_error=0     -->  barrier+clock激活 ✅ -->  NTP偏移校准     -->  Vector Clock
quota=1固定      -->  动态quota计算       -->  多维QoS策略     -->  队列感知调度
Mock=5%伯努利    -->  参数可配置          -->  统计信道模型    -->  Bellhop集成
单机单进程       -->  (维持现状)          -->  WebSocket推送   -->  分布式多Orch

每个阶段的改进都是对前一阶段的增量扩展，不需要对现有架构进行破坏性重构。这种渐进式演进策略确保系统在每个阶段都保持可用性和稳定性。