仿真试验管理系统：从任务创建到报告归档
摘要
本文实现了一套面向仿真试验全生命周期的管理系统。系统不实现仿真引擎本身，而负责将试验任务、想定与模型资源、计算资源调度、运行监控、结果分析与报告归档组织为一条可追溯链路，使系统复杂度集中于流程与数据而非算法。本文讨论了其中取舍味道最浓的几处设计：流程回退与状态机、功能域与业务阶段的错位划分、消息队列的归属、过程记录的独立建表，以及资源调度中的规格匹配与规则自验证。
1 引言
这套系统的边界值得先说清楚：它不管仿真怎么算，只管仿真这件事怎么被组织起来。引擎是别人写的，可能是商业软件，也可能是自研求解器；本系统要做的是把任务、资源、运行记录与结果报告串成一条可追溯的链路。
这个定位带来一个直接后果：复杂度主要落在流程与数据上，而不是算法上。整套设计里真正带算法味的只有资源调度一章，其余都是状态怎么流转、数据怎么存、接口怎么接。
2 系统总体设计
试验任务是一条主线，自任务创建起，经想定配置、提交审批、资源调度、运行监控、结果分析，至报告生成与归档共八个阶段；功能按业务阶段划为五个域，技术架构自下而上分四层。各模块职责与完整设计参数见附录，下文只讨论关键设计取舍。
3 关键设计取舍
3.1 流程回退与状态机
阶段之间不止有正向流转，还有两种回退：审批不通过的任务退回想定配置阶段修改，运行异常的实例可触发重试或终止。
这条看着平淡，却是这类系统的核心价值。若没有回退路径，一个填错参数的试验只能新建任务重来，前面填写的内容全部丢失；有了回退，修改是在原任务上继续，历史记录也留在同一条链上。
我在设计时把状态机单独画成一张图，因为口头描述流程容易出现两种情况说不清：同一状态下能执行哪些操作不明确，以及异常路径被遗漏。画成图之后，每个箭头都必须有对应的代码分支，漏掉一个就是缺陷。
3.2 功能域与业务阶段的错位
五个功能域与八个业务阶段并非一一对应，这是有意的：功能域按”由谁维护”划分，阶段按”业务如何推进”划分。资源管理需要服务的并不只是创建阶段——运行阶段同样要按版本获取模型。
3.3 消息队列归属于数据层
系统为分层架构，我将消息队列置于数据层而非服务层。理由是它在此系统中的角色是状态变化的传输通道：运行监控、日志回传与调度结果通知均依赖它。归入数据层是为了提醒自己它是基础设施，而不是某个业务模块的私有组件。
4 数据设计
4.1 核心实体与关系
核心实体四个：试验任务、想定资源、模型资源与运行实例。其关系可概括为一句话：任务是想定的一次使用，实例是一次实际运行。表结构与数据字典见附录。
4.2 过程记录必须独立建表
资源调度记录表与报告归档表并非业务实体，而是过程记录。我将它们单独建表，而非在任务表上增设字段，原因是一个任务可能被调度多次（重试）并生成多份报告（修改参数后重跑）。若只在任务表上保存单一字段，这些历史即告丢失。
5 接口与资源调度
5.1 接口链上两个易忽略的点
试验任务提交后，系统向资源平台申请计算资源，获得调度结果后向仿真引擎下发想定并启动仿真，运行期间持续接收状态回传，仿真结束后生成报告并归档。这条链上有两点容易被忽略。
其一，申请资源与下发想定之间存在等待，界面必须将”排队中”与”运行中”区分呈现，否则用户会判定系统已卡死。其二，状态回传是持续行为，意味着系统必须处理”任务仍在运行但连接已断开”的情形，实践中依靠心跳超时判定实例异常。
5.2 资源调度：规格匹配最容易被做错
调度规则综合考虑任务优先级、截止期与资源匹配三项。其中第三项最容易被做错。
若仅按优先级排队，可能出现排于队首的任务需要八个计算节点、而池中仅余四个空闲节点的情况，整个队列被单一任务阻塞。因此分配前必须完成资源规格匹配，将能够被当前空闲资源满足的任务提前。
5.3 调度规则自身也要被仿真验证
调度效果仅以两项指标衡量：任务平均等待时间与资源利用率。二者存在天然对抗——压缩等待时间需扩大并行度，资源利用率随之下降；提高利用率则需将任务尽量塞满节点，等待时间随之上升。
因此调度规则的任何调整，均需在并发任务场景下通过仿真回放，验证其对两项指标的影响。换言之，本系统的用途之一，就是作为自身调度策略的试验台。
6 部署与运维
分层部署的缘由很直接：计算节点的资源规格与负载特征同业务服务差异显著，混置于同一台机器上会出现”仿真运算拖垮接口”一类问题。
三类数据采用三种备份策略，依据是变化频率与恢复要求不同：关系数据每日变动，故每日备份；想定与模型文件仅在版本变更时变动，按变更触发即可；报告归档文件生成后不再变动，但需长期保存，故走异地归档。
运维监控的四类指标中，我特意加入了调度队列长度。它比资源利用率更早暴露问题：当利用率尚在百分之六十时，队列可能已在快速堆积，说明任务的资源需求规格与资源池不匹配，应予扩容的是特定规格的节点，而非全部节点。
7 结论
本文实现了一套管理仿真试验全流程的系统，其价值不在于算法，而在于把试验活动组织为可回退、可追溯、可验证的链路。设计中最值得记住的有三点：回退路径决定了历史是否保留，过程记录独立建表决定了重试是否可查，以及调度规则必须接受与业务同等的仿真验证。
附件
