基于微服務架構的一體化科研管理平臺設計與實現

趙 軍，陳子晗，高子航

(1.中國電子科技集團公司第五十四研究所，河北 石家莊 050081；2.中國科學技術大學 數學科學學院，安徽 合肥 230026；3.華中科技大學，湖北 武漢 430074)

0 引言

目前企業采用SOA架構開發的應用系統，如合同、項目、物資、質量和售后等，均為傳統單體架構模式構建，即每個系統的所有功能均為一個獨立應用，系統是最小的交付和部署單元[1]。系統間信息的傳遞與共享采用企業服務總線(ESB)實現，系統中業務流程的改變、功能的拓展，均需對原系統及接口進行程序改造并部署[1]。隨著企業應用系統數量、規模和復雜度的不斷增長，傳統開發模式在系統的開發、拓展、部署和維護等方面均面臨新的挑戰。

近幾年，國內外越來越多的企業將系統從傳統單體架構遷移到MSA，如國外的Netflix，Amazon，eBay，IBM Bluemix等，國內也有許多成功的實踐案例，如阿里巴巴開源的MSA Dubbo、京東的MSA JSF等[1]。目前，基于MSA構建系統應用已成為一種新選擇[2]。

前Netflix首席架構師Adrian Cockroft將微服務定義為細粒度的SOA[2]，核心是將傳統單體架構應用劃分成多個獨立服務，服務之間采用輕量級通信進行相互協作和調用。該架構具有快速開發、部署獨立、故障隔離以及技術多元化等特點，能縮短開發周期、快速交付應用[2]。

文獻[1-8]給出了應用架構的演變過程，各應用架構的優缺點、MSA的定義及實現原理，文獻[2-15]給出了MSA的優缺點及應用實踐，文獻[5-20]給出了MSA設計及編碼實現方式。

本文在一體化科研管理平臺的設計與實現中，對應用架構進行了對比、分析、研究，給出了采用MSA改造合同管理系統、項目管理系統的應用實踐。

1 微服務原理

1.1 MSA

微服務是近幾年出現的用于處理復雜應用的系統架構方法論，是SOA思想的一種實現，其核心理念在于，將復雜應用進行服務化切分，即把單一應用系統以獨立業務單元的形式拆分為多個服務，每個服務可選擇適合的技術實現特定業務功能，并以獨立的進程部署、運行。服務之間功能邊界清晰，采用REST/JSON等輕量級的通信機制相互溝通，相互配合實現完整應用[2]。

該架構旨在通過將功能分解到多個自治單元服務中以實現對復雜應用的快速開發，其本質是由一組可獨立交付的微服務業務單元構成的分布式系統[2]。

1.2 微服務架構特點

主要特點如下[3]：

① 復雜度可控：微服務將復雜的應用系統按業務功能分解為功能單一、易于管理的多個服務，系統的復雜度取決于服務的劃分；

② 架構靈活：對大型復雜應用，可將多個微服務采用負載均衡的分布式架構部署，最大程度地滿足用戶性能要求；

③ 技術多元化：每個微服務可根據業務功能特點及行業發展趨勢選擇適合的技術開發，使服務的開發和維護便捷、高效；

④ 功能易擴展：每個微服務功能單一，可獨立擴展、變更服務下的業務功能，而不影響其他微服務；

⑤ 獨立自治：每個微服務可獨立封裝業務邏輯，以獨立進程運行，故可單獨開發、測試、部署和維護。

1.3 MSA與SOA對比

SOA是一種粗粒度、松耦合的服務架構[1]，應用核心是業務邏輯，以服務封裝業務流程，采用中間件集中式總線，即ESB對每個業務流程實施控制、跟蹤、改進，并進行跨平臺的多應用系統間集成，ESB具有數據轉換、負載均衡、服務管理和服務監控等諸多功能，有效解決了應用系統的異構和復用問題，但其結構復雜，開發周期長，系統升級維護成本高，不利于業務功能的擴展和流程的變更[2]。

相比之下，MSA采用細粒度的服務，沒有結構復雜的ESB，它將大型、復雜的應用構建為一組相互配合的服務，每個服務業務單一、功能明確，服務間采用輕量級通信進行接口調用，服務開發測試與部署相互獨立，使系統具有良好的擴展性[5]。

SOA更傾向于是一種體系和指導思想，不是具體的實現方法。而MSA本質上可以說是面向服務應用級別的實現方式。

MSA與SOA在許多方面不同，主要區別如表1所示。

表1 SOA與MSA比較

指標SOAMSA 適用系統靜態、企業級大型應用快速迭代、快速交付應用服務粒度服務粒度大、功能較多 服務粒度細、功能單一架構模式集中式架構分布式架構通信機制SOAP,ESB等服務總線,重量級基于HTTP的RESTful、輕量級實現方式J2EE/EJB/WebServiceDocker/RESTful部署方式統一的平臺獨立進程、可不同平臺

2 系統設計與實現

2.1 業務現狀與問題

企業在科研管理領域已建成了合同、項目等系統，對合同收付款、項目執行等相關業務過程進行了有效管理，但系統建設之初，均基于某一業務部門內部的管理需求，隨著應用的深入，現有的系統在運行中暴露出以下問題：

① 僅對合同的基本信息及收付款情況進行登記，全流程、系統化的業務梳理不夠，相關部門需求覆蓋不全，缺乏有效的合同管控手段及風險預警能力；

② 收款業務與項目系統存在業務交叉、合同信息多源頭錄入等問題，致使合同信息不準確；

③ 收款計劃與項目執行計劃缺乏關聯，使合同收款節點狀態不能準確掌控；

④ 付款計劃與采購業務缺乏一體化管控手段，依靠人工跟蹤，工作量大、效率低下，準確性差；

⑤ 合同管理與財務支付缺乏有效集成，無法獲取合同的結算信息；

⑥ 收款、付款毫無關聯，無法做到準確的資金預測，導致合同履約過程中難以進行統一監督、跟蹤；

⑦ 缺乏往來單位收款付款全過程數據的統一管理，無法滿足各級領導對合同多維分析需要。

為解決上述問題，滿足企業不斷發展的業務需要及當前形勢對科研管理精細化的要求，迫切需要利用先進信息技術手段，對現有合同、項目系統進行功能擴展和改造，實現合同收付款計劃與業務執行的一體化管控，促進信息系統業務的連續性。

2.2 系統實現原理

一體化科研管理平臺，涉及合同、項目、采購、質量和財務等多個業務領域，實現原理如圖1所示，其核心思想是打破現有多個業務系統間的界限，重構系統功能，將目前各領域的業務系統進行補充、分解、重構成獨立的業務功能模塊，進一步構建一體化科研業務模型，以向用戶提供連續的跨領域的管理平臺，促進信息系統之間業務流程的連續性；使用戶對同一事項或任務的處理無需在不同系統或領域模塊間切換。

具體方式為：將企業現有合同管理、項目管理、采購管理、質量管理、財務管理和成本管理等多個單體應用系統的業務功能、流程進行梳理，補充、分解、重構現有功能，依據業務功能及業務之間的關聯關系程度構建一體化科研業務模型，如合同信息管理、合同收款管理、項目立項管理等多個功能模塊，采用MSA，將每個功能模塊微服務化，如合同服務、項目服務和采購服務等，從而為使用人員提供良好的用戶體驗。

圖1 一體化科研管理平臺工作原理

2.3 總體架構設計

一體化科研管理平臺采用多層架構進行設計，如圖2所示，分別為應用層、服務層、數據層、監控層和安全層。其中，應用層“以用戶為中心”，為用戶提供個性化功能服務，主要關注用戶體驗與業務功能；服務層是MSA的核心，采用服務化方式，通過“去中心化”的服務組合調用與重組來滿足不同用戶的功能需求；監控層、安全層對整個系統進行統一的運維和安全管理。

圖2 一體化科研管理平臺總體架構設計

API服務網關：一體化科研管理平臺的統一訪問入口，具有負載均衡、服務路由和請求過濾等功能，它對一體化科研管理平臺內部的所有服務進行了封裝，對外部公共的API與內部服務進行了隔離，有效保障了平臺的安全性。

服務層：依據服務的作用又分為基礎平臺微服務、業務共享微服務和定制微服務。基礎平臺微服務如元數據管理微服務、工作流引擎微服務等為其他業務服務提供技術支撐；共享業務微服務對共性業務服務進行抽取，為其他業務提供服務；定制微服務實現特定領域功能。

數據層：通過數據總線為服務層應用提供數據訪問接口。

2.4 微服務設計

基于MSA的一體化科研管理平臺依據服務的性質和作用將服務分為3大類：基礎平臺微服務、業務共享微服務和業務定制微服務，每類下又包含若干微服務，如表2所示。其中，與業務相關的微服務劃分一方面依據業務功能特點及業務之間的關系，另一方面跟開發所需技術相關，同一業務實現技術不同將被劃分為不同的服務。

在一體化科研管理平臺的合同系統、項目系統的微服務改造中，將項目任命、項目計劃等作為業務共享微服務，為合同信息管理、合同收款計劃提供服務；而將只與自身業務相關的功能，如合同信息管理作為業務定制微服務。

表2 一體化科研管理平臺微服務列表

服務類型微服務名稱基礎平臺微服務元數據管理微服務工作流引擎微服務報表工具微服務備份管理微服務權限管理微服務業務共享微服務項目立項微服務項目任命微服務項目計劃微服務項目監控微服務業務定制微服務合同信息管理微服務合同收款管理微服務收款任務管理微服務撥款管理微服務項目變更微服務……

2.5 系統開發實現技術

一體化科研管理平臺開發采用以下關鍵技術：

① 基于Spring Boot技術：采用Spring Cloud為本系統的微服務技術應用框架。具體技術是使用Eureka作為服務的注冊與發現中心，使用Ribbon實現客戶端負載均衡，使用Zuul實現智能網關、動態路由，對外提供RESR API，使用Hystrix服務斷路器進行服務保護等，Spring Cloudk框架既考慮Web應用，也考慮今后手機APP應用。

② 服務調用：采用基于AMQP協議的開源消息中間件RabbitMQ進行服務間的異步調用，降低服務間的耦合度。

③ 服務監控：使用Zipkin進行服務鏈路的調用監控，利用Kibana對運維數據進行分析并提供可視化展示。

④ 安全防護：采用基于云平臺的安全措施進行安全防護。

⑤ 服務部署：采用Docker虛擬化技術進行自動化部署。

微服務開發主要步驟如下：

① 創建Spring Cloud 配置服務器：首先創建項目，激活配置服務器，配置訪問路徑，然后對該項目下的所有服務實施配置管理。

② 微服務注冊：使用Eureka作為客戶端的連接組件，作為注冊中心，為微服務提供注冊服務。

③ 微服務發現與應用：通過添加@EnableDicoveryClient注解，使微服務啟動時能自動注冊至注冊中心。

④ 配置斷路器：使微服務啟動后依賴于注冊中心，對微服務實施保護。

⑤ 配置前端HTML頁面：使用AngularJS技術，將業務數據模型綁定到頁面變量，為用戶提供Web頁面訪問。

⑥ 微服務測試。

⑦ 微服務部署運行。

3 應用結果與分析

通過將MSA應用于一體化科研管理平臺的合同系統、項目系統改造中，將大而復雜的一體化科研管控問題分解為相對獨立的合同管理、項目管理等問題，使用一組小服務來開發單個復雜應用，在企業的實際應用中效果良好，達到預期目標，開發周期由原先預計的6個月，縮短為4.5個月，開發效率提高25%。實踐證明，采用MSA，在業務需求漸清晰的情況下，可實現業務功能快速迭代及敏捷開發。傳統開發方式與采用微服務架構開發方式的比較如表3所示。

表3 2種開發方式開發周期對比 天

4 結束語

針對企業目前收款合同與項目執行的業務現狀，在一體化科研管理平臺的設計與實現中，引入了MSA，通過對傳統單體架構的合同管理系統與項目管理系統實施微服務改造，實現了收款合同、項目執行的微服務化，促進了信息系統業務流程的連續性，滿足了企業收款計劃與項目執行計劃一體化管控需要。目前，系統已上線運行，實踐證明，采用微服務改造后，可快速應對企業組織及管理變化帶來的業務調整及需求變化，提高了一體化科研管理平臺的適用性和擴展性，對后續其他系統的功能擴展以及重構提供了重要的指導意義。

微服務平臺建設是個不斷迭代完善的過程，在后續系統建設中，一方面要優化和補充基礎平臺微服務功能，如完善調用服務，除監控服務運行狀態外，還要對服務的安全性、日志和流量控制等方面進行管理，以確保服務的高可靠性；另一方面，要結合業務需求不斷抽取、沉淀共享業務微服務，使之為更多的定制業務提供服務。另外，隨著后續一體化科研管理平臺中質量、采購等系統的不斷改造，微服務數量會逐漸增加，服務的運維工作會變得十分繁重，還要考慮采取輕量級Docker容器技術進行自動化部署。