简介这份PDF是达索PLM系列博客的架构篇终稿面向PLM实施顾问、企业信息化人员以及对Enovia系统感兴趣的初学者。内容从业务逻辑架构展开涵盖新产品立项、研发、工艺、配置、成本、质量与知识管理等全生命周期业务随后介绍系统安装部署架构说明应用服务器、数据库服务器、文件服务器与license服务器的职责划分并详细讲解应用架构中的项目管理、单一数据源、DBOM/EBOM及工艺路线等应用模式。技术管理方面梳理了存储层、应用层与使用层的三层结构以及TomEE中间件、建模、缓存、适配器等技术要点数据仓库部分则解释了多Vault隔离机制及Oracle实例管理。资源为单个PDF文档压缩包约993KB内容结构清晰适合作为Enovia架构入门与备查材料。目前已有529人学习/浏览对于希望系统了解达索PLM整体框架的读者很有价值。1. 达索PLM的 Enovia 系统架构先看清这张图再动手部署很多团队拿到《达索PLM那些事2Enovia系统架构终稿.pdf》这份文档第一反应是把拓扑图截下来发给运维照着 IP 段直接装环境。我见过不止一次这样的翻车客户端连不上或者 checkout 对象卡死查到最后根本不是软件问题而是没看懂架构图里服务和存储的关系。这里就顺着这份终稿讲 Enovia 系统架构逻辑上分几层、物理上怎么部署、数据库与文件库怎么配合、哪些参数实施前就得定好以及最常见的坑。适合刚接手 Enovia 实施或运维的 PLM 工程师、系统架构师也适合准备从测试环境迁到生产环境却还没想清楚容量规划的团队。2. 从逻辑架构到数据模型Enovia 的骨架是怎么搭起来的2.1 Enovia 的逻辑分层表现层、应用层、对象层、存储层Enovia 的逻辑架构行业内通用的描述是四层模型。最上面是表现层负责接收用户操作并渲染结果。这里不只是浏览器里的 Web 界面还包括 CATIA、SOLIDWORKS 这类 CAD 客户端的集成端以及 EKL 脚本触发的批处理入口。表现层不直接访问数据库所有请求都通过下一层的应用服务转发。第二层是应用层核心是 Matrix Application Server常被简称为 Matrix Server。这一层承载业务逻辑、触发器、命令和后台任务也是日常运维里配置改动最多的地方。第三层是对象层由 Business Object 模型构成把数据库里的记录包装成带类型、属性和关系的对象。最后一层是存储层包含关系型数据库、文件库和索引服务负责把对象和文件真正落盘。这个分层的意义在于问题排查时可以先判断故障落在哪一层。客户端报错但其他客户端正常问题多半在表现层或网络所有客户端都慢应用层和数据库层的嫌疑最大只有下载文件慢那通常要去看文件库和网络的配置。很多实施团队一上来就查数据库其实是走了弯路先定位层次再动手效率会高很多。从这份终稿的角度看逻辑架构图通常画在文档最前面但它不是用来欣赏的。照着逻辑架构图做物理部署映射才是它的真正用途表现层对应 Web 服务器和 CAD 集成主机应用层对应 Matrix Server 集群存储层对应 Oracle RAC 和文件库阵列。这个映射关系在实际项目里容易出错因为中间隔着负载均衡器、网络分段和高可用机制物理主机和逻辑层并不是一一对应。2.2 数据模型的核心Business Object、Type 与 RelationshipEnovia 的数据模型建立在 Matrix 对象框架上任何业务数据都被抽象为 Business Object。系统预置了相当多的类型比如 Document、Part、Person、Project实施时会在这之上扩展自定义类型。每个类型有自己的属性表实例则通过 Relationship关系连接起来形成一张有向图。这里有个容易忽略的细节Enovia 里的 Type 是严格继承的子类型会继承父类型的属性和关系定义但对象实例一旦创建类型就不能随意改变。所以架构设计阶段先把类型树定清楚比实施到一半再调类型重要得多。另一个细节是属性分为系统属性和用户属性系统属性如 owner、createtime 在创建对象时自动写入用户属性则要显式定义并分配权限。接口表关系也值得关注。数据库中常见的表有 bus业务对象主表、docversion文档版本表、prog程序表和 rel关系表等。这些表并不像 ERP 系统那样按业务域拆得很细而是高度抽象对象的具体业务含义由类型和属性描述表结构只负责承载。这也是 Enovia 实施时新人容易懵的地方——数据库里看不到一张叫 bom 的表BOM 结构是通过关系对象表达的。关系本身也是对象可以有属性。比如“Part 引用 Document”这条关系可以挂上“引用顺序”“备注”等属性。这和传统关系型数据库的外键思路差异很大理解了这个模型后续的查询和报表开发才会顺手。终稿的数据模型章节通常会给出一张类型关系图我建议把它当成数据库表结构的对照表来读而不是当成概念图。2.3 MQL 与 TCL两条绕不开的控制线Enovia 提供两个重要的操作接口。一个是 MQLMatrix Query Language用于查询和修改对象模型另一个是 TCL 脚本用于编写业务逻辑、触发器和定时任务。在系统架构层面这两条线分别对应数据访问和业务扩展两个方向。MQL 在运维里最常见的用途是批量查数据和修数据。比如查一个类型的全部实例、看某个对象的属性、找关系链一条命令就能完成。MQL 的执行并不总是走应用服务器部分指令可以直接对数据库发起这也是部署架构里要区分读路径和写路径的原因之一。在搭建系统时MQL 访问权限由后台访问控制策略统一管理不建议给每人开独立管理权限。TCL 脚本则跑在 Matrix Server 内部通过 Enovia API 和 MQL 调用实现逻辑。架构层面要注意的是TCL 的执行环境独立于 Web 容器有自己的一套上下文机制。如果脚本里访问了尚未启动的文件服务或索引服务就会抛出运行时错误这类错误在部署初期相当常见而且只看 Tomcat 日志不一定能看到真正的堆栈。实施团队在架构评审时应该要求开发商提供一份完整的 MQL 对象清单和 TCL 脚本目录。终稿里通常会有这部分内容但很多团队只关注拓扑图把脚本目录当附录忽略掉。实际上这两份清单决定了后续权限配置和工作流开发的边界值得花时间逐条核对。2.4 对象生命周期状态机如何影响存储行为和性能对象从创建到废弃经历的是状态机控制的生命周期。在 Enovia 里状态控制着用户能对对象做什么在“工作”状态可以编辑在“发布”状态只能读取在“废弃”状态连读取权限都可能被收走。每个状态转换可以挂触发器和命令这就形成了一套完整的业务闭环。架构层面要理解的是状态机并不是单纯的数据字段它会影响物理存储行为。比如对象在“工作”状态时文件内容可能存储在本地文件库切换为“发布”状态后系统会把文件推到远程文件库这个过程受文件复制策略控制。如果文件库之间的网络带宽不够发布一个大装配体就会触发大量文件同步表现为状态转换很慢。所以架构设计时要对对象状态转换频率做预判。研发类企业通常把状态分为工作、评审、发布、变更、废弃等几个档位每个档位的文件存储位置不同。在规划文件库时要把发布态对象的容量单独估算而不是简单地“所有文件都放一个盘”。这份终稿如果做得好会在状态机章节附近给出容量预估方法这部分值得仔细读。3. 物理部署架构与关键配置把拓扑图画成能跑的机房3.1 经典拓扑单机、双机与高可用集群Enovia 的物理部署从实施角度看常见三种形态。最基础的是单机部署Web 服务器、Matrix Server、数据库都装在一台主机上适合开发测试环境或人数少于 50 的试点团队。单机部署不是没有优点它排障快、备份简单我见过不少小团队把单机跑了好几年也没出大事前提是并发用户数控制得住。第二种是双机部署应用层和数据库层分开Web 服务器可以和应用服务器同机也可以独立。这是中小规模生产环境的常见选择数据库单独一台机器后备份和恢复操作不会拖垮应用响应。第三种是高可用集群多台 Matrix Server 前置负载均衡数据库走 RAC文件库做实时同步。这种形态面向几百上千人的集中部署也是终稿里篇幅最大的部分。无论哪种拓扑有个原则没变过不要把应用服务器和数据库服务器混在一起跑重负载业务。Enovia 是典型的 CPU 和 IO 敏感型应用Matrix Server 对内存要求高Oracle 对磁盘 IO 要求高两者同机时往往互相抢资源。我在实际项目里见过一台 32 核机器同时跑应用和数据库日常在线用户刚过 100 就频繁出现锁等待拆开后性能立刻恢复正常。部署拓扑的决策要结合业务规模而不是追求组件越多越好。很多团队照着终稿里的集群架构搭了一套全家桶结果发现日常负载根本打不满反而因为组件多、链路长每次变更都要停好几个服务。我一般会把在线用户数、日均对象创建数、模型文件平均大小这三个数字先算出来再决定要不要上集群。3.2 文件库File Vault选型与路径规划文件库是 Enovia 最容易低估的部分。数据库里存的是对象属性和元数据真正的 CAD 文件、Office 文档、PDF 转换结果都存在文件库里。文件库一旦规划不合理后续加盘、迁移都是大工程属于典型的前期省事后期还债。文件库在逻辑上分为本地文件库Local Vault和远程文件库Remote Vault。本地文件库和 Matrix Server 在同一台机器上响应速度最快远程文件库通过网络被访问用于跨站点共享。实施时还可以把多个物理路径组成一个带区Striped Vault文件按照策略分布到不同磁盘上以提升吞吐。路径规划上我一般遵循三条原则。第一文件库不要放在系统盘系统盘满了直接影响操作系统稳定性第二本地文件库和远程文件库的路径要提前统一命名规范避免 Unix 和 Windows 混用第三文件库预留空间按数据库容量的 5 到 10 倍估算这不是拍脑袋而是 PLM 系统里模型文件通常比元数据大几个数量级。一个需要提前确认的点是文件复制策略。发布状态的对象会被推送到远程文件库这个复制动作受调度任务控制如果两条文件库链路带宽不足会在每个发布动作上堆积大量同步任务。我建议在架构设计时就把各站点间的带宽需求写清楚不然上线后每次发布都很慢用户的第一反应是升级服务器配置实际上网络才是瓶颈。3.3 分布式交换机Distributed Switch与联邦架构终稿里如果出现“分布式交换机系统架构”这个名词指的不是网络设备的交换机而是 Enovia 跨站点文件转发机制中承担路由角色的一层组件。分布式交换机的作用是把客户端访问文件库的请求定向到最近的文件库节点从而减少跨站点的文件传输量。这个机制在部署上的关键点是站点配置。每个站点有自己的一组文件库和交换机节点客户端归属于哪个站点决定了它从哪里取文件。配置错误时最常见的现象是A 站点的用户下载一个归档文件请求被转发到 B 站点的文件库带宽被占满速度却很慢。这种情况在架构图上看不出问题要看运行时日志里的站点间调度记录。联邦架构Federated Architecture则解决的是多套 Enovia 实例之间的对象共享问题。复杂的企业里可能有多个 PLM 实例各自的站点、权限、文件库独立联邦架构让它们能以统一入口对外提供服务。跨实例的对象引用需要配置业务模型服务这部分实施难度大一般不在初版上线范围内但架构设计时要有预留。分布式交换机和联邦架构的共同点是它们都引入了额外的网络跳数也在排障时增加了黑匣子。如果企业还没有跨地域协同的硬需求我不建议为了“架构完整”而把它们全部打开先跑通单站点再逐步扩展运维和用户都会省心不少。3.4 JVM 堆内存与连接池的初始建议Matrix Server 跑在 Tomcat 容器里JVM 堆内存和数据库连接池是最先需要定下来的两个参数。下面给出一份常见的最小配置模板以 Tomcat 的 setenv.sh 为例# 以 Tomcat 8.5 承载 Matrix Server 时的 JVM 参数示例 CATALINA_OPTS-Xms4096m -Xmx8192m -XX:MaxMetaspaceSize1024m -Djava.awt.headlesstrue -Dfile.encodingUTF-8 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/enovia/logs/heap.hprof逻辑说明-Xms 和 -Xmx 控制堆内存的大小生产环境建议将两者设为相同值避免 JVM 运行时反复扩容收缩带来的停顿。-XX:HeapDumpPath 是为了在内存溢出时留下现场文件配合 -XX:HeapDumpOnOutOfMemoryError 一起使用不然翻车后连排障依据都没有。数据库连接池在应用服务器里配置常见的参数组合如下表参数初始建议值说明initialSize10启动时预创建连接数maxActive50最大活动连接数按并发用户数调整maxWait10000获取连接的最大等待毫秒数超时抛异常removeAbandonedTimeout300超过 300 秒未归还的连接将被强制回收testOnBorrowtrue每次借用连接时校验有效性防止拿到死连接maxActive 不是越大越好。连接池的最大值要换算成数据库端允许的最大会话数留出 30% 的余量给后台任务和 MQL 直接连接。很多故障案例都是把 maxActive 调到 200结果 Oracle 的 processes 参数只有 150数据库直接拒绝新会话整个系统表现为“连不上”而不是“变慢”。这一章的思考方式可以复用凡是架构图里出现了一个组件就要问清楚它对应哪个进程、监听哪个端口、依赖哪些文件的落盘路径。把这张表补齐拓扑图才算真正落地。4. Enovia 部署避坑指南五条能省一周排障时间的记录4.1 数据库字符集不一致导致中文乱码现象对象属性里的中文正常但通过 MQL 查询导出的中文全部变成问号或者 Web 界面能显示中文报表导出的 Excel 却是乱码。原因Enovia 应用层使用 UTF-8 编码但数据库实例的字符集配置不一致应用写入和读取的编码映射出现偏差。还有一种情况是 JDBC 连接字符串里漏了 characterEncodingUTF-8导致驱动层用了默认编码。解决统一字符集是唯一正路。数据库实例在安装时就设置为 AL32UTF8连接串里显式加上 encoding 参数。对已经乱掉的历史数据先导出再转换回 UTF-8 重新导入不要想着在线改字符集风险极高。架构评审时把字符集这一项列入检查清单能省掉后续大量返工。4.2 文件库磁盘满导致 Checkout 直接失败现象用户执行 Checkout 时提示写入文件失败或者 Checkin 到一半中断报错信息里出现磁盘空间不足字样。数据库连接正常应用日志也没有异常堆栈但文件就是传不上去。原因文件库的磁盘空间满了但监控只看了数据库所在磁盘的使用率没有检查文件库路径所在挂载点。Enovia 做 Checkout 时会先把文件缓存到本地文件库如果本地文件库路径写到了 /tmp 或系统盘这些小文件会先把系统盘占满。解决将文件库挂载到独立分区并纳入磁盘监控。给文件库所在挂载点留出 20% 的空余空间这是 I/O 性能和碎片整理的底线。日常运维至少每周检查一次文件库空间趋势大版本发布前要提前做一次容量预判不然大批量转换文件会把空间一次打满。4.3 连接池设置过大把数据库连接数打满现象系统运行一段时间后突然所有客户端都报“无法获取数据库连接”但数据库服务器 CPU、内存占用都不高登录数据库查看会话数却发现已经打满。原因连接池的 maxActive 配置超过数据库 processes 参数多个应用节点各自创建连接池累加后超出上限。后台的 Agent 任务也可能通过独立连接占用了额外会话。解决把连接池参数和数据库 processes、sessions 参数放在一起核算。先确定数据库能支撑的最大会话数再把每个应用节点的连接池上限分配好。更改配置后要滚动重启应用节点不要单节点热加载避免连接池新旧配置并存造成二次打满。4.4 索引服务没启动全文检索悄悄失效现象全文搜索某些关键字一直无结果但对象在数据库里明确存在。按属性精确查询正常只有全文检索相关的搜索入口异常。原因Enovia 的搜索依赖独立的索引服务索引服务没有随 Matrix Server 一起启动或者索引队列积压。索引服务有自己的进程、日志文件和数据目录它挂了并不会导致系统整体不可用所以很容易被忽略属于典型的隐性故障。解决把索引服务加入开机自启和健康检查脚本。日常检查它的进程状态、索引队列长度和错误日志三者有一项异常就告警。如果索引数据目录损坏不要试图去修复索引文件直接用上一次全量索引的快照重建索引重建的时间通常比手工修数据短得多。4.5 JVM 堆内存不足系统不定时假死现象系统每隔一段时间就出现几分钟无响应过一会儿自己恢复恢复后日志里能看到频繁的 Full GC。有时伴随应用节点宕机重启后短时间内正常之后又循环。原因JVM 堆内存偏小对象缓存和会话数据把堆占满触发频繁 Full GCGC 停顿期间所有请求排队等待。常见诱因是 Web 页面加载大对象时把大对象直接放进了堆或者后台批量任务一次性加载过大的对象集合。解决先调 -Xmx 到物理内存的一半以上例如 16G 物理内存给 8G 堆同时检查是否有人写了大分页查询或脚本里一次性拉取了所有对象。调 JVM 参数是治标定位到具体的大对象加载逻辑才是治本。预留堆转储文件开关下次卡死时能直接取现场。这五条记录每一条我都对应着排查过真实问题。把它们整理成团队内部的问题清单比临时翻知识库高效得多。5. 数据库层与性能调优架构图里最容易忽视的瓶颈5.1 表空间规划与 Oracle 参数设置Enovia 的数据库层生产环境基本是 Oracle。表空间规划直接影响长期运维我在项目里见过因为临时表空间太小导致查询直接失败的案例也见过 UNDO 表空间膨胀把磁盘塞满的案例。表空间至少要按数据、索引、临时、UNDO 四类分开规划。数据表空间存业务对象数据索引表空间独立出来是为了避免索引扫描和数据写入争抢 IO临时表空间给排序和大查询用初始大小至少按数据表空间的 20% 规划UNDO 表空间的大小和最长事务的执行时长相关PLM 里批量导入、大批量状态变更都会产生长事务UNDO 设太小会直接报 ORA-01555。Oracle 参数里需要重点确认的是 processes、sessions、open_cursors。processes 决定数据库允许的最大进程数要和连接池核算open_cursors 限制单个会话同时打开的游标数Enovia 的复杂查询或者 TCL 脚本里大量执行动态 SQL 时游标耗尽是比较常见的报错点。架构评审时我会要求 DBA 提供一张参数对比表当前值、建议值、调整理由、影响范围。这样改参数有据可查不会出现上线后某个 session 因为参数不符合要求而连接失败。5.2 大表分析与索引策略从 bus 表说起Enovia 的数据库模型高度抽象大部分业务对象都集中在 bus 表和 docversion 表里这两张表的数据量增长极快几年下来动辄上亿行。索引策略不提前设计查询性能会断崖式下跌。很多运维习惯用 like %关键字% 做模糊查询这种条件无法走索引只能在数据量小时用。在 Enovia 里要检索对象属性正确做法是把条件拆成带前缀的等值或范围匹配-- 不推荐以 % 开头的模糊查询无法使用普通 B-tree 索引 SELECT id, name FROM bus WHERE name LIKE %结构件%; -- 推荐的写法基于前缀匹配 属性过滤 -- 表名按实际环境调整这里以 bus 和 attrs 为例 SELECT b.id, b.name, a.attribute_value FROM bus b, attrs a WHERE b.name LIKE 结构件% AND a.ownerid b.id AND a.attribute_name design_no AND a.attribute_value DS-10245;逻辑说明第一句在数据量小的时候看不出差别等 bus 表超过千万行后面带 % 的查询基本走全表扫描每次查询消耗几十秒。第二句把模糊条件从前缀开始匹配同时把属性过滤放到属性表上让优化器有机会走索引。参数说明attribute_name 和 attribute_value 这组条件在 Enovia 属性表里通常有组合索引记得和 DBA 确认索引顺序是 (attribute_name, attribute_value) 还是相反的这决定了这条 SQL 能不能命中。分区策略也值得做。按时间或按类型把 bus 表做范围分区老数据进入只读分区数据备份和查询性能都能受益。分区表的改造要在上线前做上线后动表结构锁表时间会直接影响业务。5.3 后台任务 Agent 与调度窗口Enovia 的很多动作由后台 Agent 触发比如文件复制、索引更新、邮件通知、状态自动变更。这些 Agent 如果集中在一个时间点执行会造成 IO 和数据库会话的瞬时高峰。建议在系统架构设计阶段就给 Agent 划分好调度窗口。重型的批量任务放在业务低谷期比如夜间文件复制、索引更新这类任务避开上班时段的每整点高峰。每个 Agent 的执行时长要监控连续多次超时的 Agent 需要排查脚本逻辑而不是一味调大超时参数。Agent 与文件库的相互影响也要关注。前面提到的发布状态文件推送本质就是一组 Agent 在多个文件库之间复制文件。如果复制任务堆积先看目标文件库的磁盘和网络再看 Agent 的并发度一般来说并发度调到 2 到 4 就够了调太高反而让磁盘 IO 排队。5.4 用监控指标预判故障四个维度够了监控 Enovia 系统我一般盯四个维度应用层看 JVM 堆使用率和 Full GC 频率数据库看活跃会话数、锁等待和慢查询文件层看文件库空间、文件数量增长速率网络层看各站点之间的传输延迟和丢包率。四个维度分别对应前面的四层架构任何一层指标异常都能在用户投诉前预警。监控工具倒不一定要上多贵的商业产品。开源监控做数据采集配合日志关键字告警就能覆盖大部分场景。重要的是把 Enovia 特有的指标——比如索引队列长度、文件复制任务积压数、MQL 慢查询——纳入监控项这些才是 PLM 系统和普通 Web 应用的区别所在。6. 终稿的正确用法把架构图变成容量规划和升级验证6.1 从架构图反推容量规划拿到终稿后我最先做的事是把拓扑图转成一张容量表每个组件对应几台机器、每台机器的 CPU 核数、内存、磁盘容量、网络带宽。然后填入三个实测数字——在线用户峰值、日均对象创建数、模型文件平均大小——去验证每个节点的容量是不是够用。如果团队里有系统架构设计师我会请他独立核对这张表避免实施方把自己方案的短板也画进图里。比如文件库容量按“日均新增对象数 × 平均文件大小 × 保留周期 × 版本膨胀系数”来算版本膨胀系数取 1.5 到 2因为 PLM 里同一对象的多个版本会同时保留。这个数字如果超出架构图里的磁盘规划就要在实施前申请扩容否则上线后半年就要做一次存储迁移。数据库表空间也是同理按数据增长速率推算一年的占用而不是按初始安装大小。6.2 用终稿指导变更验证每次做版本升级或架构变更前我会拿终稿里的组件清单列一份验证清单升级后索引服务是否正常启动、文件复制 Agent 是否按预期调度、连接池是否恢复到目标值、各站点之间文件传输延迟是否在正常范围。这些验证项都来自架构图里的组件依赖关系比临时想测试用例靠谱得多。最后说一个我的习惯不管终稿画得有多细我第一次部署时都会手工画一份简化版拓扑只保留进程名、端口、日志路径三个要素贴在服务器文档里。遇到问题时看这张表比翻长文档快得多。这套流程帮我躲过很多次低级故障希望帮到你。本文还有配套的精品资源点击获取
与세그먼테이션(Segmentation)原理与实践指南)
