PLM系统架构规划、优化方法及案例分析（上）

Jason_zhaojs 2016-09-29

展开全文

稳定的服务器平台及优秀的、可持续扩展的系统架构PLM系统顺利部署实施的前提，也为系统上线后实现高稳定性及高可用性的保障；本文以Siemens公司的TeamCenter系统为例，详细介绍了PLM项目实施中硬件规划及架构优化的相关方法，包括架构设计的依据，单层组件的资源分配计算方法，系统调优方案等，以及该方法在厦门金龙旅行车公司PLM系统实施中的实践案例。

1 引言

产品生命周期管理系统PLM（Product Life-cycle Management）自20世纪末提出以来，便迅速成为制造业关注的焦点。PLM结合电子商务技术与协同技术，将产品的开发流程与SCM、CRM、ERP等系统进行集成，将孤岛式流程管理转变为集成化的一体管理，实现从概念设计、产品设计、产品生产、产品维护到管理信息的全面数据管理。大型PLM系统一般是指具有高并发用户、参与部门多、日数据量大、系统逻辑复杂等特点的PLM系统。

作为贯穿整个企业研发、销售、生产、配套、物流、售后整套体系的企业级信息系统，对其稳定性及高性能的要求相对较高。如何在满足业务部门性能及稳定性需求的前提下，尽可能降低硬件设备的投入，避免一次性大量采购成本高昂的高档次服务器及存储？如何避免今后因扩容需求或硬件更换造成原有投入的资源浪费？

在PLM系统上线前期，是可以通过收集整理业务部门的需求，制定合理的系统架构，做系统资源分配测算等一系列方法，设计出一套投入较小，稳定性高，可持续扩展的系统架构规划方案。本文总结了作者在厦门金旅公司PLM项目及国内其他公司PLM系统实施过程中经验，提出了一个清晰合理的硬件规划操作方法，具有很强的可操作性。

2 需求分析

在做系统架构设计及硬件规划前，需同PLM用户及所在公司的IT部门充分沟通，形成系统性能需求分析文档。此文档将作为下一步骤：系统架构设计的重要设计输入；需求分析过程中，主要需了解的业务需求详见表1。

表1 需求分析内容项目

调研数据需按照规范化写法整理出需求分析报告文档，使用表格的方式体现业务数据增长。

3 系统架构说明、设计

目前世界上主流的PLM产品均具备较为优秀的可扩展式多层架构，以Siemens公司的TeamCenter产品（以下简称TC）为例，介绍其系统基础架构。

3.1 TC两层富客户端架构说明

TC两层客户端必须同卷服务器、数据库服务器部署在同一局域网内。在两层环境下，系统架构分为客户层与资源层两个部分：

1)客户层包含基于Java为核心的图形化应用程序、业务逻辑服务器（又称企业服务器）和文件客户端缓存组件（FCC，File Cache Client），这些组件均运行在客户端的计算机上。

2)资源层包含数据库与卷服务器（文件服务器）。数据库一般采用Oracle数据库作为核心；卷服务器一般运行在带有企业级存储的服务器上，要求有较大的容量与较快的文件寻址速度；

TC两层架构的客户端直接与数据库通讯，无需架设业务逻辑服务器和Web中间层服务器，对服务器资源的需求较小。一般用于小型PLM系统部署，如系统同时在线用户数不多（少于30人），数据量小于50G，业务模型较为稳定（一年3-10次小更改）的业务场景下，使用两层客户端可以快速进行PLM系统部署实施；两层架构的组件链接图表请参加图1。

图1 TeamCenter系统两层基础架构

但TC两层架构的缺点也非常明显：因为业务逻辑处理运行在客户端环境上，一旦遇到业务模型更新或业务逻辑变化，需要逐台客户端去更新业务模型和程序；并且因为客户端和资源层服务器必须在同一局域网内，对网络要求较高，且无法跨区域，跨防火墙进行访问；再次因为客户端上需要同时运行TC富客户端、处理业务逻辑、工程师一般还需要打开CAD类软件对设计进行修改和创建，对客户端计算机的硬件要求也较高。为了解决这些问题，TC系统还提供了一种更加灵活、扩展性强大的四层架构。

TeamCenter系统两层架构模块图表说明：

①系统数据库（可为 Oracle、SQL Server、IBM DB2等数据库引擎）

②系统文件服务（Teamcenter File Management System简称FMS，是TC系统基于http及https协议独有的文件传输服务）

③系统客户端（TC客户端是一个以Java为核心的图形化应用程序，包含三大模块：RichClient、FCC、tcserver。RichClient通过IIOP协议与处理业务逻辑的tcserver进程通讯，tcserver进程则通过TCP/IP与数据库进行数据传输，用于根据业务模型和业务逻辑处理客户端提交的请求，是客户端与数据库之间的桥梁；FCC即文件客户端缓存，通过http/https协议与FMS通讯，用于传输文件数据）

3.2 TC四层客户端架构说明

TC四层架构是在TC两层架构的基础上，在资源层与客户层之间，增加了应用层与Web层；同时将TC两层客户端上需要运行的tcserver进程迁移到应用层上，客户端与服务器之间的通讯更改为SOA总线形式，通过http或https协议进行。如此设计，在TC四层环境下的客户端，只需要一个提交和接收请求的基于Java的轻量化应用程序（UI同TC两层富客户端，但是所有占用CPU资源的业务逻辑处理迁移至企业层上完成）以及负责文件传输的FCC组件即可运行。TC四层架构的组件链接图表请参见图2。

图2 TeamCenter系统四层基础架构

TeamCenter系统四层架构模块说明：

①系统数据库（可为 Oracle、SQL Server、IBM DB2等数据库引擎）

②TC系统服务池进程，在企业服务器上一个用户对应一个独立的tcserver进程

③TC系统池服务管理器，用于管理企业服务器上启动的tcserver进程

④中间件服务器，负责客户端与tcserver之间的通讯

⑤卷服务器与系统文件服务（Teamcenter File Management System简称FMS，是TC系统基于http及https协议独有的文件传输服务）

⑥TC瘦客户端，基于网页形式的TC客户端，可以使用任何浏览器登陆进行TC日常使用操作

⑦TC四层客户端程序和FCC组件

3.2.1 应用层包含组件说明

在TC系统企业层服务器上，运行有一个TC服务池管理器。此管理器管理着tcserver进程的新建，关闭，读写状态切换。当用户登录时，池服务管理器会为用户启动对应的tcserver进程，用于提供业务逻辑服务，并会根据系统后台的设置，自动保持一定量的暖进程，用以处理短时间密集用户登录的场景。tcserver进程产生的临时文件数据（书签数据，运算输出数据，文本报告等）会通过Transient FSC（File Server Cache）组件传送给客户端的FCC组件。这里的FSC类似于资源层卷服务器上的FMS组件，它也提供了文件的读写及高速缓冲功能，唯一的区别是，它不作为文件的长久保存基地，仅是临时文件和高频率读写数据的缓存空间。

3.2.2 Web层包含组件说明

TC系统Web层一般来说是运行在基于J2EE的web中间件服务平台上，如常见的Oracle Weblogic，IBM WebSphere和免费的JBoss；中间件也可以运行在基于Windows Server.Net框架平台的IIS服务器上。

3.3 系统架构设计

3.3.1 系统架构的选择

在进行系统架构设计初期阶段，需要进行TC系统架构选择。考虑因素可以参考从本文第二章节介绍的需求分析报告；以下给出几种常见场景的分析说明供参考：

●如果企业PLM系统还处于初级阶段，并未走出研发部门，可以考虑仅采用两层架构。能有效的降低项目初期设备投入，降低部署和维护难度，使PLM项目快速部署上线。

●如果企业PLM系统已在多个部门使用，与研发相关的业务流程正在逐步向PLM系统迁移，建议采用四层客户端。四层客户端可以减少Consumer用户对同时在线许可证点数的要求，方便查询用户使用浏览器方式登录PLM系统进行数据查阅；同时，四层客户端也降低了业务模型部署难度，避免因频繁的业务模型变更造成处理逻辑不同步，数据出错的概率。

●如果企业PLM系统应用已较为深入，开始使用数字样机评审、项目管理、异地协同等模块，并且业务模型也相对稳定，就可以采用两层与四层架构并行部署；本地站点的CAD设计师，BOM工程师等工作流程稳定的角色，计算机配置较好，对速度要求高，即可使用两层客户端；而研发流程签核人员、配套、生成部门等流程查询用户，要求轻量化、可在多设备、多平台下运行的客户端，可以采用四层客户端；对异地站点人员，也必须使用四层客户端；

3.3.2 各层组件的架构分配

此处以Siemens TeamCenter系统的四层架构为例，对几种场景的架构场景优势劣势继续说明：

●资源层两组件分开放置：因为数据库组件和卷组件对于服务器CPU、内存、磁盘IO、磁盘容量、网络带宽等资源的需求差异非常大，且都是注重稳定性和安全的重要组件。同时，考虑到数据库的性能对PLM系统的响应速度影响巨大，升级扩容更换数据库和卷服务器必定带来系统停机，而且数据迁移都需要很长的时间等因素，故建议数据库和卷服务器组件两台独立的服务器放置。

●应用层和Web层在硬件资源运行的情况下，可以放置在同一台服务器上；因为应用层组件对CPU、内存IO、与数据库间网络带宽资源较为敏感，而web层中间件服务相对资源占用较少。所以在用户数不多，系统资源富裕的情况下，可以部署在同一台服务器上。即节省资源，又能减少tcserver和中间件服务通讯的网路延迟。

●对于大型PLM系统部署或需要高可用扩展的部署，必须将Web层和应用层放置在两台不同的服务器上。只有做好硬件上的分离，才可通过应用服务器或中间件服务的集群功能，避免单点故障。如果企业部署了云计算，分开部署Web层和应用层还能根据忙时和闲时，实现服务器资源动态调配，能有效的降低对电力的消耗，达到节能减排的环保目的。

●如果卷服务器单独部署在一台计算机上，可以将分发服务器和卷服务器整合。

3.3.3 系统架构高可用性、容灾的考虑

●PLM系统的高可用性包含中间层故障迁移、企业服务器层故障迁移的两个方面，图3给出了基于中间层组件提供的高可用性负载均衡及故障迁移的示例。

图3 基于中间件服务的高可用性扩展示例图

●通过中间件提供的服务代理器（tcproxy）可以将多个中间件服务和多个应用层池服务资源汇集，组成一个性能强大的服务器集群，并可以根据用户数的多少，随时扩展或减少服务器。同时，也提供了故障迁移的路径，如果其中的任意服务组件发生故障，均可以将用户迁移到其他服务器上继续运行，不会造成服务的中断。

●PLM系统的容灾处理主要体现在资源层的卷服务组件和数据库组件上，图4为IBM官方提供的一种异地容灾的解决方案。对于一般企业进行PLM系统部署的实际情况，卷和数据库均会运行在较为稳定的专业级存储设备上。而且企业级存储一般都会部署相应的备份设施，除非遇见无可抗拒的自然灾害，比较少发生数据丢失的情况。所以在PLM项目初级阶段和中期阶段，可以考虑将资金投入更能带来效益的项目实施经费。