2. Teamcenter整体架构概览

Teamcenter 作为 Siemens 的 PLM 平台，其整体架构可以概括为四层结构：客户端层、应用服务器层、数据库层和文件服务器层。理解这四层的职责边界与数据流向，是后续进行容量规划、性能调优和故障定位的基础。很多实施问题——例如“为什么打开大装配体很慢”“为什么检入大文件时超时”——本质上都可以归因到这四层中的某一层或层间交互。

四层架构的职责划分

客户端层是用户直接接触的部分，主要包括富客户端（Rich Client，基于 Eclipse 的胖客户端）、Web 客户端（Active Workspace）、以及各类集成客户端（如 NX、SolidWorks 等 CAD 集成）。客户端负责界面呈现、用户交互、本地缓存和部分轻量计算。它并不直接访问数据库，而是通过 HTTP/HTTPS 或 IIOP 协议与应用服务器通信。客户端的性能瓶颈通常出现在本地内存、图形渲染和网络带宽上。

应用服务器层是 Teamcenter 的“大脑”，承载业务逻辑、权限校验、数据模型解析、工作流引擎、生命周期管理等核心服务。它由多个进程组成，典型包括：TC Server（主业务进程）、Pool Manager（进程池管理）、Volume Manager（卷管理）、FSC（File Server Cache，文件服务缓存）、以及可选的 Web Tier（用于 Active Workspace 的 Web 应用）。应用服务器不存储持久化业务数据，而是将数据读写请求转发给数据库，将文件读写请求转发给文件服务器。

数据库层负责持久化存储所有结构化数据：物料、BOM、变更单、工作流状态、用户权限、元数据等。Teamcenter 支持 Oracle、SQL Server 等关系型数据库。数据库层的关键在于事务一致性、索引设计和连接池配置。数据库不存储物理文件本身，只存储文件的元数据和引用路径。

文件服务器层负责存储非结构化数据：CAD 模型、图纸、PDF、Office 文档、仿真结果等。Teamcenter 通过 Volume（卷）来组织文件存储，每个 Volume 对应一个文件系统路径。文件服务器通常由 FSC 进程管理，支持多卷、分布式部署和缓存加速。文件服务器与数据库之间通过元数据引用关联，实际文件内容不经过数据库。

各层之间的数据流向与交互关系

理解四层架构的关键，是区分两条独立的数据路径。第一条是结构化数据路径：客户端发起查询或保存请求，应用服务器解析业务逻辑后，通过 SQL/JDBC 访问数据库，数据库返回结果集，应用服务器再封装为业务对象返回客户端。这条路径上的数据量通常较小，但对延迟敏感，因为每次界面操作都可能触发多次数据库往返。

第二条是非结构化文件路径：当用户检入或检出 CAD 模型、图纸等文件时，客户端将文件流发送给应用服务器上的 FSC，FSC 根据 Volume Manager 的配置将文件写入指定的文件系统路径，同时将文件的元数据（文件名、大小、校验和、Volume 标识）写入数据库。检出时则相反：应用服务器从数据库读取元数据，定位到具体 Volume，再由 FSC 从文件系统读取文件流返回客户端。这条路径上的数据量大，对吞吐量和磁盘 I/O 更敏感。

典型部署拓扑

在实际企业环境中，四层架构可以有不同的物理部署方式，常见的有三种拓扑：

单机部署（All-in-One）：客户端、应用服务器、数据库、文件服务器全部安装在一台服务器上。这种拓扑仅适用于演示、培训或极小规模团队（如 5 人以下）。优点是安装简单、成本低；缺点是性能瓶颈明显、无高可用性、数据库与应用服务器争抢资源。

两层部署（应用+数据库分离）：应用服务器和文件服务器部署在一台机器，数据库部署在另一台专用数据库服务器。这是中小型企业（50～200 用户）最常见的拓扑。数据库服务器通常配置 RAID 10 和高内存，应用服务器配置多核 CPU 和大内存，文件服务器使用独立的高速磁盘阵列。这种拓扑在成本和性能之间取得了较好的平衡。

三层/多层部署（分布式）：应用服务器集群、数据库集群、文件服务器集群分别部署，客户端通过负载均衡访问应用服务器。大型企业（500 用户以上）通常采用这种拓扑。应用服务器可以水平扩展多个 TC Server 实例，通过 Pool Manager 统一调度；数据库采用 RAC 或 AlwaysOn 实现高可用；文件服务器通过多个 FSC 和 Volume 实现分布式存储和缓存加速。

部署拓扑中的关键参数与判断依据

在规划部署拓扑时，以下几个参数和判断依据值得重点关注：

• 并发用户数与 TC Server 实例数：每个 TC Server 实例通常可支撑 50～80 个并发活跃用户。若并发用户数为 200，建议至少部署 3 个 TC Server 实例，并配置 Pool Manager 进行进程池管理。
• 数据库连接池大小：每个 TC Server 实例默认使用约 20～50 个数据库连接。若部署 3 个实例，数据库需要支持至少 150 个并发连接。Oracle 的 processes 参数和 sessions 参数需要相应调整。
• 文件服务器吞吐量：若企业每天检入/检出 500 个大型装配体（单个 200MB～1GB），文件服务器需要至少 1Gbps 网络带宽和 RAID 5/10 磁盘阵列。FSC 缓存大小建议设置为文件服务器内存的 30%～50%。
• Volume 规划：建议按项目或部门划分 Volume，例如 Volume_Design、Volume_Manufacturing、Volume_Simulation。每个 Volume 对应独立的文件系统路径，便于容量管理和备份策略差异化。

从架构视角定位常见问题

掌握四层架构后，很多现场问题可以快速定位到具体层。例如：用户反馈“登录很慢”，可能涉及客户端网络、应用服务器认证服务、数据库用户表查询三个环节；用户反馈“打开装配体时卡死”，通常与文件服务器 I/O、FSC 缓存命中率、客户端内存有关；用户反馈“保存时提示超时”，则可能是数据库事务锁等待、应用服务器线程池耗尽或文件服务器写入延迟。架构图的价值不在于背诵四层名称，而在于形成“数据从哪来、经过谁、存到哪”的链路思维，从而在排障时逐层缩小范围。