趙 軍，陳子晗，高子航

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

0 引言

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

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

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

文獻[1-8]給出了應(yīng)用架構(gòu)的演變過程，各應(yīng)用架構(gòu)的優(yōu)缺點、MSA的定義及實現(xiàn)原理，文獻[2-15]給出了MSA的優(yōu)缺點及應(yīng)用實踐，文獻[5-20]給出了MSA設(shè)計及編碼實現(xiàn)方式。

本文在一體化科研管理平臺的設(shè)計與實現(xiàn)中，對應(yīng)用架構(gòu)進行了對比、分析、研究，給出了采用MSA改造合同管理系統(tǒng)、項目管理系統(tǒng)的應(yīng)用實踐。

1 微服務(wù)原理

1.1 MSA

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

該架構(gòu)旨在通過將功能分解到多個自治單元服務(wù)中以實現(xiàn)對復(fù)雜應(yīng)用的快速開發(fā)，其本質(zhì)是由一組可獨立交付的微服務(wù)業(yè)務(wù)單元構(gòu)成的分布式系統(tǒng)[2]。

1.2 微服務(wù)架構(gòu)特點

主要特點如下[3]：

① 復(fù)雜度可控：微服務(wù)將復(fù)雜的應(yīng)用系統(tǒng)按業(yè)務(wù)功能分解為功能單一、易于管理的多個服務(wù)，系統(tǒng)的復(fù)雜度取決于服務(wù)的劃分；

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

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

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

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

1.3 MSA與SOA對比

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

相比之下，MSA采用細粒度的服務(wù)，沒有結(jié)構(gòu)復(fù)雜的ESB，它將大型、復(fù)雜的應(yīng)用構(gòu)建為一組相互配合的服務(wù)，每個服務(wù)業(yè)務(wù)單一、功能明確，服務(wù)間采用輕量級通信進行接口調(diào)用，服務(wù)開發(fā)測試與部署相互獨立，使系統(tǒng)具有良好的擴展性[5]。

SOA更傾向于是一種體系和指導(dǎo)思想，不是具體的實現(xiàn)方法。而MSA本質(zhì)上可以說是面向服務(wù)應(yīng)用級別的實現(xiàn)方式。

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

表1 SOA與MSA比較

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

2 系統(tǒng)設(shè)計與實現(xiàn)

2.1 業(yè)務(wù)現(xiàn)狀與問題

企業(yè)在科研管理領(lǐng)域已建成了合同、項目等系統(tǒng)，對合同收付款、項目執(zhí)行等相關(guān)業(yè)務(wù)過程進行了有效管理，但系統(tǒng)建設(shè)之初，均基于某一業(yè)務(wù)部門內(nèi)部的管理需求，隨著應(yīng)用的深入，現(xiàn)有的系統(tǒng)在運行中暴露出以下問題：

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

② 收款業(yè)務(wù)與項目系統(tǒng)存在業(yè)務(wù)交叉、合同信息多源頭錄入等問題，致使合同信息不準確；

③ 收款計劃與項目執(zhí)行計劃缺乏關(guān)聯(lián)，使合同收款節(jié)點狀態(tài)不能準確掌控；

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

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

⑥ 收款、付款毫無關(guān)聯(lián)，無法做到準確的資金預(yù)測，導(dǎo)致合同履約過程中難以進行統(tǒng)一監(jiān)督、跟蹤；

⑦ 缺乏往來單位收款付款全過程數(shù)據(jù)的統(tǒng)一管理，無法滿足各級領(lǐng)導(dǎo)對合同多維分析需要。

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

2.2 系統(tǒng)實現(xiàn)原理

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

具體方式為：將企業(yè)現(xiàn)有合同管理、項目管理、采購管理、質(zhì)量管理、財務(wù)管理和成本管理等多個單體應(yīng)用系統(tǒng)的業(yè)務(wù)功能、流程進行梳理，補充、分解、重構(gòu)現(xiàn)有功能，依據(jù)業(yè)務(wù)功能及業(yè)務(wù)之間的關(guān)聯(lián)關(guān)系程度構(gòu)建一體化科研業(yè)務(wù)模型，如合同信息管理、合同收款管理、項目立項管理等多個功能模塊，采用MSA，將每個功能模塊微服務(wù)化，如合同服務(wù)、項目服務(wù)和采購服務(wù)等，從而為使用人員提供良好的用戶體驗。

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

2.3 總體架構(gòu)設(shè)計

一體化科研管理平臺采用多層架構(gòu)進行設(shè)計，如圖2所示，分別為應(yīng)用層、服務(wù)層、數(shù)據(jù)層、監(jiān)控層和安全層。其中，應(yīng)用層“以用戶為中心”，為用戶提供個性化功能服務(wù)，主要關(guān)注用戶體驗與業(yè)務(wù)功能；服務(wù)層是MSA的核心，采用服務(wù)化方式，通過“去中心化”的服務(wù)組合調(diào)用與重組來滿足不同用戶的功能需求；監(jiān)控層、安全層對整個系統(tǒng)進行統(tǒng)一的運維和安全管理。

圖2 一體化科研管理平臺總體架構(gòu)設(shè)計

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

服務(wù)層：依據(jù)服務(wù)的作用又分為基礎(chǔ)平臺微服務(wù)、業(yè)務(wù)共享微服務(wù)和定制微服務(wù)。基礎(chǔ)平臺微服務(wù)如元數(shù)據(jù)管理微服務(wù)、工作流引擎微服務(wù)等為其他業(yè)務(wù)服務(wù)提供技術(shù)支撐；共享業(yè)務(wù)微服務(wù)對共性業(yè)務(wù)服務(wù)進行抽取，為其他業(yè)務(wù)提供服務(wù)；定制微服務(wù)實現(xiàn)特定領(lǐng)域功能。

數(shù)據(jù)層：通過數(shù)據(jù)總線為服務(wù)層應(yīng)用提供數(shù)據(jù)訪問接口。

2.4 微服務(wù)設(shè)計

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

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

表2 一體化科研管理平臺微服務(wù)列表

服務(wù)類型微服務(wù)名稱基礎(chǔ)平臺微服務(wù)元數(shù)據(jù)管理微服務(wù)工作流引擎微服務(wù)報表工具微服務(wù)備份管理微服務(wù)權(quán)限管理微服務(wù)業(yè)務(wù)共享微服務(wù)項目立項微服務(wù)項目任命微服務(wù)項目計劃微服務(wù)項目監(jiān)控微服務(wù)業(yè)務(wù)定制微服務(wù)合同信息管理微服務(wù)合同收款管理微服務(wù)收款任務(wù)管理微服務(wù)撥款管理微服務(wù)項目變更微服務(wù)……

2.5 系統(tǒng)開發(fā)實現(xiàn)技術(shù)

一體化科研管理平臺開發(fā)采用以下關(guān)鍵技術(shù)：

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

② 服務(wù)調(diào)用：采用基于AMQP協(xié)議的開源消息中間件RabbitMQ進行服務(wù)間的異步調(diào)用，降低服務(wù)間的耦合度。

③ 服務(wù)監(jiān)控：使用Zipkin進行服務(wù)鏈路的調(diào)用監(jiān)控，利用Kibana對運維數(shù)據(jù)進行分析并提供可視化展示。

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

⑤ 服務(wù)部署：采用Docker虛擬化技術(shù)進行自動化部署。

微服務(wù)開發(fā)主要步驟如下：

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

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

③ 微服務(wù)發(fā)現(xiàn)與應(yīng)用：通過添加@EnableDicoveryClient注解，使微服務(wù)啟動時能自動注冊至注冊中心。

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

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

⑥ 微服務(wù)測試。

⑦ 微服務(wù)部署運行。

3 應(yīng)用結(jié)果與分析

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

表3 2種開發(fā)方式開發(fā)周期對比 天

4 結(jié)束語

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

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