3.1 软件架构组成

3.1 软件架构组成

本节摘要：SOURCE 3.1：现代 CAD 分层为 UI、应用逻辑、几何内核、数据持久化；云原生引入渲染与协同微服务。

从"装修"与"地基"看分层

想象一栋楼：地基、承重墙决定它能不能盖 100 层；装修决定住在里面舒不舒服。CAD 架构同理——几何内核是地基，应用层是装修。地基决定数学上限（能做什么样的几何运算），装修决定使用体验（命令好不好找、界面顺不顺手）。用户整天与装修打交道，但真正决定系统"体质"的是地基。

典型四层架构

各层详解

交互层：用户感知最直接的一层。桌面 CAD 用 Qt/WPF 等框架，Web CAD 用 WebGL 渲染视口。它负责命令分发、图形拾取、视图导航。交互层关注的是"帧率、精确拾取、手势流畅"，不负责几何正确性。

应用层：承载工程语义的中枢。特征建模、装配约束、工程图、钣金、布线……这些业务模块都在这一层。它调用内核完成几何运算，并把运算结果组织成"特征""零件""装配"等业务对象。

内核层：整个系统的"数学心脏"。提供 NURBS 求值、布尔运算、曲面求交、倒角、抽壳、圆角等底层算法。核心要求是稳健性——数学库面对退化输入（重合面、共线边、极小间距）必须给出确定结果，而不是崩溃或输出坏几何。

数据层：持久化与互操作。把内存中的模型序列化为文件（原生格式/中性格式），并通过适配器对接 PDM/PLM。它决定模型能否跨版本、跨系统存活。

内核授权的商业格局

SOURCE 强调内核授权是商业 CAD 的核心成本与出口管制焦点。全球格局大致如下：

内核更换成本极高——CAD 厂商绑定内核后，所有业务代码都围绕其 API 构建。因此"换内核"几乎等于"重写产品"，这就是国产内核必须从早期生态就切入的原因。

开源 OpenCASCADE 降低入门门槛但高端曲面仍差距明显——具体体现在高阶连续性控制、大装配稳健性、复杂布尔的成功率上。

云原生 CAD 的架构演进

传统 CAD 是"单体桌面应用"：所有功能打包在一个进程里。云原生 CAD（如 Onshape、CrownCAD）把架构拆成微服务：

# 云 CAD 微服务示意：渲染与几何分离，各自独立扩容
services = {
    "viewer":   {"role": "亿级三角面片渲染", "scale": "按并发扩"},
    "modeling": {"role": "特征/布尔/约束求解", "scale": "按计算扩"},
    "persist":  {"role": "分布式存储与版本",  "scale": "按容量扩"},
    "collab":   {"role": "实时协同与通知",   "scale": "按在线数扩"},
}

def handle_user_command(user, cmd):
    # 命令先鉴权 → 路由到建模服务 → 结果持久化 → 通知各端刷新
    if auth(user) and modeling.execute(cmd):
        persist.snapshot(user)
        collab.notify_peers(user, cmd)
        return viewer.rerender(user)
​

微服务架构的好处是按需伸缩：渲染高峰扩容 viewer、计算密集型任务扩容 modeling，互不拖累。代价是数据一致性变复杂——多实例并发修改同一模型时，需要事务与锁机制。

架构演进趋势

• 渲染与计算分离：GPU 渲染在客户端/边缘节点，几何求解在云端；
• 插件生态：标准化 API 让第三方行业插件（建筑规范、PCB 布线）入驻；
• 内核即服务：几何内核以云服务形式被调用，降低自研门槛；
• 可移植性：从 WebAssembly 到原生容器，内核可以在浏览器里跑。

一条命令的旅程：从点击到重生

理解架构的最好方式，是追踪一条命令在系统里的完整旅程。以"给圆角半径改为 3mm"为例：

1. 交互层：鼠标拾取圆角特征，弹出参数面板，用户输入 3 并回车；
2. 应用层：命令对象被实例化，先做参数校验（3mm 是否合法、是否与相邻特征冲突）；
3. 内核层：调用内核的圆角重建 API，内核沿圆角所在边重新计算过渡曲面；
4. 数据层：特征树写入新参数，模型持久化快照；
5. 反向传播：内核返回"重建成功"，应用层通知视图刷新，交互层重绘视口。

任何一个环节失败，命令都要回滚到操作前的状态。这就是 CAD 的事务机制——命令要么完全成功，要么完全不生效。

# 命令模式 + 事务回滚的最小示意
class Feature:
    def rebuild(self, params):
        try:
            kernel.fillet_rebuild(self, params)   # 内核计算
            self.history.append(params)           # 记录历史
            viewer.refresh()
        except KernelError as e:
            self.rollback()                        # 失败则回滚
            raise CommandError(f"重建失败: {e}")
​

渲染管线：精度与帧率的平衡

现代 CAD 视口采用分档渲染策略：交互操作时用低精度网格保证帧率，操作停止后用高精度网格保证质量：

GPU 加速（Vulkan/DirectX）让视口能实时处理百万级三角形。云 CAD 进一步把渲染拆成独立微服务，客户端只接收图像流，几何求解留在云端——这解释了为什么瘦客户端也能打开大模型。

插件机制：架构的"可扩展接口"

现代 CAD 的竞争力很大程度取决于插件生态。插件通过 SDK/API 访问内核能力，实现行业定制：

插件机制的关键约束是权限边界：插件只能通过公开 API 操作模型，不能直接触碰内核内部数据结构——否则一个劣质插件就能破坏整个模型的几何一致性。

架构演进的三个阶段

单体架构开发简单、部署直接，但功能耦合导致"改一处全崩"；微服务架构各自独立演进，但引入分布式一致性的复杂度。架构没有最优，只有适应当前规模的最合适。

⚠️ 常见坑：在应用层重复实现求交——应调用内核 API 保证稳健性。

💡 关键直觉：架构 = 谁拥有几何真理。

要点速记

• 内核是地基，应用是房间
• 云 CAD 拆分渲染与协同服务
• 自主内核关乎产业安全
• 微服务换来伸缩性，代价是一致性
• 稳健性：内核面对退化输入必须给出确定结果