工业软件架构与迁移案例 / Industrial Software Architecture and Migration Case Studies

案例文章保留真实约束、证据和决策过程，不把某一次项目选择包装成普遍结论。

工业软件案例的价值不在于展示一张漂亮架构图，而在于记录约束如何迫使团队做出取舍。相同的求解器、插件框架或数据格式，在桌面单机、企业私有化和云端协同场景下可能得到完全不同的方案。读者需要看到当时有哪些选择、为什么排除某些选择、结果用什么证据验证，以及哪些结论不能迁移到其他项目。

从问题到证据的案例链路

业务目标与现状
      │
      v
约束清单 -> 候选方案 -> 决策记录
                         │
                         v
                 分阶段实现与迁移
                         │
                         v
              正确性 / 性能 / 运维验证
                         │
                         v
                 复盘、局限与后续动作

目标必须可验证，例如缩短某类模型的前处理时间、兼容既有工程文件、隔离第三方插件故障，或让求解任务能够恢复。诸如“提升架构先进性”无法直接验收。约束需要说明数据规模、平台、许可证、团队能力、时间窗口和不可停机要求；缺少这些背景，读者无法判断方案是否合理。

1. 案例边界与事实等级

案例开头应说明它属于哪一种材料：

• 已上线生产系统；
• 真实项目中的局部改造；
• 可运行原型；
• 架构设计研究；
• 基于公开资料的产品分析；
• 教学示例。

不同等级允许得出的结论不同。 原型可以证明接口和数据流可行，不能证明长期稳定、生产性能和组织落地。

公开资料分析可以比较可观察能力，不能推断供应商内部实现。 没有源码或测量证据时，应明确写“无法验证”。

案例中的事实还应区分：

Observed fact
  -> measurement / source / artifact

Engineering interpretation
  -> explanation based on evidence

Decision
  -> choice under project constraints

General principle
  -> reusable only within stated boundary

把解释写成事实，会让读者无法判断证据强度。

2. 写清业务目标

业务目标需要可验证。

不合格目标：

• 架构更先进；
• 提升用户体验；
• 支持大模型；
• 实现插件化；
• 提高性能。

可验证目标示例：

• 旧版工程在新平台打开后，关键实体和工况映射保持一致；
• 500 万单元模型首次可交互时间低于 20 秒；
• 第三方格式解析崩溃不能终止主界面；
• 求解任务中断后可从最近 Checkpoint 恢复；
• 核心插件支持两个宿主主版本的迁移窗口；
• 发布失败后 15 分钟内回滚到可用版本。

目标还要写不在范围内的内容。 明确非目标可以防止案例被后来的无限需求重新解释。

3. 现状调查

迁移或重构前先建立现状地图。

需要调查：

• 用户角色和高频流程；
• 工程文件与数据规模；
• 几何、网格、工况和结果关系；
• 插件与脚本生态；
• 求解器与许可证；
• 外部格式与合作方接口；
• 构建和发布方式；
• 硬件与操作系统；
• 已知性能瓶颈；
• 历史故障和恢复方式；
• 团队技能和维护责任。

Current System Map
├─ Users and workflows
├─ Data and formats
├─ Components and dependencies
├─ Runtime and deployment
├─ Operational evidence
└─ Organizational ownership

只画组件图会漏掉真实操作和组织边界。 很多迁移失败不是技术不可行，而是旧脚本、文件或审批流程没有被发现。

4. 约束分类

约束可以分为：

产品约束

• 必须兼容哪些用户工作流；
• 哪些操作不能中断；
• 哪些功能允许降级；
• 可接受的学习成本。

数据约束

• 文件数量与最大规模；
• 版本跨度；
• 单位和坐标系；
• 旧插件私有数据；
• 保留与合规要求。

技术约束

• 支持平台；
• 编译器与 ABI；
• GPU 与驱动；
• 网络和离线环境；
• 第三方库许可证。

项目约束

• 交付时间；
• 团队规模；
• 可用测试环境；
• 迁移窗口；
• 预算和采购周期。

约束应标明硬约束或偏好。 硬约束不能被候选方案违反，偏好可以通过权衡调整。

5. 候选方案应公平比较

所有候选方案使用同一组维度。

维度	需要回答的问题
正确性	怎样保持领域与数值语义
兼容性	旧文件、脚本和插件怎样处理
性能	端到端瓶颈和资源上限是什么
可靠性	崩溃、取消和恢复怎样处理
安全	权限、供应链和输入边界是什么
运维	安装、升级、日志和回滚怎样完成
成本	开发、迁移和长期维护成本是多少
可逆性	如果判断错误，退出成本有多大

不要给偏好方案写十页细节，却用一句“过于复杂”否定其他方案。

6. 架构决策记录

重要选择应形成 ADR，而不是只存在会议记忆。

ADR 至少包含：

• 标题和状态；
• 决策日期；
• 背景与问题；
• 关键约束；
• 候选方案；
• 选择结果；
• 正面与负面后果；
• 验证计划；
• 回滚或重新评估条件。

决策记录不是为了证明当时的人永远正确。 它使后来者知道当时掌握了什么信息，以及约束变化后应重审什么。

7. 数据迁移

迁移方案需要独立描述数据，而不是只描述新代码。

legacy source
  -> inventory and classification
  -> schema mapping
  -> conversion
  -> semantic validation
  -> target storage
  -> reconciliation report

数据迁移要回答：

• 是否全量或增量；
• 稳定 ID 怎样保持；
• 未知插件数据怎样保留；
• 单位和坐标系怎样转换；
• 失败是否可重试；
• 新旧系统并行期间谁是权威；
• 如何核对数量、引用和数值；
• 如何回滚。

只比较文件能否打开不够。 需要验证实体关系、属性、工况、结果引用和领域不变量。

8. 分阶段迁移

大规模迁移通常不适合一次切换。

Phase 0: observe and inventory
Phase 1: read-only compatibility
Phase 2: dual run and compare
Phase 3: limited write path
Phase 4: progressive migration
Phase 5: retire legacy path

每个阶段都应有进入条件、退出条件和回滚点。 双运行期间要比较结果，而不是仅确认两个系统都返回成功。

新旧系统并行会增加同步成本。 这个阶段应有期限，否则临时桥接会变成永久架构。

9. 验证矩阵

案例验证至少覆盖：

1. 领域正确性；
2. 数值正确性；
3. 文件往返；
4. 版本兼容；
5. 插件组合；
6. 大规模性能；
7. 取消和失败恢复；
8. 部署升级；
9. 权限与安全；
10. 生产可观察性。

性能结果保存原始样本和环境。 数值结果保存容差、残差和对照来源。

故障注入包括磁盘写满、依赖缺失、任务崩溃、网络中断和旧插件加载失败。

10. 上线证据

上线不是案例的最后一句话。 需要记录灰度范围、观察指标、异常和回滚准备。

deploy candidate
  -> health and smoke tests
  -> limited users / projects
  -> observe correctness and SLI
  -> expand or rollback

对工业软件，还要检查真实工程文件、许可证、GPU 驱动和离线环境。

11. 复盘结构

复盘应回答：

• 目标是否实现；
• 哪些假设被证实或推翻；
• 实际成本与估计差异；
• 哪些故障提前发现；
• 哪些故障只在生产出现；
• 哪些临时方案需要偿还；
• 哪些原则可以迁移；
• 哪些结论只适用于当前约束。

复盘不寻找个人责任，而是改进系统和决策过程。 行动项需要负责人、截止条件和可验证结果。

12. 案例写作验收

一篇案例在发布前检查：

• 背景和目标可验证；
• 约束完整；
• 事实与解释分离；
• 候选方案公平；
• 数据流和失败边界有图；
• 决策后果明确；
• 迁移和回滚可执行；
• 证据能追溯；
• 局限和反例存在；
• 没有虚构数字或内部实现。

案例附件还应包含最小可复现材料：

• 输入数据说明；
• 运行或测量命令；
• 关键配置；
• 软件与硬件版本；
• 原始结果位置；
• 差异或对照报告；
• 已知失败样本；
• 脱敏和授权说明。

当前案例

• 从 ANSYS 工作流到 FastCAE 架构的映射

案例分析模板

1. 业务目标与不在范围内的事项；
2. 现有系统、数据和插件生态；
3. 几何—网格—求解—结果链路；
4. 性能、兼容性、安全与部署约束；
5. 候选方案及其不可逆成本；
6. 分阶段迁移和回滚策略；
7. 验证指标与事后复盘。

怎样记录候选方案

每个候选方案至少说明模块边界、数据流、部署方式、迁移成本和失败模式。比较时使用同一组维度，不能只详细描述偏好的方案，再用一句话否定其他选择。对于不可逆决定，例如文件格式、公共插件 ABI 或长期存储模型，应说明兼容策略和退出成本。

案例中的图应展示真实决策关系。例如迁移案例可以画出旧系统与新系统的共存阶段、数据转换位置和回滚路径；性能案例应画出测量点和关键数据移动；插件案例应画出宿主、扩展和进程隔离边界。图后要解释为什么边界放在这里，以及边界失败时由谁恢复。

验证不能只写“运行正常”

正确性验证应包含代表性数据、基准结果或与可信实现的对照。性能验证要记录硬件、数据规模、构建参数、预热和统计方法，避免只报告最好的一次结果。兼容性需要覆盖旧版本文件、不同插件组合和升级回退。部署验证则包括安装、权限、日志、备份、恢复和故障注入。

如果案例没有真实生产数据，应明确写成设计研究或原型验证，并说明哪些结论仍待验证。敏感信息可以匿名化，但不能用虚构数字填补证据空缺。

如何提炼可复用结论

复盘需要区分“本项目事实”和“可迁移原则”。例如某项目选择进程外求解器，事实可能是求解器会崩溃且许可证限制独立进程；可迁移原则则是高风险、长时间任务应与交互进程隔离。结论还应列出反例：当模型很小、启动成本占主导时，同样的隔离方式可能不划算。

一篇完整案例最终应让读者能够重建决策：在相同约束下得到相近选择，在约束变化时知道应该重新评估哪一部分，而不是机械复制最终架构。