methodology

Integration-story

在软件工程里关于继承的一些场景

通过API解耦的性质

web应用的传统开发方式，前后端的分离的模式，通过API的调用。最近的一种基于类似dash plotly的方式是用python后端来同事把前端也表达了，稍微感觉有些不太灵活，不方便定制，但是可能开发起来，出原型的话稍微的快一些。大的应用还是不太推荐这种技术方案的。

这里需要注意的问题是区别哪些参数、或者界面配置是前端传入的，哪些信息是要后端先定义好数据结构然后让前端读出来直接写的。

这里是一个本地vtk+qt以及python vtk + vtkjs的方案对比

VTK 可视化架构方案对比：Qt 前端 vs Web 前端

评估维度 Qt 前端 + VTK 后端 Web 前端 (VTK.js) + VTK 后端
性能 ⭐⭐⭐⭐⭐ 本地零拷贝内存访问，亚毫秒级延迟 ⭐⭐⭐ 受网络传输和序列化开销限制，中等延迟
跨平台一致性 ⭐⭐ 需各平台单独适配，UI行为可能不一致 ⭐⭐⭐⭐⭐ 浏览器环境保证完全一致体验
部署便捷性 ⭐ 需安装客户端，处理依赖库，更新需重新安装 ⭐⭐⭐⭐⭐ 通过URL即时访问，服务端更新全员生效
超大数据处理 ⭐⭐⭐⭐⭐ 原生内存管理，支持100GB+数据集 ⭐⭐ 通常需预处理，传输限制<1GB
系统集成深度 ⭐⭐⭐⭐⭐ 完全控制硬件/OS API，支持专业外设驱动 ⭐⭐ 通过Electron有限集成，硬件访问受限
多用户协作 ⭐ 需自建网络模块实现协作 ⭐⭐⭐⭐⭐ 原生支持WebSocket实时数据同步
UI开发效率 ⭐⭐ Qt Widgets开发慢，QML学习曲线陡峭 ⭐⭐⭐⭐⭐ 使用React/Vue生态组件快速开发
安全可控性 ⭐⭐⭐⭐⭐ 数据完全本地处理，无网络暴露风险 ⭐⭐⭐ 敏感数据需传输至服务器，增加攻击面
技术栈门槛 ⭐ 需精通C++/Qt/VTK，人才稀缺且成本高 ⭐⭐⭐ 前后端分离，JS+C++组合更易招人
移动端支持 ❌ 无官方解决方案 ⭐⭐⭐⭐ 响应式设计适配平板/手机
实时流处理 ⭐⭐⭐⭐ 本地线程高效处理 ⭐⭐⭐ WebSocket支持但受网络波动影响
安装包体积 ⚠️ 50MB+ (含基础QT/VTK库) ✅ <5MB (核心应用)，资源按需加载
热更新能力 ❌ 需重新安装 ✅ 服务端更新即时生效
硬件加速 ✅ 原生OpenGL/Vulkan支持 ⚠️ WebGL特性受限，无CUDA等专业计算支持

关键场景推荐

🖥 优先选择 Qt 前端的场景：

  • 医疗影像处理软件（如DICOM实时重建）
  • 工业仿真平台（需处理GB级CAD数据）
  • 手术导航系统（延迟敏感型应用）
  • 机密数据处理（完全离网环境）
  • 硬件集成项目（如科学仪器控制）

就拿实际应用场景来说，大部分工业相关的软件实际上也都是CS端的架构，安装部署起来也方便，似乎只有可视化展示采用web端的，如果没有运维端的话，说实话看不出来web端有什么意义，可能还是偏向于research场合中的展示使用。

🌐 优先选择 Web 前端的场景：

  • 云端科学计算平台
  • 跨地域团队协作分析
  • 教育/演示类轻量工具
  • 建筑BIM模型查看器
  • 移动端可视化应用（平板/手机）

混合架构建议

+---------------------+     +---------------------+
| VTK C++计算后端     |<----| 本地IPC (共享内存)  |
+----------^----------+     +----------|----------+
           |                          |
           | WebSocket/HTTP           | Qt信号槽
+----------|----------+     +----------v----------+
| 浏览器/Electron客户端 |     | Qt主客户端          |
+----------^----------+     +----------|----------+
           |                          |
           | 可视化指令                | 嵌入WebView
+----------|----------+     +----------v----------+
| VTK.js渲染引擎       |<----| WebView组件         |
+---------------------+     +---------------------+

从开发成本上讲，c++与qt结合的形式，成本还是相对高一些的，找一个前端开发人员比招一个后端开发人员的成本低好多。而且web渲染的方式在解耦方面还是强一些。网上看起来electron还是有一些坑，从效率的角度上讲，还是前端快速出原型，后端调用可能好些，需要克服的问题就是打包使用的问题、效率的问题等等。

通过数据库解耦的形式

k8s可能是一个很好能说明的例子，各个组件都围绕etcd，通过watch关键字段的配置实现各个模块的解耦。还有一种是后端写数据库，前端直接从数据库中读数据的形式，规模或者数据量上到一定程度的时候可能需要这种模式。因为数据输入输出数据库的时间也是一种开销，如果数据量比较小的话就不太需要这种方式。

通过本地文件解耦的形式

类似于CFX或者ansys的各种模块的性质，前面一个应用输出文件之后，后面的应用可以接着导入相关的数据，有点类似于工作流的形式。

插件形式

这种形式对于被集成的服务要求比较高，接口的规范程度是不是够的。比较典型的就是ParaView的插件的形式，比如自己实现了某些算法，然后通过插件的机制集成进来，在框架设计的时候接口一定要提前考虑好可扩展的机制。

特别是界面的定制，主要方法调用的配置，传入，返回值等等。比较保险的方式是先弄几个小的测试，确认接口定义考虑周到了再大规模铺开。

总的来说，集成的问题涉及到不同组的交接，需要大量的沟通协调，在实际开发中应该留足充足的时间。遇到的一些问题是全责划分的问题，需要确认的是接口，而不是具体传入的数据结构的配置，比如作为继承方，我只需要拿到一个vtk的数据，但是vtk的数据具体包括什么，我是不需要知道的。这个在开发过程中可能会随时改变，集成方也是不需要知道的。一个lesson就是，作为集成方，我一定想要让开发方告诉我有哪些数据结构，然后前端界面想要怎么设置等等，这样大家就都很痛苦。

推荐文章