基于微服務架構的水資源數據接口設計與實現

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

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

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

1 系統架構

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

圖1 系統架構演化示意Fig.1 System architecture evolution

1.1 系統架構演化歷程

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

1.2 基于容器云的MSA架構

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

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

2 數據接口功能設計與實現

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

2.1 業務系統微服務架構改造

整體改造方案對各業務系統進行松耦合及拆分，提取公用數據服務并進行分類實現。業務系統微服務架構改造設計見圖2。

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

2.2 接口功能設計

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

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

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

2.3 技術路線

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

圖4 水資源數據接口系統架構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。服務器拿到頭信息后從數據庫(或者緩存)中取出access-key對應的secret，按照相同方式計算HMAC，如果其與Authorization header一致，則請求合法；否則不合法。

基于HMAC加密的安全驗證時序圖見圖5。接口開發完成后通過Yapi接口管理平臺提供管理測試等功能。接口管理列表見圖6。業務功能改造前后對比見圖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 持續集成

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

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

3.1.2 鏡像管理

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

3.2 監控與鏈路管理

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

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

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

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

(5) 鏈路管理。基于zipkin的服務間調用鏈路監控，展示調用延時、調用結果等信息。通過系統上下游的自定義埋點，可以監控整體系統鏈路的業務全貌。

3.3 配置中心

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

4 結 論

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

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

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

隨著后期業務功能發展，在現有的設計方法和技術路線的基礎上，系統功能還將有較大的改造和優化空間。