陳 亮，郭洋洋，趙澤乾，劉 磊、王騰霄

（1.中國鐵道科學研究院集團有限公司 鐵道科學技術(shù)研究發(fā)展中心，北京 100081；2.中國鐵道科學研究院集團有限公司 電子技術(shù)研究所，北京 100081）

近年來，我國鐵路科技迅猛發(fā)展，技術(shù)創(chuàng)新逐漸成為推動鐵路發(fā)展的源動力。為了解決鐵路建設(shè)中各項工程的重大問題，跨學科或產(chǎn)學研結(jié)合的科研項目無論在數(shù)量上還是在研發(fā)經(jīng)費上都呈逐年增多的趨勢。鐵路科研工作越來越多地顯現(xiàn)系統(tǒng)綜合性、復雜性和跨學科性的發(fā)展趨勢。因此，通過研究多學科、多專業(yè)、多人員交叉的復雜系統(tǒng)需求，開發(fā)一套鐵路科研協(xié)作平臺對提高鐵路科研項目的研發(fā)效率與質(zhì)量具有重要意義。

現(xiàn)階段的科研信息化平臺多以項目牽頭或項目甲方的需求為出發(fā)點進行開發(fā)[1]，而考慮所有項目參與方需求的研究較少。同時，眾多信息化平臺中，采用傳統(tǒng)單體式結(jié)構(gòu)的較多，采用微服務架構(gòu)的較少[2]。

本文從微服務架構(gòu)與傳統(tǒng)單體式架構(gòu)對比分析出發(fā)，通過對鐵路科研協(xié)作進行全面、立體、多層級的需求分析，設(shè)計平臺的總體架構(gòu)和技術(shù)架構(gòu)，為鐵路科研協(xié)作平臺的研究開發(fā)提供支撐。

1 傳統(tǒng)單體式架構(gòu)與微服務架構(gòu)方式對比

1.1 傳統(tǒng)單體式架構(gòu)

基于傳統(tǒng)單體式架構(gòu)的信息系統(tǒng)僅以實現(xiàn)業(yè)務功能為目的，將所有功能集中在同一工程內(nèi)部，業(yè)務邏輯耦合緊密。在鐵路科研協(xié)作平臺中，鐵路的各個專業(yè)交叉多且功能眾多，單體式架構(gòu)的缺點較為明顯[3]，包括：（1）增加新的協(xié)作需求時，平臺不能及時擴展；（2）需求變更時，難以快速在原有復雜的平臺基礎(chǔ)上進行更新；（3）可靠性較低，受到邏輯耦合緊密的影響，可能會由于一個模塊的影響導致整個平臺宕機；（4）新接手的成員對于原有復雜系統(tǒng)的理解、上手較慢，造成維護成本較高。綜上，在新的需求變更驅(qū)動下，一個小而簡單的應用都會慢慢變得臃腫且龐大[4]。

1.2 微服務架構(gòu)

微服務架構(gòu)是目前比較流行的軟件架構(gòu)風格，是一種將軟件的應用設(shè)計為可單獨部署的服務套件的特定軟件架構(gòu)方式。該架構(gòu)將復雜的單體應用分解為小而專一、耦合度低、高度自治的服務。每個服務集中于各自的應用業(yè)務確定邊界，可以進行獨立的開發(fā)、測試以及部署，實現(xiàn)按需配置擴展[5]，便于后續(xù)的系統(tǒng)運營與維護。每個服務都運行于獨立進程中，通過輕量級通信機制，可以避開開發(fā)語言的限制[6]，實現(xiàn)相互協(xié)同工作，完整系統(tǒng)功能。

鐵路科研協(xié)作平臺內(nèi)模塊眾多，應基于微服務架構(gòu)方式，按照高內(nèi)聚、低耦合的思路進行開發(fā)，否則越到后期維護以及二次開發(fā)時，成本代價越大，同時也給系統(tǒng)的穩(wěn)定性帶來一定風險。

2 平臺需求分析

鐵路科研協(xié)作平臺是鐵路科研項目綜合信息化的重要手段。從服務項目管理團隊、科研團隊的角度出發(fā)，建立接口豐富、功能便捷的平臺，將項目文檔、經(jīng)費、人才、知識、成果交流等隨項目一同產(chǎn)生及必需的數(shù)據(jù)統(tǒng)一錄入，避免科研信息孤島，實現(xiàn)項目立項、檢查、變更、驗收全過程協(xié)作的目的[7]。

鐵路科研協(xié)作平臺為科研管理績效考評和制定科學決策提供依據(jù)，促進科研工作的開展和科技成果的轉(zhuǎn)化與推廣，滿足鐵路建設(shè)的科研協(xié)作需求。平臺功能需求主要包括門戶管理、項目管理、協(xié)作管理、經(jīng)費管理、人才管理、成果與知識管理、決策分析、移動辦公[8]。

2.1 平臺門戶

針對不同角色的人員，應分配不同的門戶及其對應的權(quán)限，具體角色包括：決策人員、科研管理人員、項目負責人、項目成員、項目需求人員、游客。平臺應針對不同角色配備不同的權(quán)限，配置好的權(quán)限可以根據(jù)角色批量分配給用戶。

（1）決策人員：具有系統(tǒng)所有功能模塊的操作權(quán)限；

（2）科研管理人員：具有項目管理及發(fā)起協(xié)作權(quán)限；

（3）項目負責人：具有項目組內(nèi)分工、委任權(quán)限，并對委任工作進行相應評價；

（4）項目需求人員：提出實際需求、根據(jù)科研管理人員分配的權(quán)限，查看已完成項目的成果情況；

（5）游客：查看項目公告欄、公開通知等內(nèi)容。

2.2 項目管理

項目管理模塊的需求包括：

（1）立項：由項目牽頭單位發(fā)起立項申請，項目各參與方共同協(xié)作立項，項目團隊成員可以查看立項申請進度、審批情況等內(nèi)容；

（2）項目進度控制：跟蹤科研計劃進度，從內(nèi)容及經(jīng)費等方面對項目合同立項、中期檢查、驗收結(jié)題進行協(xié)作控制；

（3）合同變更：合同變更的申報審核、補充協(xié)議的簽訂以及變更合同的瀏覽等功能。

2.3 協(xié)作管理

協(xié)作管理模塊的需求包括：

（1）撰文協(xié)作，多人協(xié)同編輯同一份文檔文件，并實現(xiàn)修訂、批注、評論等功能；

（2）實現(xiàn)團隊內(nèi)部任務分解功能，負責人向團隊進行任務指派、任務評價功能；

（3）通過手機App 及短信方式，發(fā)送任務提醒功能；

（4）團隊、個人的日歷日程共享功能；

（5）根據(jù)權(quán)限管理文檔、共享資料；

（6）項目協(xié)同進度展示功能，采用如甘特圖等圖表方式。

2.4 經(jīng)費管理

經(jīng)費管理模塊的需求包括：

（1）項目經(jīng)費預算的申報及審批；

（2）配置不同級別項目的經(jīng)費模板，支持按照自定義預算標準生成預算申請單；

（3）經(jīng)費計算器自動核算金額，根據(jù)不同預算標準制定經(jīng)費內(nèi)各項預算；

（4）在項目執(zhí)行期，通過對比經(jīng)費的預算與實際使用情況，向用戶提供經(jīng)費使用情況預警。

2.5 人才管理

人才管理模塊的需求包括：

（1）科研人員履歷庫的建立，支持科研機構(gòu)及科研人員的注冊，對科研人員的職稱及履歷進行管理；

（2）對科研信息庫中的專家整體情況以及某一具體科研人員的詳細信息進行查看、編輯、審核、履歷管理，實現(xiàn)科研專家?guī)靸?、篩選與評價功能；

（3）科研機構(gòu)與科研團隊信息庫的建立與管理。

2.6 成果與知識管理

成果與知識管理模塊的需求包括：（1）由科研團隊或個人完成平臺內(nèi)成果申請?zhí)釄?；?）成果評審與鑒定，科研人員上傳材料提交至平臺，由相關(guān)科研管理部門組織專家進行鑒定、評審流程，專家組根據(jù)驗收材料給出鑒定意見及結(jié)果；

（3）成果轉(zhuǎn)化數(shù)據(jù)展示，平臺可通過圖形、圖表的形式，將成果應用從取得情況、應用情況以及能夠帶來的經(jīng)濟效益等多維度進行全方位展示。

2.7 決策分析

決策分析模塊的需求包括：

（1）能夠根據(jù)科研項目的不同單位、類型、來源進行分析，也可以對項目任務、成果鑒定、獎勵、知識歸檔使用等進行綜合分析；

（2）對科研機構(gòu)、科研人才的科研項目完成能力進行綜合分析、評價；

（3）在對科研費用的預算和使用進度實時跟蹤的基礎(chǔ)上，對科研項目進行輔助決策。

2.8 移動辦公

（1）通過手機App 及時向用戶和群組推送系統(tǒng)通知等消息；

（2）用戶可通過手機App 訪問系統(tǒng)平臺，進行上述各管理模塊的應用。

3 平臺設(shè)計

結(jié)合平臺的需求分析，利用微服務架構(gòu)組件化、獨立部署、復雜度低、技術(shù)多元化、維護風險低等優(yōu)勢，對科研協(xié)作平臺的總體架構(gòu)、技術(shù)架構(gòu)及功能架構(gòu)進行分析設(shè)計。

3.1 微服務劃分

根據(jù)平臺建設(shè)的實際情況，將微服務分為共享微服務和定制微服務2 類。共享微服務又分為基礎(chǔ)微服務和業(yè)務微服務。定制微服務是共享微服務在無法滿足實際業(yè)務需求情況下的擴展。平臺的部分微服務劃分如表1 所示。

表1 平臺部分微服務劃分列表

平臺由實現(xiàn)不同功能的微服務組成，將各類微服務都定義成獨立的服務接口，相比于原來單體結(jié)構(gòu)難以維護的情況，現(xiàn)在每個微服務只關(guān)注單一的業(yè)務功能。

3.2 平臺總體架構(gòu)

鐵路科研協(xié)作平臺是鐵路信息化的重要組成部分。該平臺從服務于科研立項單位、科研牽頭單位、項目管理團隊的角度出發(fā)，將科研項目、經(jīng)費、人才、知識、成果等數(shù)據(jù)進行統(tǒng)一錄入，建立科研項目檔案，實現(xiàn)科研項目從立項、檢查、變更、驗收，到項目知識成果轉(zhuǎn)化等的項目全生命周期服務。同時，平臺引入科研項目所需的外部的人、財、物等系統(tǒng)的數(shù)據(jù)，實現(xiàn)科研協(xié)作的完整閉環(huán)。平臺的總體架構(gòu)如圖1 所示。

3.3 技術(shù)架構(gòu)

平臺采用前后端完全分離的微服務技術(shù)架構(gòu)，使用Spring Cloud 作為微服務應用框架，基于Spring Boot 進行開發(fā)，為PC 端及移動端提供接口服務。平臺前端使用Vue.js 主流MVVM（Model-View-ViewModel）模式框架，實現(xiàn)頁面的展示[9]，如圖2所示。

（1）資源層：負責數(shù)據(jù)長時間的存儲，主要包含Oracle 數(shù)據(jù)庫、Redis 分布式緩存、文件存儲等。

（2）平臺服務層：通過開發(fā)對應的服務實現(xiàn)具體業(yè)務的應用，服務分為項目管理所需的服務和用于保證數(shù)據(jù)及通信基礎(chǔ)[10]的為平臺提供支撐的服務。

（3）中間件：Web 對每個服務的訪問，都通過API 網(wǎng)關(guān)層傳遞數(shù)據(jù)來實現(xiàn)。平臺采用API Zuul 網(wǎng)關(guān)完成所有服務接口的統(tǒng)一，采用Shiro+JWT 方式完成身份認證的權(quán)限管理功能，使用Nginx 集群[11]、網(wǎng)關(guān)集群Zuul 以及Ribbon 負載均衡等中間件提供穩(wěn)定的集群網(wǎng)絡服務[12-14]。

（4）展示層：平臺前端采用MVVM 模式實現(xiàn)頁面展示，使用提供視圖和視圖模型雙向數(shù)據(jù)綁定的基礎(chǔ)架構(gòu)，將前端視圖與后端數(shù)據(jù)進行分離，實現(xiàn)數(shù)據(jù)與視圖解耦的目的。

3.4 功能架構(gòu)

平臺由基礎(chǔ)服務和業(yè)務服務構(gòu)成，每個微服務都是一個獨立組件，可根據(jù)實際業(yè)務情況進行服務配置，構(gòu)成特定的業(yè)務子系統(tǒng)應用。當實際業(yè)務與基礎(chǔ)服務和業(yè)務服務不一致時，通過業(yè)務定制微服務的方式，進行個性化定制開發(fā)，來滿足實際需要。平臺功能架構(gòu)如圖3 所示。

4 結(jié)束語

科研協(xié)作在現(xiàn)代鐵路科研工作中發(fā)揮著越來越重要的作用，是鐵路科研工作的發(fā)展趨勢。本文通過比較傳統(tǒng)單體架構(gòu)與微服務架構(gòu)的特點，采用微服務架構(gòu)設(shè)計搭建了鐵路科研協(xié)作平臺。該平臺可以靈活應對科研協(xié)作工作的復雜性，快速開發(fā)應用以滿足科研工作中的新需求，更好地推進不同學科、不同分工的科研人員及組織間的相互配合與協(xié)作，為高標準、高質(zhì)量完成鐵路科研工作奠定基礎(chǔ)。