1 引言
產(chǎn)品生命周期管理系統(tǒng)PLM（Product Life-cycle Management）自20世紀末提出以來，便迅速成為制造業(yè)關(guān)注的焦點。PLM結(jié)合電子商務(wù)技術(shù)與協(xié)同技術(shù)，將產(chǎn)品的開發(fā)流程與SCM、CRM、ERP等系統(tǒng)進行集成，將孤島式流程管理轉(zhuǎn)變?yōu)榧苫囊惑w管理，實現(xiàn)從概念設(shè)計、產(chǎn)品設(shè)計、產(chǎn)品生產(chǎn)、產(chǎn)品維護到管理信息的全面數(shù)據(jù)管理。大型PLM系統(tǒng)一般是指具有高并發(fā)用戶、參與部門多、日數(shù)據(jù)量大、系統(tǒng)邏輯復(fù)雜等特點的PLM系統(tǒng)。
作為貫穿整個企業(yè)研發(fā)、銷售、生產(chǎn)、配套、物流、售后整套體系的企業(yè)級信息系統(tǒng)，對其穩(wěn)定性及高性能的要求相對較高。如何在滿足業(yè)務(wù)部門性能及穩(wěn)定性需求的前提下，盡可能降低硬件設(shè)備的投入，避免一次性大量采購成本高昂的高檔次服務(wù)器及存儲？如何避免今后因擴容需求或硬件更換造成原有投入的資源浪費？
在PLM系統(tǒng)上線前期，是可以通過收集整理業(yè)務(wù)部門的需求，制定合理的系統(tǒng)架構(gòu)，做系統(tǒng)資源分配測算等一系列方法，設(shè)計出一套投入較小，穩(wěn)定性高，可持續(xù)擴展的系統(tǒng)架構(gòu)規(guī)劃方案。本文總結(jié)了作者在廈門金旅公司PLM項目及國內(nèi)其他公司PLM系統(tǒng)實施過程中經(jīng)驗，提出了一個清晰合理的硬件規(guī)劃操作方法，具有很強的可操作性。
2 需求分析
在做系統(tǒng)架構(gòu)設(shè)計及硬件規(guī)劃前，需同PLM用戶及所在公司的IT部門充分溝通，形成系統(tǒng)性能需求分析文檔。此文檔將作為下一步驟：系統(tǒng)架構(gòu)設(shè)計的重要設(shè)計輸入；需求分析過程中，主要需了解的業(yè)務(wù)需求詳見表1。
表1 需求分析內(nèi)容項目
調(diào)研數(shù)據(jù)需按照規(guī)范化寫法整理出需求分析報告文檔，使用表格的方式體現(xiàn)業(yè)務(wù)數(shù)據(jù)增長。
3 系統(tǒng)架構(gòu)說明、設(shè)計
目前世界上主流的PLM產(chǎn)品均具備較為優(yōu)秀的可擴展式多層架構(gòu)，以Siemens公司的TeamCenter產(chǎn)品（以下簡稱TC）為例，介紹其系統(tǒng)基礎(chǔ)架構(gòu)。
3.1 TC兩層富客戶端架構(gòu)說明
TC兩層客戶端必須同卷服務(wù)器、數(shù)據(jù)庫服務(wù)器部署在同一局域網(wǎng)內(nèi)。在兩層環(huán)境下，系統(tǒng)架構(gòu)分為客戶層與資源層兩個部分：
1)客戶層包含基于Java為核心的圖形化應(yīng)用程序、業(yè)務(wù)邏輯服務(wù)器（又稱企業(yè)服務(wù)器）和文件客戶端緩存組件（FCC，F(xiàn)ile Cache Client），這些組件均運行在客戶端的計算機上。
2)資源層包含數(shù)據(jù)庫與卷服務(wù)器（文件服務(wù)器）。數(shù)據(jù)庫一般采用Oracle數(shù)據(jù)庫作為核心；卷服務(wù)器一般運行在帶有企業(yè)級存儲的服務(wù)器上，要求有較大的容量與較快的文件尋址速度；
TC兩層架構(gòu)的客戶端直接與數(shù)據(jù)庫通訊，無需架設(shè)業(yè)務(wù)邏輯服務(wù)器和Web中間層服務(wù)器，對服務(wù)器資源的需求較小。一般用于小型PLM系統(tǒng)部署，如系統(tǒng)同時在線用戶數(shù)不多（少于30人），數(shù)據(jù)量小于50G，業(yè)務(wù)模型較為穩(wěn)定（一年3-10次小更改）的業(yè)務(wù)場景下，使用兩層客戶端可以快速進行PLM系統(tǒng)部署實施；兩層架構(gòu)的組件鏈接圖表請參加圖1。
圖1 TeamCenter系統(tǒng)兩層基礎(chǔ)架構(gòu)
但TC兩層架構(gòu)的缺點也非常明顯：因為業(yè)務(wù)邏輯處理運行在客戶端環(huán)境上，一旦遇到業(yè)務(wù)模型更新或業(yè)務(wù)邏輯變化，需要逐臺客戶端去更新業(yè)務(wù)模型和程序；并且因為客戶端和資源層服務(wù)器必須在同一局域網(wǎng)內(nèi)，對網(wǎng)絡(luò)要求較高，且無法跨區(qū)域，跨防火墻進行訪問；再次因為客戶端上需要同時運行TC富客戶端、處理業(yè)務(wù)邏輯、工程師一般還需要打開CAD類軟件對設(shè)計進行修改和創(chuàng)建，對客戶端計算機的硬件要求也較高。為了解決這些問題，TC系統(tǒng)還提供了一種更加靈活、擴展性強大的四層架構(gòu)。
TeamCenter系統(tǒng)兩層架構(gòu)模塊圖表說明：
①系統(tǒng)數(shù)據(jù)庫（可為 Oracle、SQL Server、IBM DB2等數(shù)據(jù)庫引擎）
②系統(tǒng)文件服務(wù)（Teamcenter File Management System簡稱FMS，是TC系統(tǒng)基于http及https協(xié)議獨有的文件傳輸服務(wù)）
③系統(tǒng)客戶端（TC客戶端是一個以Java為核心的圖形化應(yīng)用程序，包含三大模塊：RichClient、FCC、tcserver。RichClient通過IIOP協(xié)議與處理業(yè)務(wù)邏輯的tcserver進程通訊，tcserver進程則通過TCP/IP與數(shù)據(jù)庫進行數(shù)據(jù)傳輸，用于根據(jù)業(yè)務(wù)模型和業(yè)務(wù)邏輯處理客戶端提交的請求，是客戶端與數(shù)據(jù)庫之間的橋梁；FCC即文件客戶端緩存，通過http/https協(xié)議與FMS通訊，用于傳輸文件數(shù)據(jù)）
3.2 TC四層客戶端架構(gòu)說明
TC四層架構(gòu)是在TC兩層架構(gòu)的基礎(chǔ)上，在資源層與客戶層之間，增加了應(yīng)用層與Web層；同時將TC兩層客戶端上需要運行的tcserver進程遷移到應(yīng)用層上，客戶端與服務(wù)器之間的通訊更改為SOA總線形式，通過http或https協(xié)議進行。如此設(shè)計，在TC四層環(huán)境下的客戶端，只需要一個提交和接收請求的基于Java的輕量化應(yīng)用程序（UI同TC兩層富客戶端，但是所有占用CPU資源的業(yè)務(wù)邏輯處理遷移至企業(yè)層上完成）以及負責(zé)文件傳輸?shù)腇CC組件即可運行。TC四層架構(gòu)的組件鏈接圖表請參見圖2。
圖2 TeamCenter系統(tǒng)四層基礎(chǔ)架構(gòu)
TeamCenter系統(tǒng)四層架構(gòu)模塊說明：
①系統(tǒng)數(shù)據(jù)庫（可為 Oracle、SQL Server、IBM DB2等數(shù)據(jù)庫引擎）
②TC系統(tǒng)服務(wù)池進程，在企業(yè)服務(wù)器上一個用戶對應(yīng)一個獨立的tcserver進程
③TC系統(tǒng)池服務(wù)管理器，用于管理企業(yè)服務(wù)器上啟動的tcserver進程
④中間件服務(wù)器，負責(zé)客戶端與tcserver之間的通訊
⑤卷服務(wù)器與系統(tǒng)文件服務(wù)（Teamcenter File Management System簡稱FMS，是TC系統(tǒng)基于http及https協(xié)議獨有的文件傳輸服務(wù)）
⑥TC瘦客戶端，基于網(wǎng)頁形式的TC客戶端，可以使用任何瀏覽器登陸進行TC日常使用操作
⑦TC四層客戶端程序和FCC組件
3.2.1 應(yīng)用層包含組件說明
在TC系統(tǒng)企業(yè)層服務(wù)器上，運行有一個TC服務(wù)池管理器。此管理器管理著tcserver進程的新建，關(guān)閉，讀寫狀態(tài)切換。當用戶登錄時，池服務(wù)管理器會為用戶啟動對應(yīng)的tcserver進程，用于提供業(yè)務(wù)邏輯服務(wù)，并會根據(jù)系統(tǒng)后臺的設(shè)置，自動保持一定量的暖進程，用以處理短時間密集用戶登錄的場景。tcserver進程產(chǎn)生的臨時文件數(shù)據(jù)（書簽數(shù)據(jù)，運算輸出數(shù)據(jù)，文本報告等）會通過Transient FSC（File Server Cache）組件傳送給客戶端的FCC組件。這里的FSC類似于資源層卷服務(wù)器上的FMS組件，它也提供了文件的讀寫及高速緩沖功能，唯一的區(qū)別是，它不作為文件的長久保存基地，僅是臨時文件和高頻率讀寫數(shù)據(jù)的緩存空間。
3.2.2 Web層包含組件說明
TC系統(tǒng)Web層一般來說是運行在基于J2EE的web中間件服務(wù)平臺上，如常見的Oracle Weblogic，IBM WebSphere和免費的JBoss；中間件也可以運行在基于Windows Server.Net框架平臺的IIS服務(wù)器上。
3.3 系統(tǒng)架構(gòu)設(shè)計
3.3.1 系統(tǒng)架構(gòu)的選擇
在進行系統(tǒng)架構(gòu)設(shè)計初期階段，需要進行TC系統(tǒng)架構(gòu)選擇�？紤]因素可以參考從本文第二章節(jié)介紹的需求分析報告；以下給出幾種常見場景的分析說明供參考：
●如果企業(yè)PLM系統(tǒng)還處于初級階段，并未走出研發(fā)部門，可以考慮僅采用兩層架構(gòu)。能有效的降低項目初期設(shè)備投入，降低部署和維護難度，使PLM項目快速部署上線。
●如果企業(yè)PLM系統(tǒng)已在多個部門使用，與研發(fā)相關(guān)的業(yè)務(wù)流程正在逐步向PLM系統(tǒng)遷移，建議采用四層客戶端。四層客戶端可以減少Consumer用戶對同時在線許可證點數(shù)的要求，方便查詢用戶使用瀏覽器方式登錄PLM系統(tǒng)進行數(shù)據(jù)查閱；同時，四層客戶端也降低了業(yè)務(wù)模型部署難度，避免因頻繁的業(yè)務(wù)模型變更造成處理邏輯不同步，數(shù)據(jù)出錯的概率。
●如果企業(yè)PLM系統(tǒng)應(yīng)用已較為深入，開始使用數(shù)字樣機評審、項目管理、異地協(xié)同等模塊，并且業(yè)務(wù)模型也相對穩(wěn)定，就可以采用兩層與四層架構(gòu)并行部署；本地站點的CAD設(shè)計師，BOM工程師等工作流程穩(wěn)定的角色，計算機配置較好，對速度要求高，即可使用兩層客戶端；而研發(fā)流程簽核人員、配套、生成部門等流程查詢用戶，要求輕量化、可在多設(shè)備、多平臺下運行的客戶端，可以采用四層客戶端；對異地站點人員，也必須使用四層客戶端；
3.3.2 各層組件的架構(gòu)分配
此處以Siemens TeamCenter系統(tǒng)的四層架構(gòu)為例，對幾種場景的架構(gòu)場景優(yōu)勢劣勢繼續(xù)說明：
●資源層兩組件分開放置：因為數(shù)據(jù)庫組件和卷組件對于服務(wù)器CPU、內(nèi)存、磁盤IO、磁盤容量、網(wǎng)絡(luò)帶寬等資源的需求差異非常大，且都是注重穩(wěn)定性和安全的重要組件。同時，考慮到數(shù)據(jù)庫的性能對PLM系統(tǒng)的響應(yīng)速度影響巨大，升級擴容更換數(shù)據(jù)庫和卷服務(wù)器必定帶來系統(tǒng)停機，而且數(shù)據(jù)遷移都需要很長的時間等因素，故建議數(shù)據(jù)庫和卷服務(wù)器組件兩臺獨立的服務(wù)器放置。
●應(yīng)用層和Web層在硬件資源運行的情況下，可以放置在同一臺服務(wù)器上；因為應(yīng)用層組件對CPU、內(nèi)存IO、與數(shù)據(jù)庫間網(wǎng)絡(luò)帶寬資源較為敏感，而web層中間件服務(wù)相對資源占用較少。所以在用戶數(shù)不多，系統(tǒng)資源富裕的情況下，可以部署在同一臺服務(wù)器上。即節(jié)省資源，又能減少tcserver和中間件服務(wù)通訊的網(wǎng)路延遲。
●對于大型PLM系統(tǒng)部署或需要高可用擴展的部署，必須將Web層和應(yīng)用層放置在兩臺不同的服務(wù)器上。只有做好硬件上的分離，才可通過應(yīng)用服務(wù)器或中間件服務(wù)的集群功能，避免單點故障。如果企業(yè)部署了云計算，分開部署Web層和應(yīng)用層還能根據(jù)忙時和閑時，實現(xiàn)服務(wù)器資源動態(tài)調(diào)配，能有效的降低對電力的消耗，達到節(jié)能減排的環(huán)保目的。
●如果卷服務(wù)器單獨部署在一臺計算機上，可以將分發(fā)服務(wù)器和卷服務(wù)器整合。
3.3.3 系統(tǒng)架構(gòu)高可用性、容災(zāi)的考慮
●PLM系統(tǒng)的高可用性包含中間層故障遷移、企業(yè)服務(wù)器層故障遷移的兩個方面，圖3給出了基于中間層組件提供的高可用性負載均衡及故障遷移的示例。
圖3 基于中間件服務(wù)的高可用性擴展示例圖
●通過中間件提供的服務(wù)代理器（tcproxy）可以將多個中間件服務(wù)和多個應(yīng)用層池服務(wù)資源匯集，組成一個性能強大的服務(wù)器集群，并可以根據(jù)用戶數(shù)的多少，隨時擴展或減少服務(wù)器。同時，也提供了故障遷移的路徑，如果其中的任意服務(wù)組件發(fā)生故障，均可以將用戶遷移到其他服務(wù)器上繼續(xù)運行，不會造成服務(wù)的中斷。
●PLM系統(tǒng)的容災(zāi)處理主要體現(xiàn)在資源層的卷服務(wù)組件和數(shù)據(jù)庫組件上，圖4為IBM官方提供的一種異地容災(zāi)的解決方案。對于一般企業(yè)進行PLM系統(tǒng)部署的實際情況，卷和數(shù)據(jù)庫均會運行在較為穩(wěn)定的專業(yè)級存儲設(shè)備上。而且企業(yè)級存儲一般都會部署相應(yīng)的備份設(shè)施，除非遇見無可抗拒的自然災(zāi)害，比較少發(fā)生數(shù)據(jù)丟失的情況。所以在PLM項目初級階段和中期階段，可以考慮將資金投入更能帶來效益的項目實施經(jīng)費。
圖4 IBM官方異地災(zāi)難備份方案圖例
PLM系統(tǒng)架構(gòu)規(guī)劃、優(yōu)化方法及案例分析（中篇）
PLM系統(tǒng)架構(gòu)規(guī)劃、優(yōu)化方法及案例分析（下篇）
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標題：PLM系統(tǒng)架構(gòu)規(guī)劃、優(yōu)化方法及案例分析（上篇）
本文網(wǎng)址：http://www.oesoe.com/html/solutions/14019312186.html
相關(guān)文章
