樊啟萌，姚華明，湯正陽，楊 旭，張玉柱，趙牧晨

(1.三峽水利樞紐梯級(jí)調(diào)度通信中心，湖北 宜昌 443002； 2.智慧長(zhǎng)江與水電科學(xué)湖北省重點(diǎn)實(shí)驗(yàn)室，湖北 宜昌 443002)

隨著梯級(jí)調(diào)度業(yè)務(wù)持續(xù)發(fā)展，三峽水利樞紐梯級(jí)調(diào)度通信中心積累了氣象、水調(diào)、電調(diào)等多業(yè)務(wù)系統(tǒng)，各系統(tǒng)相對(duì)獨(dú)立，數(shù)據(jù)也較為分散。受建設(shè)時(shí)期、業(yè)務(wù)模式等因素制約，整體缺乏統(tǒng)一的設(shè)計(jì)標(biāo)準(zhǔn)，開發(fā)平臺(tái)、開發(fā)語言各有差異，信息交互共享困難。為滿足水資源研究、展示數(shù)據(jù)需要，實(shí)現(xiàn)信息共享與交互，加之配合長(zhǎng)江電力公司Paas云平臺(tái)化建設(shè)，基于微服務(wù)架構(gòu)形成一個(gè)通用的水資源數(shù)據(jù)接口服務(wù)，具有重要意義。

1 系統(tǒng)架構(gòu)

應(yīng)用系統(tǒng)架構(gòu)經(jīng)過近10 a發(fā)展沉淀，逐漸由單一發(fā)展至分布式發(fā)展，由功能化至服務(wù)化，經(jīng)歷了從單一應(yīng)用架構(gòu)(ORM)到垂直應(yīng)用架構(gòu)(MVC)、分布式服務(wù)架構(gòu)(RPC)、流動(dòng)計(jì)算架構(gòu)(SOA)及微服務(wù)架構(gòu)(MSA)的演化歷程(圖1)。

圖1 系統(tǒng)架構(gòu)演化示意Fig.1 System architecture evolution

1.1 系統(tǒng)架構(gòu)演化歷程

早期系統(tǒng)以單體應(yīng)用為主，即所有功能集中部署的高內(nèi)聚版本。隨著業(yè)務(wù)的復(fù)雜化，單體應(yīng)用逐步被MVC架構(gòu)替代，業(yè)務(wù)被拆分成視圖層、控制層、邏輯層、數(shù)據(jù)訪問層、數(shù)據(jù)存儲(chǔ)層。MVC架構(gòu)解決了前后端、界面、控制邏輯和業(yè)務(wù)邏輯分層問題，系統(tǒng)具有模塊化的特點(diǎn)，便于二次開發(fā)與維護(hù)，但是仍存在不同應(yīng)用之間的通信與交互問題。進(jìn)一步考慮將核心和公共業(yè)務(wù)抽取形成單獨(dú)服務(wù)，以解決模塊之間跨進(jìn)程通信的問題。結(jié)合公司開放能力云平臺(tái)建設(shè)，系統(tǒng)架構(gòu)隨業(yè)務(wù)需求迭代演化，最終實(shí)現(xiàn)了統(tǒng)一服務(wù)生命周期管控及較好的服務(wù)治理。綜上所述，推出了全面支持微服務(wù)的開發(fā)框架[1]，采用微服務(wù)架構(gòu)和平臺(tái)輕量級(jí)容器技術(shù)(Docker)、云計(jì)算資源相結(jié)合，可將高度耦合的功能分解到各個(gè)離散的微服務(wù)中以實(shí)現(xiàn)對(duì)應(yīng)用系統(tǒng)的解耦[2]，是更好提升系統(tǒng)持續(xù)集成和擴(kuò)展能力的解決方案。

1.2 基于容器云的MSA架構(gòu)

微服務(wù)是一種軟件架構(gòu)的設(shè)計(jì)風(fēng)格，整個(gè)軟件服務(wù)架構(gòu)由多個(gè)微服務(wù)構(gòu)成[3]，微服務(wù)架構(gòu)實(shí)際上是SOA架構(gòu)樣式的變體，提倡將單一應(yīng)用程序劃分為若干單獨(dú)的服務(wù)，每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制。每個(gè)微服務(wù)可以獨(dú)立編譯、部署、運(yùn)行。微服務(wù)是在信息技術(shù)下完成分散大系統(tǒng)的建構(gòu)，運(yùn)行過程中為高度相對(duì)獨(dú)立狀態(tài)，也能夠有效實(shí)現(xiàn)自治[4]。微服務(wù)架構(gòu)理念為敏捷開發(fā), 在微服務(wù)架構(gòu)的基礎(chǔ)上研究電力服務(wù)平臺(tái), 可以最大限度地簡(jiǎn)化服務(wù), 同時(shí)能夠?qū)ΜF(xiàn)有的電力業(yè)務(wù)不產(chǎn)生任何影響[5]。在微服務(wù)運(yùn)行過程中，微服務(wù)性能受運(yùn)行環(huán)境影響，云計(jì)算平臺(tái)的出現(xiàn)和發(fā)展為微服務(wù)提供了方便快捷的運(yùn)行環(huán)境。在云計(jì)算平臺(tái)下，所有的軟硬件資源(包括網(wǎng)絡(luò)、服務(wù)器、存儲(chǔ)、應(yīng)用軟件、服務(wù))統(tǒng)一在資源池中，用戶按需取用，大大減少了資源管理工作開銷。常見云服務(wù)模式有3層，分別是IaaS(基礎(chǔ)設(shè)施即服務(wù))層、PaaS(平臺(tái)即服務(wù))層和SaaS(軟件即服務(wù))層。IaaS層為用戶提供計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)資源；PaaS層為用戶提供應(yīng)用程序部署和管理服務(wù)；SaaS層提供用戶使用的軟件系統(tǒng)。近年來，容器化技術(shù)廣泛應(yīng)用到云計(jì)算中，容器云以容器作為資源分割和調(diào)度的基本單位，進(jìn)行軟件開發(fā)和部署，最后將容器制作成鏡像交付用戶，用戶無需關(guān)注開發(fā)和部署過程，就能具有更好的性能、更快的部署和發(fā)布速度。

容器鏡像類似于文件系統(tǒng)的分層機(jī)構(gòu)，而從鏡像運(yùn)行容器會(huì)在該鏡像頂部加載一個(gè)可讀寫、初始值為空的文件系統(tǒng)，稱為容器層[6]。利用云計(jì)算提供的微服務(wù)環(huán)境構(gòu)建軟件的開發(fā)、部署和運(yùn)行環(huán)境，同時(shí)利用先進(jìn) Web 技術(shù)實(shí)現(xiàn)軟件的 Web 化將是云計(jì)算環(huán)境下軟件的發(fā)展方向和趨勢(shì)[7]。Docker是一種常用的容器技術(shù)，因其輕量化、高性能、跨平臺(tái)等優(yōu)點(diǎn)而被廣泛運(yùn)用，Kubernetes是一個(gè)基于Docker實(shí)現(xiàn)的容器編排系統(tǒng)。Docker和Kubernetes是構(gòu)建開放平臺(tái)基礎(chǔ)設(shè)施的核心技術(shù)?；谌萜髟频拈_放平臺(tái)基礎(chǔ)設(shè)施可以實(shí)現(xiàn)基礎(chǔ)資源的復(fù)用，一體化部署及統(tǒng)一的服務(wù)治理，優(yōu)化微服務(wù)程序的部署方法，同時(shí)也可以實(shí)現(xiàn)更靈活的云資源彈性擴(kuò)展和回收。

2 數(shù)據(jù)接口功能設(shè)計(jì)與實(shí)現(xiàn)

目前，水資源研究業(yè)務(wù)涉及數(shù)據(jù)主要來源于梯調(diào)水庫調(diào)度數(shù)據(jù)庫，在此基礎(chǔ)上，先后開發(fā)過移動(dòng)查詢、可視化、決策支持等系統(tǒng)，系統(tǒng)多采取單體應(yīng)用或垂直業(yè)務(wù)架構(gòu)，各系統(tǒng)之間獨(dú)立，數(shù)據(jù)無法共享。現(xiàn)考慮將前期各系統(tǒng)數(shù)據(jù)接口整理、分類、重構(gòu)為微服務(wù)架構(gòu)的接口服務(wù)。

2.1 業(yè)務(wù)系統(tǒng)微服務(wù)架構(gòu)改造

整體改造方案對(duì)各業(yè)務(wù)系統(tǒng)進(jìn)行松耦合及拆分，提取公用數(shù)據(jù)服務(wù)并進(jìn)行分類實(shí)現(xiàn)。業(yè)務(wù)系統(tǒng)微服務(wù)架構(gòu)改造設(shè)計(jì)見圖2。

圖2 系統(tǒng)微服務(wù)架構(gòu)改造設(shè)計(jì)Fig.2 System microservice architecture rebuilding design

2.2 接口功能設(shè)計(jì)

按業(yè)務(wù)需求，接口服務(wù)可劃分為管理數(shù)據(jù)接口、水文業(yè)務(wù)接口、基礎(chǔ)數(shù)據(jù)處理接口三大類。① 管理數(shù)據(jù)接口主要包括登錄驗(yàn)證等功能；② 水文業(yè)務(wù)接口主要包括實(shí)時(shí)數(shù)據(jù)、小時(shí)數(shù)據(jù)、日數(shù)據(jù)、旬?dāng)?shù)據(jù)、月數(shù)據(jù)、年數(shù)據(jù)、計(jì)劃數(shù)據(jù)、預(yù)報(bào)數(shù)據(jù)、決策系統(tǒng)模擬計(jì)算水位、流量結(jié)果數(shù)據(jù)、水庫模擬仿真計(jì)算數(shù)據(jù)、規(guī)則模型參數(shù)數(shù)據(jù)等；③ 基礎(chǔ)數(shù)值計(jì)算接口提供擬合、插值、曲線查詢等功能。水資源數(shù)據(jù)接口功能總體設(shè)計(jì)見圖3。

圖3 水資源數(shù)據(jù)接口功能總體設(shè)計(jì)Fig.3 Overall design of water resource data interface function

其中，實(shí)時(shí)數(shù)據(jù)接口，包括通用實(shí)時(shí)數(shù)據(jù)查詢、通過電站編號(hào)獲取電站實(shí)時(shí)機(jī)組出力信息、實(shí)時(shí)水位數(shù)據(jù)查詢、實(shí)時(shí)流量數(shù)據(jù)查詢、實(shí)時(shí)出力數(shù)據(jù)查詢等獲取實(shí)時(shí)數(shù)據(jù)。計(jì)劃數(shù)據(jù)接口，通過點(diǎn)號(hào)和電站號(hào)獲得最新計(jì)劃出力信息。小時(shí)、日、月、旬、年等數(shù)據(jù)接口，涵蓋水文、電力、氣象等各時(shí)段數(shù)據(jù)信息。預(yù)報(bào)數(shù)據(jù)接口，包括流量預(yù)報(bào)信息、演進(jìn)后預(yù)報(bào)信息、氣象雨量預(yù)報(bào)信息?；A(chǔ)數(shù)值計(jì)算接口，包括多項(xiàng)式擬合、常量擬合、帶截?cái)嗟木€性擬合、一般線性擬合、線性內(nèi)插、三次多項(xiàng)式插值、三次樣條插值以及曲線查詢、水文頻率查詢等方法。

2.3 技術(shù)路線

資源數(shù)據(jù)接口服務(wù)程序采用微服務(wù)+容器云的技術(shù)路線。微服務(wù)單獨(dú)部署并在注冊(cè)中心進(jìn)行注冊(cè)，網(wǎng)關(guān)中心為微服務(wù)提供入口，實(shí)現(xiàn)路由和過濾功能。數(shù)據(jù)層采用Mybatis Plus框架，實(shí)現(xiàn)數(shù)據(jù)庫的持久化操作以及查詢、統(tǒng)計(jì)、計(jì)算等操作。數(shù)據(jù)服務(wù)層采用Spring Boot框架，Spring Boot可用于多層架構(gòu)體系的模型業(yè)務(wù)層, 對(duì)于上層其可以有效地屏蔽底層數(shù)據(jù)庫操作, 提高低層模塊與高層模塊之間的內(nèi)聚, 降低多層模塊間的耦合性, 具有分層模塊化架構(gòu)應(yīng)用業(yè)務(wù)系統(tǒng)的優(yōu)勢(shì)[8]。通過業(yè)務(wù)需求邏輯對(duì)數(shù)據(jù)進(jìn)行加工處理，形成最終業(yè)務(wù)數(shù)據(jù)，定義并發(fā)布1套標(biāo)準(zhǔn)的數(shù)據(jù)調(diào)用方式和接口。數(shù)據(jù)封裝采用JSON數(shù)據(jù)格式。系統(tǒng)技術(shù)架構(gòu)圖如圖4所示。

圖4 水資源數(shù)據(jù)接口系統(tǒng)架構(gòu)Fig.4 Water resource data interface system architecture

接口安全驗(yàn)證采用基于HMAC的驗(yàn)證方式。其主要設(shè)計(jì)是在請(qǐng)求頭中使用兩個(gè)字段：access-key和Date(或Timestamp)，在API授權(quán)時(shí)為調(diào)用者生成access-key和access-secret，前者暴露在網(wǎng)絡(luò)中，后者安全保存。當(dāng)客戶端調(diào)用API時(shí)，把自己的access-key填入Authorization頭中，用自己的access-secret按照要求對(duì)request的headers/body計(jì)算HMAC加密后的secret。服務(wù)器拿到頭信息后從數(shù)據(jù)庫(或者緩存)中取出access-key對(duì)應(yīng)的secret，按照相同方式計(jì)算HMAC，如果其與Authorization header一致，則請(qǐng)求合法；否則不合法。

基于HMAC加密的安全驗(yàn)證時(shí)序圖見圖5。接口開發(fā)完成后通過Yapi接口管理平臺(tái)提供管理測(cè)試等功能。接口管理列表見圖6。業(yè)務(wù)功能改造前后對(duì)比見圖7。

圖5 基于HMAC加密的安全驗(yàn)證時(shí)序Fig.5 Security verification sequence based on HMAC encryption

圖6 接口管理列表Fig.6 Interface management list

圖7 改造前后對(duì)比Fig.7 Comparison before and after improvement

3 服務(wù)治理

3.1 DevOps

3.1.1 持續(xù)集成

依托微服務(wù)平臺(tái)持續(xù)集成功能，實(shí)現(xiàn)接口服務(wù)程序的一體化部署。本地調(diào)試完成后的交付jar包，在平臺(tái)創(chuàng)建部署流水線，配置自定義項(xiàng)并生成容器配置文件，根據(jù)配置文件自動(dòng)創(chuàng)建容器鏡像，實(shí)現(xiàn)一鍵發(fā)布。

同時(shí)，此次發(fā)布構(gòu)建的應(yīng)用鏡像發(fā)布到鏡像倉庫，實(shí)現(xiàn)了應(yīng)用的統(tǒng)一管理。應(yīng)用鏡像發(fā)布后存儲(chǔ)于鏡像倉庫中，滿足應(yīng)用一次構(gòu)建、多次運(yùn)行的需求。同時(shí)應(yīng)用部署日志可查看，搜索及管理。通過配置域名管理，接口服務(wù)程序以域名對(duì)外提供訪問。

3.1.2 鏡像管理

發(fā)布的應(yīng)用服務(wù)通過容器鏡像的方式進(jìn)行管理。微服務(wù)平臺(tái)提供公有和私有兩種方式鏡像發(fā)布。公有鏡像倉庫集成了JavaWeb、Python、Nginx等常見應(yīng)用環(huán)境；私有方式需要自定義Docker，發(fā)布到鏡像倉庫。

3.2 監(jiān)控與鏈路管理

(1) 集群監(jiān)控。包括集群的總體資源監(jiān)控(包括CPU、內(nèi)存、磁盤以及集群內(nèi)建立的NS的資源使用情況)。

(2) 主機(jī)監(jiān)控。包括主機(jī)的總體資源監(jiān)控(包括CPU、內(nèi)存、磁盤的資源使用情況)。

(3) 應(yīng)用監(jiān)控。應(yīng)用成功發(fā)布后，PaaS監(jiān)控大盤提供運(yùn)行應(yīng)用的監(jiān)控?cái)?shù)據(jù)。包括實(shí)時(shí)及歷史24 h內(nèi)，應(yīng)用占用的CPU、內(nèi)存、網(wǎng)絡(luò)曲線。通過監(jiān)控曲線，掌握應(yīng)用資源占用情況。

(4) 變更大盤。PaaS變更大盤提供用戶操作記錄。用戶操作生成變更單詳細(xì)記錄。變更單包括所有應(yīng)用的變更，通過變更單可查看歷史變動(dòng)，同時(shí)根據(jù)變更回滾至相應(yīng)版本。

(5) 鏈路管理?；趜ipkin的服務(wù)間調(diào)用鏈路監(jiān)控，展示調(diào)用延時(shí)、調(diào)用結(jié)果等信息。通過系統(tǒng)上下游的自定義埋點(diǎn)，可以監(jiān)控整體系統(tǒng)鏈路的業(yè)務(wù)全貌。

3.3 配置中心

通過統(tǒng)一的配置中心實(shí)現(xiàn)了對(duì)分布式應(yīng)用配置文件的統(tǒng)一管理以及對(duì)不同環(huán)境配置文件的管理及更新。通過配置中心，可以查看保持同步的實(shí)例的地址信息，在線維護(hù)配置文件。配置中心的配置文件與各環(huán)境鏡像中客戶端的配置文件保持同步。

4 結(jié) 論

本文提出了基于微服務(wù)架構(gòu)的水資源數(shù)據(jù)接口服務(wù)的設(shè)計(jì)及實(shí)現(xiàn)方法，是解決通過網(wǎng)絡(luò)傳輸數(shù)據(jù)和數(shù)據(jù)訪問的重要方法之一，解決了現(xiàn)有系統(tǒng)之間數(shù)據(jù)無法共享、功能冗余的問題，實(shí)現(xiàn)了從單體應(yīng)用到微服務(wù)架構(gòu)、從傳統(tǒng)部署到容器化持續(xù)集成的演變。

(1) 在業(yè)務(wù)功能方面。水資源接口服務(wù)涵蓋水資源研究、展示所需大部分?jǐn)?shù)據(jù)，并具備擴(kuò)展性，對(duì)比改造前，各系統(tǒng)后臺(tái)數(shù)據(jù)通過微服務(wù)統(tǒng)一管理，業(yè)務(wù)人員查看及調(diào)用更加便捷。

(2) 在服務(wù)治理方面，通過整合PaaS平臺(tái)，系統(tǒng)具備持續(xù)集成、統(tǒng)一配置、完整鏈路監(jiān)控日志的完善體系，具有較高的自動(dòng)化運(yùn)維水平和較低的運(yùn)維成本，對(duì)比改造前，系統(tǒng)異常處理及日常運(yùn)維效率有較大提升。

隨著后期業(yè)務(wù)功能發(fā)展，在現(xiàn)有的設(shè)計(jì)方法和技術(shù)路線的基礎(chǔ)上，系統(tǒng)功能還將有較大的改造和優(yōu)化空間。