基于微服務架構的鐵路科研協作平臺研究與設計

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

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

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

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

本文從微服務架構與傳統單體式架構對比分析出發，通過對鐵路科研協作進行全面、立體、多層級的需求分析，設計平臺的總體架構和技術架構，為鐵路科研協作平臺的研究開發提供支撐。

1 傳統單體式架構與微服務架構方式對比

1.1 傳統單體式架構

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

1.2 微服務架構

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

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

2 平臺需求分析

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

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

2.1 平臺門戶

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

（1）決策人員：具有系統所有功能模塊的操作權限；

（2）科研管理人員：具有項目管理及發起協作權限；

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

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

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

2.2 項目管理

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

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

（2）項目進度控制：跟蹤科研計劃進度，從內容及經費等方面對項目合同立項、中期檢查、驗收結題進行協作控制；

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

2.3 協作管理

協作管理模塊的需求包括：

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

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

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

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

（5）根據權限管理文檔、共享資料；

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

2.4 經費管理

經費管理模塊的需求包括：

（1）項目經費預算的申報及審批；

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

（3）經費計算器自動核算金額，根據不同預算標準制定經費內各項預算；

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

2.5 人才管理

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

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

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

（3）科研機構與科研團隊信息庫的建立與管理。

2.6 成果與知識管理

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

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

2.7 決策分析

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

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

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

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

2.8 移動辦公

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

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

3 平臺設計

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

3.1 微服務劃分

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

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

平臺由實現不同功能的微服務組成，將各類微服務都定義成獨立的服務接口，相比于原來單體結構難以維護的情況，現在每個微服務只關注單一的業務功能。

3.2 平臺總體架構

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

3.3 技術架構

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

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

（2）平臺服務層：通過開發對應的服務實現具體業務的應用，服務分為項目管理所需的服務和用于保證數據及通信基礎[10]的為平臺提供支撐的服務。

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

（4）展示層：平臺前端采用MVVM 模式實現頁面展示，使用提供視圖和視圖模型雙向數據綁定的基礎架構，將前端視圖與后端數據進行分離，實現數據與視圖解耦的目的。

3.4 功能架構

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

4 結束語

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