姚振 王萍 宮政 劉濤 唐軼軒
摘 要: 針對電力公司管理信息系統(tǒng)所存在的可拓展性、可維護(hù)性較差以及在敏捷開發(fā)和快速部署方面的劣勢,提出采用Spring Cloud平臺、微服務(wù)架構(gòu)和輕量級容器技術(shù)相結(jié)合的以提升電力信息系統(tǒng)的持續(xù)集成和擴(kuò)展能力的解決方案。其中微服務(wù)架構(gòu)是一種具有靈活的技術(shù)選擇、可獨(dú)立地按需擴(kuò)展和高可用性的先進(jìn)架構(gòu);Spring Cloud作為開源技術(shù)架構(gòu)則為信息系統(tǒng)的微服務(wù)化提供全面的技術(shù)支持;而Dockers所代表的容器技術(shù)則為微服務(wù)架構(gòu)提供了一個(gè)獨(dú)立且不受干擾的部署環(huán)境。試驗(yàn)表明,該解決方案具有計(jì)算效率好和運(yùn)行穩(wěn)定的優(yōu)點(diǎn)。
關(guān)鍵詞: 微服務(wù); 管理信息系統(tǒng); Spring Cloud; Dockers
中圖分類號: TP 315 ? ? ?文獻(xiàn)標(biāo)志碼: A
Abstract: In view of the scalability, poor maintainability and disadvantages of agile development and rapid deployment of power company management information systems, this paper tries to improve the combination of Spring Cloud platform, micro service architecture and lightweight container technology. A solution for continuous integration and expansion capabilities of power information systems is proposed. The microservices architecture is an advanced architecture with flexible technology choices, independent on-demand scalability and high availability; Spring Cloud as an open source technology architecture provides comprehensive technical support for micro-services of information systems, and represented by Dockers the container technology provides an independent and undisturbed deployment environment for the microservices architecture. Tests have shown that this solution has the advantages of good computational efficiency and stable operation.
Key words: microservice; management information system; Spring Cloud; Dockers
0 引言
電力公司在信息化建設(shè)過程中,致力于通過將業(yè)務(wù)流程與信息技術(shù)的結(jié)合來提高管理效率。然而由于缺乏整體規(guī)劃和理論支持,導(dǎo)致電力公司管理信息系統(tǒng)的架構(gòu)出現(xiàn)以下三個(gè)特征:(1) 單片架構(gòu)成為主要的部署模式[1-3]。單片架構(gòu)軟件系統(tǒng)在開發(fā)的早期階段易于調(diào)試,運(yùn)行簡單,易于部署。電力公司我們需要做的只是將打包的信息系統(tǒng)復(fù)制到服務(wù)器上。通過在負(fù)載均衡器的后端運(yùn)行多個(gè)無狀態(tài)服務(wù)副本,可以很容易地實(shí)現(xiàn)應(yīng)用程序的橫向擴(kuò)展,并且操作或維護(hù)的門檻很低。(2) 隨著需求的變化,電力公司管理信息系統(tǒng)逐漸變得復(fù)雜得多,新的開發(fā)人員無法弄清楚業(yè)務(wù)邏輯。因此,修復(fù)錯(cuò)誤和添加新功能非常困難且耗時(shí)。最終,電力公司管理信息系統(tǒng)將陷入一個(gè)巨大的、難以理解的泥潭。(3) 傳統(tǒng)的系統(tǒng)開發(fā)模式在成本和效率上沒有優(yōu)勢,限制了電力公司的信息化發(fā)展。單片架構(gòu)的管理信息系統(tǒng)也使得采用新的體系結(jié)構(gòu)和編程語言變得非常困難。最終,電力公司無法通過非擴(kuò)展,低可靠性應(yīng)用程序?qū)崿F(xiàn)敏捷開發(fā)甚至快速部署。為此,本文提出基于微服務(wù)架構(gòu)和輕量級容器技術(shù)進(jìn)行電力公司管理信息系統(tǒng)的開發(fā)以解決上述問題。
1 相關(guān)研究
微服務(wù)體系結(jié)構(gòu)(MSA)是一個(gè)提供了用于構(gòu)建復(fù)雜軟件系統(tǒng)的細(xì)粒度、自包含的服務(wù)組件(微服務(wù))的新興云軟件系統(tǒng)。基于SDLC(軟件開發(fā)生命周期)原則開發(fā)的電力公司管理信息系統(tǒng)所缺乏可擴(kuò)展、可維護(hù)等諸多問題,促使電力公司管理信息系統(tǒng)從傳統(tǒng)的單片體系結(jié)構(gòu)遷移到MSA。文獻(xiàn)[4]提出了基于SDLC的遷移過程,包括設(shè)計(jì)、開發(fā)和實(shí)現(xiàn)過程中所需的所有方法和工具。
設(shè)計(jì)良好的微服務(wù)架構(gòu)和更好的質(zhì)量依賴于對相關(guān)質(zhì)量屬性的清晰理解。然而,目前對微服務(wù)體系結(jié)構(gòu)中質(zhì)量屬性的理解還不夠全面。文獻(xiàn)[5]通過系統(tǒng)文獻(xiàn)綜述(SLR)、探索性案例研究和解釋性調(diào)查構(gòu)建了建筑質(zhì)量屬性知識。通過分析相關(guān)質(zhì)量屬性的影響因素及相應(yīng)策略,旨在為微服務(wù)體系結(jié)構(gòu)的質(zhì)量改進(jìn)提供全面的指導(dǎo)。
文獻(xiàn)[8]介紹了使用相同的可擴(kuò)展場景開發(fā)和部署的Web應(yīng)用程序與單片架構(gòu)、私有云運(yùn)營的微服務(wù)架構(gòu)和由云提供商運(yùn)營的微服務(wù)架構(gòu)三種不同方法的成本比較。測試結(jié)果表明,與標(biāo)準(zhǔn)單片式架構(gòu)相比,微服務(wù)可以幫助降低基礎(chǔ)架構(gòu)成本。此外,使用專門用于部署和擴(kuò)展微服務(wù)的服務(wù)可將基礎(chǔ)架構(gòu)成本降低70%或更多。該研究還描述了實(shí)施和部署微服務(wù)信息系統(tǒng)的挑戰(zhàn)。
容器虛擬化以其能夠以靈活的方式部署和管理物聯(lián)網(wǎng)設(shè)備中的微服務(wù)正在成為一種被普遍使用的技術(shù)。文獻(xiàn)[6]關(guān)注物聯(lián)網(wǎng)設(shè)備中的微服務(wù)可靠性,并提出了一種基于容器虛擬化的系統(tǒng),該系統(tǒng)提供了物聯(lián)網(wǎng)云上所運(yùn)行的微服務(wù)的故障容錯(cuò)機(jī)制。
2 基于微服務(wù)架構(gòu)的信息系統(tǒng)
2.1 基本思路
為了減少電力公司信息系統(tǒng)中子系統(tǒng)之間的耦合,通常將系統(tǒng)分成多個(gè)組件,這有助于分離組件邊界和職責(zé)。程序員可以通過獨(dú)立地升級或維護(hù)系統(tǒng)。面向服務(wù)功能組件的主要目的是將不同編程語言實(shí)現(xiàn)的功能組件封裝到服務(wù)中。然后,用不同編程語言編寫的客戶端程序?qū)Ψ?wù)接口進(jìn)行跨語言和跨環(huán)境調(diào)用,功能組件服務(wù)和跨語言服務(wù)接口調(diào)用的效果,如圖1所示。
2.2 微服務(wù)架構(gòu)的設(shè)計(jì)原則
在電力公司管理信息系統(tǒng)開發(fā)的早期階段,信息系統(tǒng)通常采用提供服務(wù)列表的單片架構(gòu)S(s1,s2,…,sx),單片架構(gòu)示意圖如圖2所示。
由一組開發(fā)人員開發(fā)代碼。隨著應(yīng)用程序的擴(kuò)展,將添加更多的服務(wù)或開發(fā)人員,從而增加了啟動(dòng)新功能或改進(jìn)所需的復(fù)雜性和時(shí)間。
面向服務(wù)的體系結(jié)構(gòu)(SOA)[7]解決了電力公司管理信息系統(tǒng)復(fù)雜性所導(dǎo)致的可運(yùn)維性、可拓展性較差的問題。電力公司管理信息系統(tǒng)由一系列單片架構(gòu)的信息系統(tǒng)(S1,S2,…,Sn)組成,每個(gè)信息系統(tǒng)通過不同的標(biāo)準(zhǔn)提供服務(wù)(如簡單對象訪問協(xié)議)。一些管理信息系統(tǒng)使用路由機(jī)制,例如企業(yè)服務(wù)總線(Enterprise Service Bus,ESB)[8]在各個(gè)電力公司管理信息系統(tǒng)之間路由和發(fā)送消息。SOA允許每個(gè)信息系統(tǒng)由按業(yè)務(wù)功能分組的不同開發(fā)團(tuán)隊(duì)進(jìn)行獨(dú)立開發(fā),最后獨(dú)立開發(fā)的各個(gè)系統(tǒng)向SOA發(fā)布各自的服務(wù)接口,并由SOA向各個(gè)系統(tǒng)提供消息訂閱功能。
雖然SOA實(shí)現(xiàn)可以滿足某些電力公司管理信息系統(tǒng)的需求,但SOA存在非常復(fù)雜、昂貴,甚至耗時(shí)的問題[6]。SOA的一個(gè)典型實(shí)現(xiàn)是ESB,其被設(shè)計(jì)用于有效地支持具有大量用戶的電力公司管理信息系統(tǒng)。當(dāng)面臨將ESB擴(kuò)展到數(shù)十萬或數(shù)百萬用戶的挑戰(zhàn)時(shí),SOA將成為創(chuàng)建高延遲和增加單一故障點(diǎn)可能性的瓶頸。因此,根據(jù)需要向ESB添加或刪除服務(wù)器是很復(fù)雜的。至于敏捷性,在ESB中需要大量的配置來滿足最終用戶的新需求,這將耗費(fèi)大量的時(shí)間。
作為SOA的一個(gè)輕量級子集,MSA(Micro Service Architecture)吸收了SOA體系結(jié)構(gòu)的優(yōu)點(diǎn),避免了單片架構(gòu)的相應(yīng)問題。MSA是使用一組微服務(wù)構(gòu)建信息系統(tǒng)的解決方案。MSA由多個(gè)服務(wù)以單獨(dú)的業(yè)務(wù)單元的形式組成,并通過適當(dāng)?shù)募夹g(shù)圍繞指定的業(yè)務(wù)實(shí)現(xiàn)。每個(gè)微服務(wù)運(yùn)行在一個(gè)獨(dú)立的進(jìn)程中,依賴于獨(dú)立的自動(dòng)部署機(jī)制,形成一個(gè)邊界清晰、內(nèi)聚性高的自治單元;微服務(wù)通過一些輕量級的通信機(jī)制進(jìn)行通信,如RPC、HTTP等[9-10]。
為此,建議將管理信息轉(zhuǎn)換為一組微服務(wù)MS(MS1,MS2…msn),每個(gè)微服務(wù)都是提供服務(wù)的子集(s1,s2…sx)。開發(fā)團(tuán)隊(duì)使用技術(shù)棧(包括表示層、服務(wù)層和持久層)獨(dú)立地開發(fā)和測試這些微服務(wù),以便更適用于微服務(wù)提供的服務(wù)。開發(fā)團(tuán)隊(duì)還負(fù)責(zé)在云計(jì)算iaas/paas解決方案上部署、擴(kuò)展、操作和升級微服務(wù)[11-13]。在表示層中,使用表示狀態(tài)轉(zhuǎn)移(rest)發(fā)布服務(wù)[14]。微服務(wù)架構(gòu)如圖3所示。
Spring Cloud是一個(gè)旨在簡化信息系統(tǒng)的開發(fā)和部署過程的全新Web框架。Spring Cloud包含一組功能良好、基于Spring Boot的輕量級微服務(wù)組件。Spring Cloud的主要特性有服務(wù)發(fā)現(xiàn)管理、服務(wù)容錯(cuò)、服務(wù)網(wǎng)關(guān)和服務(wù)配置、負(fù)載平衡和消息傳遞。在總線和服務(wù)跟蹤方面,Spring Cloud框架也有經(jīng)過良好測試和成熟的組件。
Spring Cloud完整架構(gòu)圖,如圖4所示。
Eureka實(shí)現(xiàn)了Spring Cloud中微服務(wù)的自動(dòng)注冊和發(fā)布。Zuul用于動(dòng)態(tài)路由和請求過濾。功能區(qū)是基于HTTP和TCP的客戶端負(fù)載平衡,從Eureka Registry獲取服務(wù)列表。 HyStrix是一種可以提高系統(tǒng)容錯(cuò)能力的斷路器。Turbine是一種用于監(jiān)控微服務(wù)集群的工具。 Feign集成了Ribbon,為客戶端提供聲明性HTTP API。Spring Cloud Config為Spring Cloud框架系統(tǒng)提供統(tǒng)一的配置管理,并為服務(wù)器(Config Server)和客戶端(Config Client)提供支持。Spring Cloud總線的作用是將服務(wù)節(jié)點(diǎn)與輕量級消息代理(例如RabbitMQ)連接,并廣播配置文件的動(dòng)態(tài)信息與服務(wù)之間的通信。Spring Cloud Sleuth集成了ZipKin,實(shí)現(xiàn)了微服務(wù)的監(jiān)控鏈路分析[15]。
微服務(wù)是一種先進(jìn)的體系結(jié)構(gòu),但在系統(tǒng)復(fù)雜性和服務(wù)的持續(xù)集成方面存在著不可避免的缺陷。因此,本文引入了Docker技術(shù)來彌補(bǔ)微服務(wù)架構(gòu)的上述缺陷。Docker是一個(gè)符合Apache2.0協(xié)議開源容器引擎,其使用輕量級虛擬化技術(shù)來實(shí)現(xiàn)資源隔離,并打包各種環(huán)境依賴項(xiàng)和應(yīng)用程序,以促進(jìn)應(yīng)用程序的移植和部署。本研究將微服務(wù)打包成單獨(dú)的Docker鏡像,然后將它們推入私有鏡像數(shù)據(jù)庫。每次部署服務(wù)時(shí),都會(huì)從私有鏡像庫中提取相應(yīng)的鏡像,并根據(jù)預(yù)定的微服務(wù)運(yùn)行鏡像。
2.3 實(shí)施技術(shù)
Spring Cloud框架是以Java語言為基礎(chǔ),以統(tǒng)一的通信標(biāo)準(zhǔn),將不同語言(如C++、.NET、Python、Matlab等)編寫的程序發(fā)布到微服務(wù)中。本文使用JNI(解決C++和Java通信問題)、進(jìn)程間通信和RPC(遠(yuǎn)程過程調(diào)用)等技術(shù)將底層系統(tǒng)通信接口作為Java程序的補(bǔ)充,從而解決了功能組件服務(wù)的通信問題。
一個(gè)簡單的服務(wù)組合示例,該示例由四個(gè)服務(wù)A、B、C和D組成。如圖5所示。
服務(wù)A獲取輸入數(shù)據(jù),數(shù)據(jù)可以由多個(gè)基本數(shù)據(jù)類型(整數(shù)、浮點(diǎn)數(shù))和復(fù)雜數(shù)據(jù)類型(數(shù)組)的組合;輸出(X,Y)是兩個(gè)基本數(shù)據(jù)類型的組合。在客戶端遠(yuǎn)程調(diào)用該服務(wù)組合之后,服務(wù)的內(nèi)部調(diào)用過程如下:
1) 服務(wù)A調(diào)用B.handle(數(shù)據(jù));
2) 服務(wù)B異步調(diào)用c.handle(data);
3) 服務(wù)B異步調(diào)用d.handle(data);
4) 服務(wù)C返回響應(yīng)X;
5) 服務(wù)D返回響應(yīng)Y;
6) 服務(wù)B在服務(wù)C和D都返回響應(yīng)之后返回響應(yīng)(x,y)。
構(gòu)建上述微服務(wù)的算法如下:
微服務(wù)構(gòu)建算法
1: mS ← 初始微服務(wù)列表
2: ts ← 微服務(wù)的時(shí)間閾值
3: S ← 功能列表
4: C ← 代碼庫
5: for s in S
6: c ← 在C中完成的代碼
7: mS.add(c)
8: end for
9: for mSi,mSj in mS
10: if correlation(mSi,mSj) > ts
11: mSi = merge(mSi,mSj)
12: end if
13: end for
使用Docker后微服務(wù)框圖,如圖6所示。
這四個(gè)微服務(wù)A、B、C和D獨(dú)立部署在Docker容器中,微服務(wù)A發(fā)起調(diào)用微服務(wù)B的請求,微服務(wù)B異步調(diào)用微服務(wù)C和D。這創(chuàng)建了一個(gè)復(fù)雜而完整的業(yè)務(wù)處理流程。將復(fù)雜的應(yīng)用系統(tǒng)拆分為多個(gè)服務(wù),每個(gè)服務(wù)具有單一功能和簡單的業(yè)務(wù)邏輯。每個(gè)微服務(wù)都在Eureka Server中注冊,微服務(wù)可以通過聲明性RESTful API調(diào)用。
3 實(shí)驗(yàn)分析
實(shí)驗(yàn)環(huán)境包括:配置Xeon處理器、16GB RAM的運(yùn)行微服務(wù)的主機(jī),在Linux3.9上運(yùn)行Docker 1.6和Spring Cloud Dalston.SR5的主機(jī),以及單獨(dú)運(yùn)行每個(gè)容器的主機(jī)。試驗(yàn)選擇了WSO2產(chǎn)品作為試驗(yàn)環(huán)境的服務(wù)總線。測試和比較單片架構(gòu)、ESB和本文所提的微服務(wù)架構(gòu)這三種體系結(jié)構(gòu)的性能。試驗(yàn)所測量到服務(wù)時(shí)間的消耗包括(1) 用于請求服務(wù)的時(shí)間,(2) 用于接收響應(yīng)消息的時(shí)間(3) 用于解析服務(wù)響應(yīng)消息和描述的時(shí)間。為了獲得準(zhǔn)確的數(shù)據(jù),試驗(yàn)啟動(dòng)了多個(gè)重復(fù)調(diào)用請求。
如前所述,使用SpringCloud框架將電力公司管理信息系統(tǒng)重構(gòu)為未耦合的微服務(wù),并通過Docker技術(shù)將它們部署到服務(wù)器上。在本試驗(yàn)中,使用四個(gè)微服務(wù)作為實(shí)驗(yàn)條件。微服務(wù)A負(fù)責(zé)購電成本和銷電價(jià)格的查詢。微服務(wù)B用于統(tǒng)計(jì)售電量。微服務(wù)C為購電合同的概述,如季度購電成本等。微服務(wù)D根據(jù)損益信息指定下一季度的購電計(jì)劃。
為了從中準(zhǔn)確評估這些微服務(wù)的運(yùn)行性能,試驗(yàn)在沒有加載管理系統(tǒng)的前提下反復(fù)運(yùn)行這些微服務(wù),性能試驗(yàn)結(jié)果,如表1所示。
試驗(yàn)對不同系統(tǒng)架構(gòu)下管理信息系統(tǒng)的運(yùn)行性能的反復(fù)測試的結(jié)果,如表2所示。
在不同服務(wù)調(diào)用數(shù)量下,三個(gè)系統(tǒng)架構(gòu)的運(yùn)行性能的試驗(yàn)數(shù)據(jù)對比如圖7所示。
通過分析表1、表2和圖7的試驗(yàn)數(shù)據(jù),可以得出結(jié)論:由于內(nèi)部通信成本幾乎為零,單片架構(gòu)的平均時(shí)間開銷最小,平均運(yùn)行時(shí)間為63.24 ms;對于微服務(wù)架構(gòu)和ESB,微服務(wù)架構(gòu)的平均時(shí)間損失為54.25 ms,優(yōu)于ESB的 65.42 ms,這使得使用微服務(wù)架構(gòu)重建電力公司管理信息非常合理。由圖7可知,隨著服務(wù)調(diào)用數(shù)量增長,微服務(wù)架構(gòu)沒有明顯下降,因此可以預(yù)見采用微服務(wù)架構(gòu)構(gòu)建電力公司管理信息系統(tǒng)將具有良好的運(yùn)行穩(wěn)定性。
4 總結(jié)
隨著電力公司管理系統(tǒng)的規(guī)模越來越龐大,對快速響應(yīng)功能需求的要求越來越嚴(yán)格,傳統(tǒng)的軟件系統(tǒng)架構(gòu)已經(jīng)不能滿足需求。微服務(wù)架構(gòu)作為新興的系統(tǒng)架構(gòu)為軟件開發(fā)人員提供靈活的軟件構(gòu)建方法,可以有效應(yīng)對更頻繁的軟件更新和滿足更短的交付周期的需求,成為電力公司部署管理系統(tǒng)新的架構(gòu)選擇。本文闡述了Spring Cloud和Docker所構(gòu)建的系統(tǒng)架構(gòu)能夠?qū)崿F(xiàn)面向組件和面向服務(wù)的服務(wù)管理,增強(qiáng)了服務(wù)的持續(xù)集成和擴(kuò)展能力。試驗(yàn)也表明了該系統(tǒng)架構(gòu)具有計(jì)算效率良好,運(yùn)行穩(wěn)定的優(yōu)勢。因此基于Spring Cloud和Docker的微服務(wù)架構(gòu)具有成為電力公司重構(gòu)管理信息系統(tǒng)的最佳解決方案的潛力。
參考文獻(xiàn)
[1] 李慧春,王成喜,朱曉旭.基于Docker的Linux在線實(shí)驗(yàn)環(huán)境[J].實(shí)驗(yàn)技術(shù)與管理,2019,36(3):47-50.
[2] 徐曉耘,左松林,倪妍妍.基于微服務(wù)架構(gòu)的電力營銷信息系統(tǒng)研究[J].信息技術(shù),2019(2):160-166.
[3] 劉曉東,趙曉芳,陳雅靜,等.基于服務(wù)能力模型的微服務(wù)彈性資源供給機(jī)制[J].高技術(shù)通訊,2019,29(1):1-11.
[4] 方意,朱永強(qiáng),宮學(xué)慶.微服務(wù)架構(gòu)下的分布式事務(wù)處理[J].計(jì)算機(jī)應(yīng)用與軟件,2019,36(1):152-158.
[5] 趙子晨,朱志祥,蔣來好.構(gòu)建基于Dubbo框架的Spring Boot微服務(wù)[J].計(jì)算機(jī)與數(shù)字工程,2018,46(12):2539-2543.
[6] 張琦.基于Docker的CaaS管理平臺架構(gòu)研究與設(shè)計(jì)[J].計(jì)算機(jī)應(yīng)用與軟件,2018,35(11):33-41.
[7] 馮顯力,韋化,韋洪波,等.含微服務(wù)的調(diào)度自動(dòng)化系統(tǒng)分布式實(shí)時(shí)數(shù)據(jù)庫[J].電力系統(tǒng)保護(hù)與控制,2018,46(21):138-144.
[8] 程偉華,周捷,趙亞.基于微服務(wù)架構(gòu)的電力系統(tǒng)拆分方法[J].信息技術(shù),2018,42(10):115-119.
[9] 徐琛杰,周翔,彭鑫,等.面向微服務(wù)系統(tǒng)的運(yùn)行時(shí)部署優(yōu)化[J].計(jì)算機(jī)應(yīng)用與軟件,2018,35(10):85-93.
[10] 承林,王海寧,高春成.微服務(wù)在電力交易系統(tǒng)中的應(yīng)用研究[J].電網(wǎng)技術(shù),2018,42(2):441-446.
[11] 龍新征,彭一明,李若淼.基于微服務(wù)框架的信息服務(wù)平臺[J].東南大學(xué)學(xué)報(bào)(自然科學(xué)版),2017,47(S1):48-52.
[12] 張松,疏官勝,李京.容器微云監(jiān)控系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)[J].中國科學(xué)技術(shù)大學(xué)學(xué)報(bào),2017,47(8):627-634.
[13] 畢小紅,劉淵,陳飛.微服務(wù)應(yīng)用平臺的網(wǎng)絡(luò)性能研究與優(yōu)化[J].計(jì)算機(jī)工程,2018,44(5):53-59.
[14] 郝庭毅,吳恒,吳國全,等.面向微服務(wù)架構(gòu)的容器級彈性資源供給方法[J].計(jì)算機(jī)研究與發(fā)展,2017,54(3):597-608.
[15] 歐陽榮彬,王倩宜,龍新征.基于微服務(wù)的數(shù)據(jù)服務(wù)框架設(shè)計(jì)[J].華中科技大學(xué)學(xué)報(bào)(自然科學(xué)版),2016,44(S1):126-130.
(收稿日期: 2019.06.25)