📚 课程目录第4章平台总体架构设计

4. 平台总体架构设计

标定自动化与批量试验平台要同时面对三类负载：一是高频、短时、强实时的设备交互（CAN/CAN FD、以太网 DoIP、串口、Modbus 等）；二是长周期、重计算的批量任务（参数扫描、工况遍历、模型拟合）；三是面向工程师的交互式查询与报表。若把这三类负载塞进一个无层次的工程里，最先崩掉的往往不是功能，而是可维护性与可追溯性。因此总体架构设计的第一件事，是确定分层边界与依赖方向。

分层架构：把“变化频率”作为切分依据

推荐采用五层结构，自下而上为：设备接入层、采集与执行层、领域服务层、编排与调度层、应用与展示层。切分的核心依据不是“代码多少”，而是变化频率与职责边界：设备接入层随硬件与协议变化，采集执行层随采样策略变化，领域服务层随标定业务规则变化，编排层随试验流程变化，展示层随交互需求变化。依赖方向严格自上而下，禁止下层反向依赖上层。

设备接入层负责物理链路与协议适配，输出统一的“通道抽象”：每个通道有唯一标识（如 bench01/ecu/can0/signal:EngSpd）、物理量纲、采样率、有效范围与时间戳基准。采集与执行层负责周期采集、事件触发采集、写值下发与安全联锁，向上提供“读一批信号 / 写一组参数 / 订阅变化”三类原语。领域服务层承载标定业务：参数集管理、版本与差异比对、标定任务定义、结果判定规则。编排与调度层负责把标定任务拆成可并行的子任务，管理资源池与优先级。应用与展示层提供任务编排界面、实时监视、报表与追溯查询。

微服务与单体的权衡：按“部署边界”而非“技术时髦”决策

平台初期最容易犯的错误，是把“分层”直接等同于“拆微服务”。实际上，分层解决的是代码依赖问题，微服务解决的是部署与伸缩问题，两者不是一回事。建议的决策规则是：只有当某个模块具备独立的伸缩需求、独立的发布节奏、或独立的技术栈时，才拆为独立服务。

具体到本平台，设备接入层与采集执行层通常与现场硬件强绑定，部署在试验台旁的工控机上，适合做成一个“边缘采集服务”，以单体形态运行，内部再分模块。领域服务层中的参数集管理、版本差异、判定规则，属于纯业务逻辑，无硬件依赖，可以拆为 2～3 个微服务，便于独立迭代。编排与调度层是全局单点，建议独立部署但保持单体，避免分布式事务。应用与展示层是前端，天然独立。

一个可参考的初期部署形态是：边缘采集服务（单体，每台试验台一个实例）+ 领域服务（2～3 个微服务）+ 调度服务（单体）+ 前端。这样既保留了微服务的独立迭代优势，又避免了“每个功能一个服务”带来的运维复杂度。判断是否该继续拆分的信号是：某模块的发布频率显著高于其他模块，或某模块的资源占用（CPU/内存/IO）成为瓶颈。

数据流与接口设计：三类接口，三种契约

平台内部的数据流可以归纳为三条主线：控制流（自上而下的指令）、数据流（自下而上的采样与结果）、状态流（双向的健康与进度）。接口设计的关键，是为这三条主线分别定义清晰的契约。

控制流接口采用请求-响应模式，适合用 gRPC 或 REST。以“下发标定任务”为例，请求体应包含任务 ID、目标 ECU、参数集版本、工况序列、判定规则 ID、超时与重试策略。响应体返回任务受理状态与预计开始时间。这类接口必须幂等：同一任务 ID 重复提交应返回相同结果，避免网络重试导致重复执行。

数据流接口采用发布-订阅模式。采集层将通道数据按固定周期（如 10 ms）打包为批次，附带单调递增的序列号与统一时间戳基准，发布到消息总线。领域服务订阅所需通道，做在线计算与判定。这里必须明确时间戳约定：所有时间戳统一为 UTC 毫秒，采集层负责将硬件时间戳对齐到该基准，上层不再做二次换算。

状态流接口采用事件通知模式。任务状态机（待调度→运行中→暂停→完成/失败）的每次跃迁都产生一个事件，携带任务 ID、旧状态、新状态、时间戳与原因码。前端通过 WebSocket 订阅这些事件，实现实时刷新。

接口契约一旦确定，应写入版本化的接口定义文件（如 .proto 或 OpenAPI），并纳入代码仓库。任何破坏性变更必须升版本号，禁止直接修改已发布接口的字段语义。

一个可落地的接口字段示例

以下为“标定任务下发”接口的请求体示例，字段均为本节教学示例，非实测数据：

{
  "task_id": "CAL-2024-0417-001",
  "ecu_target": "EMS_01",
  "param_set_version": "v3.2.1",
  "sweep_axes": [
    {"signal": "EngSpd", "unit": "rpm", "points": [800, 1200, 1600, 2000, 2400]},
    {"signal": "InjTiming", "unit": "degBTDC", "points": [5, 10, 15, 20]}
  ],
  "dwell_ms": 2000,
  "judge_rule_id": "RULE_TORQUE_STD_01",
  "timeout_s": 3600,
  "retry_policy": {"max_retries": 2, "backoff_s": 30}
}

该请求表达的是一个二维扫描任务：转速 5 个点、喷油提前角 4 个点，共 20 个工况点，每点稳定 2000 ms 后采集。调度层将其拆为 20 个子任务，按资源池可用性并行执行。判定规则 ID 指向领域服务中的规则定义，采集完成后由规则引擎输出每个工况点的通过/失败与偏差值。

架构落地时的三个检查点

依赖方向检查：用静态分析工具扫描模块导入关系，确保不存在下层反向依赖上层。这是分层架构能否长期维持的关键。
接口版本检查：每次发布前对比接口定义文件，确认无破坏性变更，或有明确的版本升级与兼容策略。
数据流可追溯检查：任意一条标定结果，应能沿数据流反向追溯到原始采样批次、任务 ID、参数集版本与判定规则版本。这是标定平台区别于普通测试工具的核心能力。

总体架构设计不是一次性画完的框图，而是一组需要持续维护的约束：分层约束依赖方向，服务拆分约束部署边界，接口契约约束数据交换。把这三组约束写进工程规范，平台才能在后续 30 个章节所涉及的功能扩展中保持可控。