基于微服務架構的水資源數(shù)據接口設計與實現(xiàn)

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

(1.三峽水利樞紐梯級調度通信中心，湖北 宜昌 443002； 2.智慧長江與水電科學湖北省重點實驗室，湖北 宜昌 443002)

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

1 系統(tǒng)架構

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

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

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

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

1.2 基于容器云的MSA架構

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

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

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

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

2.1 業(yè)務系統(tǒng)微服務架構改造

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

圖2 系統(tǒng)微服務架構改造設計Fig.2 System microservice architecture rebuilding design

2.2 接口功能設計

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

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

其中，實時數(shù)據接口，包括通用實時數(shù)據查詢、通過電站編號獲取電站實時機組出力信息、實時水位數(shù)據查詢、實時流量數(shù)據查詢、實時出力數(shù)據查詢等獲取實時數(shù)據。計劃數(shù)據接口，通過點號和電站號獲得最新計劃出力信息。小時、日、月、旬、年等數(shù)據接口，涵蓋水文、電力、氣象等各時段數(shù)據信息。預報數(shù)據接口，包括流量預報信息、演進后預報信息、氣象雨量預報信息?；A數(shù)值計算接口，包括多項式擬合、常量擬合、帶截斷的線性擬合、一般線性擬合、線性內插、三次多項式插值、三次樣條插值以及曲線查詢、水文頻率查詢等方法。

2.3 技術路線

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

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

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

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

圖5 基于HMAC加密的安全驗證時序Fig.5 Security verification sequence based on HMAC encryption

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

圖7 改造前后對比Fig.7 Comparison before and after improvement

3 服務治理

3.1 DevOps

3.1.1 持續(xù)集成

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

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

3.1.2 鏡像管理

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

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

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

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

(3) 應用監(jiān)控。應用成功發(fā)布后，PaaS監(jiān)控大盤提供運行應用的監(jiān)控數(shù)據。包括實時及歷史24 h內，應用占用的CPU、內存、網絡曲線。通過監(jiān)控曲線，掌握應用資源占用情況。

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

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

3.3 配置中心

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

4 結 論

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

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

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

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