基于微服務(wù)架構(gòu)的電力基建全過程管理平臺

郝鵬海，密興峰，朱 軍，時 旭

（南京南瑞信息通信科技有限公司，南京 210003）

0 引言

隨著電網(wǎng)建設(shè)業(yè)務(wù)的不斷發(fā)展，用戶數(shù)據(jù)量越來越大，業(yè)務(wù)需求日益多樣化和復(fù)雜化。傳統(tǒng)的基于單體架構(gòu)設(shè)計的電網(wǎng)基建信息化管理平臺已不能有效支撐電網(wǎng)基建業(yè)務(wù)的發(fā)展，很多局限性已經(jīng)開始體現(xiàn)。其中包括：

（1）代碼業(yè)務(wù)耦合嚴(yán)重、可靠性差。隨著基建平臺業(yè)務(wù)的擴(kuò)展，單體架構(gòu)下的業(yè)務(wù)耦合嚴(yán)重，一旦一個模塊出現(xiàn)問題，將會影響整個平臺的運(yùn)行，同時開發(fā)過程中要花費時間理解業(yè)務(wù)，開發(fā)效率大大降低。

（2）增加技術(shù)債、部署困難。代碼、組件之間的依賴過多，導(dǎo)致一些技術(shù)債難以被修復(fù)，并且隨著代碼量的增大，系統(tǒng)的全量部署費時費力。

（3）擴(kuò)展性差，在貫徹落實公司建設(shè)三型兩網(wǎng)現(xiàn)代化一流能源互聯(lián)網(wǎng)企業(yè)戰(zhàn)略目標(biāo)，實現(xiàn)電力系統(tǒng)各個環(huán)節(jié)萬物互聯(lián)、人機(jī)交互，打造狀態(tài)全面感知、信息高效處理、應(yīng)用便捷靈活的泛在電力物聯(lián)網(wǎng)的背景下，平臺對計算機(jī)資源的要求越來越高，傳統(tǒng)的單體架構(gòu)各個組件對計算機(jī)資源的要求不同，很難有效地擴(kuò)展和分配資源。

基于當(dāng)前電力基建工程項目管理過程中出現(xiàn)的問題，本文設(shè)計了一種基于微服務(wù)架構(gòu)的電力基建全過程數(shù)字化管理平臺。將基建平臺根據(jù)業(yè)務(wù)場景拆分成了多個微服務(wù)，從而達(dá)到系統(tǒng)的解耦。同時基于Spring Cloud 中間件，采用去中心化、服務(wù)化、異步化、高可用設(shè)計思路，提高了系統(tǒng)的可靠性和穩(wěn)定性。

1 系統(tǒng)架構(gòu)技術(shù)

1.1 微服務(wù)架構(gòu)技術(shù)

微服務(wù)架構(gòu)是近幾年來軟件架構(gòu)領(lǐng)域出現(xiàn)的高頻詞匯，是基于傳統(tǒng)的SOA 架構(gòu)演進(jìn)而來的一種架構(gòu)模式，微服務(wù)架構(gòu)將應(yīng)用程序構(gòu)建為以業(yè)務(wù)領(lǐng)域為模型的小型自治服務(wù)集合，其提倡將傳統(tǒng)的單體架構(gòu)或分布式架構(gòu)中的單體應(yīng)用程序和服務(wù)劃分成更小粒度的服務(wù)，這種服務(wù)稱之為微服務(wù)。微服務(wù)獨立開發(fā)部署，并與其他的微服務(wù)互相隔離。微服務(wù)之間提供restful 風(fēng)格的服務(wù)，通信協(xié)議采用http 協(xié)議，每個微服務(wù)都圍繞著具體的業(yè)務(wù)而構(gòu)建。這些服務(wù)共用一個最小型的集中式管理，服務(wù)可用不同的語言開發(fā)，并使用不同的存儲技術(shù)。相比于傳統(tǒng)的單體架構(gòu)，微服務(wù)架構(gòu)的優(yōu)點主要有以下幾個方面：微服務(wù)將一個大型的系統(tǒng)按照功能拆分成了一系列獨立的解耦的微服務(wù)，其能獨立地開發(fā)、構(gòu)建、發(fā)布和部署，而不影響其它的依賴業(yè)務(wù)，極大地簡化了單體架構(gòu)的復(fù)雜性，系統(tǒng)的開發(fā)、擴(kuò)展和維護(hù)的成本都大大降低。并且微服務(wù)架構(gòu)（見圖1）的技術(shù)選擇不受約束，同一個系統(tǒng)內(nèi)的每個微服務(wù)都可以采用不同的適合自身業(yè)務(wù)需求的技術(shù)和存儲方式，因此系統(tǒng)的性能也顯著提高。

圖1 微服務(wù)架構(gòu)圖

1.2 基建全過程系統(tǒng)微服務(wù)技術(shù)選型

目前主流的微服務(wù)框架有Dubbo 和Spring Cloud。由表1 可知，Spring Cloud 擁有更多的項目模塊，例如網(wǎng)關(guān)、鏈路追蹤等。相比于RPC調(diào)用，基于http 協(xié)議調(diào)用的rest 方式通過犧牲少量的服務(wù)調(diào)用性能，消除了服務(wù)提供方和調(diào)用方代碼級別的強(qiáng)依賴。并且Spring Cloud 作為Spring 的旗艦項目，它能夠與Spring Framework、Spring Boot 等Spring 項目完美融合。基建管理平臺整合多種業(yè)務(wù)，需要支持多語言，同時為了實現(xiàn)項目的持續(xù)集成、快速交付，服務(wù)內(nèi)部使用統(tǒng)一的技術(shù)框架更有效率，因此選用Spring Cloud作為系統(tǒng)的設(shè)計架構(gòu)。

表1 Spring Cloud和Dubbo功能對照表

2 基建全過程綜合管理系統(tǒng)架構(gòu)設(shè)計

基建平臺采用微服務(wù)微應(yīng)用技術(shù)路線，微服務(wù)基于Spring Cloud 分布式框架開發(fā)，微服務(wù)之間在注冊中心Nacos通過Feign 組件相互調(diào)用，并引入Spring Zuul 和Nginx 組件做負(fù)載均衡處理，Hystrix 處理微服務(wù)調(diào)用降級及熔斷問題，應(yīng)用Redis 做分布式緩存，Kafka 消息隊列做微服務(wù)異步解耦以及消息的訂閱與消費，采用Zookeeper 提升Kafka 的高可用性能，引進(jìn)ElasticSearch 提升平臺的數(shù)據(jù)搜索速度。平臺技術(shù)架構(gòu)采用分層設(shè)計，自下向上分為基礎(chǔ)設(shè)施層、平臺層和應(yīng)用層共三層，系統(tǒng)架構(gòu)圖如圖2所示。

圖2 微服務(wù)架構(gòu)電力基建全過程管理平臺架構(gòu)圖

2.1 應(yīng)用層

PC 應(yīng)用前端開發(fā)采用漸進(jìn)式框架Vue2.x，移動應(yīng)用采用i 國網(wǎng)作為基礎(chǔ)開發(fā)框架。采用HTML5 前端開發(fā)技術(shù)，提供平臺統(tǒng)一工作入口和工作臺，移動應(yīng)用工作臺等，實現(xiàn)直接面向終端用戶的交互界面。

2.2 平臺層

平臺層自上而下分為網(wǎng)關(guān)服務(wù)層、業(yè)務(wù)服務(wù)支撐層和平臺服務(wù)支撐層。網(wǎng)關(guān)服務(wù)層采用Spring Zuul 和Nginx 實現(xiàn)負(fù)載均衡。基建全過程管理平臺后端服務(wù)部署在多臺云服務(wù)器上，使用Nginx 做反向代理，把前端的請求進(jìn)行分發(fā)，多臺服務(wù)器平均分擔(dān)負(fù)載，實現(xiàn)負(fù)載均衡，減輕單臺服務(wù)器的壓力。如圖3所示，Zuul通過一系列的Filter 將整個HTTP 請求過程連成一系列操作來實現(xiàn)對HTTP請求的控制。

圖3 Spring Zuul的處理流程圖

用戶使用瀏覽器打開基建全過程管理平臺，向Spring Zuul 發(fā)出請求，請求被路由之前首先調(diào)用前置過濾器PRE Filter，進(jìn)行身份驗證、資源審查、記錄調(diào)試等操作。然后通過路由后過濾器ROUTER Filter 將請求路由到微服務(wù)實例，緊接著響應(yīng)發(fā)送到后置過濾器POST Filter，為響應(yīng)添加標(biāo)準(zhǔn)的HTTP HEADER、收集統(tǒng)計信息和指標(biāo)，并且把響應(yīng)從微服務(wù)發(fā)送到客戶端。在請求發(fā)送過程中如果發(fā)生錯誤，將會執(zhí)行異常過濾器ERROR Filter。

業(yè)務(wù)服務(wù)支撐層分為職能管理和項目管理。職能管理包含計劃管理服務(wù)、技術(shù)管理服務(wù)、技經(jīng)管理服務(wù)、安全管理服務(wù)、質(zhì)量管理服務(wù)、隊伍管理服務(wù)六大專業(yè)。計劃管理服務(wù)提供項目年度計劃編制、季度預(yù)測、計劃開工在建投產(chǎn)統(tǒng)計等功能，支撐項目整體進(jìn)度情況把控的相關(guān)內(nèi)容。技術(shù)管理服務(wù)提供新技術(shù)新材料成果管理、施工裝備管理、施工圖設(shè)計管理等設(shè)備成果管理服務(wù)，為技術(shù)成果、設(shè)計圖紙、施工裝備信息的錄入、申報、下達(dá)、編制等工作提供支撐。技經(jīng)管理服務(wù)提供項目可研估算管理、施工圖預(yù)算管理、工程結(jié)算管理、農(nóng)民工工資支付等服務(wù)，支持報表的上傳、解析功能。安全管理服務(wù)提供安全檢查管理、作業(yè)票統(tǒng)計、風(fēng)險預(yù)警發(fā)布等功能。質(zhì)量管理服務(wù)提供質(zhì)量檢查分析、標(biāo)準(zhǔn)工藝管理、質(zhì)量驗收分析等功能。隊伍管理服務(wù)提供職能管理隊伍、項目管理隊伍、技術(shù)支撐隊伍、施工骨干隊伍四支隊伍的信息注冊、錄入、審核、查詢功能，同時為基建隊伍專業(yè)能力評價錄入、結(jié)果管理等工作提供支撐。項目管理提供基建項目建設(shè)中的項目前期、工程前期、工程建設(shè)和總結(jié)評價四個階段的信息管理以及流程審批功能。

業(yè)務(wù)服務(wù)層用微服務(wù)微應(yīng)用思想，設(shè)計實現(xiàn)業(yè)務(wù)服務(wù)中心，將基礎(chǔ)全過程管理平臺各項基礎(chǔ)功能拆分為對應(yīng)的微服務(wù)、微應(yīng)用，通過基礎(chǔ)功能微服務(wù)API 互調(diào)用，支撐完整的基建全過程管控需求。按職能管理、項目管理兩條主線，將服務(wù)中心的基礎(chǔ)能力進(jìn)行組合，形成可支撐實際業(yè)務(wù)流程、業(yè)務(wù)功能的各項業(yè)務(wù)服務(wù)，保障業(yè)務(wù)變更的靈活性，支撐上層業(yè)務(wù)需求。

平臺服務(wù)支撐層包括流程服務(wù)、權(quán)限服務(wù)、審計服務(wù)等基礎(chǔ)服務(wù)，保證業(yè)務(wù)流程的正常流轉(zhuǎn)。

2.3 基礎(chǔ)設(shè)施層

結(jié)構(gòu)化數(shù)據(jù)存儲采用MySQL一主多從配置，每個微服務(wù)一個數(shù)據(jù)庫Schema 模式，冷備采用每日全量備份模式，非結(jié)構(gòu)化存儲采用UDS 文件平臺，實現(xiàn)內(nèi)外網(wǎng)文件同步，緩存采用Redis存儲會話、菜單權(quán)限、高頻業(yè)務(wù)操作數(shù)據(jù)等；通過UEP 消息中間件ActiveMQ 和UDS 文件平臺實現(xiàn)數(shù)據(jù)的縱向貫通。

3 基建全過程綜合管理系統(tǒng)實現(xiàn)

3.1 服務(wù)注冊與發(fā)現(xiàn)

微服務(wù)架構(gòu)將復(fù)雜的大型應(yīng)用拆分成了多個高內(nèi)聚、低耦合的小型微服務(wù)，從而實現(xiàn)快速的迭代更新。但是隨著業(yè)務(wù)的擴(kuò)充，微服務(wù)數(shù)量的增多，服務(wù)之間的調(diào)用關(guān)系也越來越復(fù)雜，服務(wù)的維護(hù)成本大大增高。因此引入了服務(wù)注冊中心。服務(wù)注冊和發(fā)現(xiàn)指每個微服務(wù)向注冊中心匯報自己的服務(wù)地址、服務(wù)內(nèi)容、端口和服務(wù)狀態(tài)等信息，當(dāng)有服務(wù)依賴此服務(wù)時，從注冊中心獲取可用的服務(wù)列表并發(fā)起請求，服務(wù)消費者不用關(guān)心服務(wù)所處的位置和狀態(tài)，具體用哪個實例對外提供服務(wù)則由注冊中心決定。目前主流的服務(wù)注冊與發(fā)現(xiàn)產(chǎn)品有Spring Cloud中提供的Eureka和阿里開發(fā)定制的Nacos。

相比于Eureka，Nacos 服務(wù)實例的修改響應(yīng)更快，同時Nacos 集注冊中心與配置中心于一身，方便服務(wù)與配置的統(tǒng)一管理。因此選用Nacos 作為基建管理平臺的注冊中心，注冊原理如圖4所示。

圖4 Nacos注冊原理圖

3.2 微服務(wù)子系統(tǒng)的構(gòu)建

微服務(wù)的開發(fā)基于Spring 全家桶，服務(wù)開發(fā)框架SpringBoot，服務(wù)治理框架Spring Cloud以及持久化框架Mybatis。以計劃管理服務(wù)progress-service 為例說明微服務(wù)子系統(tǒng)的構(gòu)建流程。

（1）使用maven 構(gòu)建項目，在依賴文件pom.xml中添加相關(guān)的依賴，如服務(wù)注冊中心、服務(wù)配置中心nacos-discovery 依賴以及各種服務(wù)模塊。在bootstrap.yml配置文件中配置微服務(wù)的啟動端口server.port，nacos注冊中心的地址，數(shù)據(jù)源配置和mybatis配置等相關(guān)服務(wù)配置。

（2）生成服務(wù)啟動類，用于啟動微服務(wù)。在服務(wù)啟動類上添加@EnableDiscoveryClient 注解，開啟服務(wù)發(fā)現(xiàn)注冊功能，添加@MapperScan 注解，用于掃描DAO 層的接口到容器中。添加@EnableFeignClients 注解，用于啟動feign 客戶端。部分代碼如下：

@SpringBootApplication （scanBasePackages= "com.nariit.emp"）

@MapperScan（"com.nariit.emp.progress.core.mapper"）

@EnableDiscoveryClient

@EnableFeignClients（basePackages="com.nariit.

emp"）

@RefreshScope

@EnableScheduling

public class ProgressApplication ｛

public static void main（String［］args）｛

SpringApplication.run（ProgressApplication.class.args）；

｝

@Bean

public RestTemplate restTemplate（）｛

return new RestTemplate（）；

｝

｝

（3）微服務(wù)相關(guān)接口的開發(fā)，包括DAO 層、service 層、controller 層的開發(fā)。對于遠(yuǎn)程調(diào)用的接口，創(chuàng)建接口時使用@FeignClient 注解，name 中的參數(shù)為注冊在nacos 中的微服務(wù)名稱，接口上的value 為接口的調(diào)用url，別的微服務(wù)調(diào)用計劃管理服務(wù)progress-service，只需要在接口服務(wù)層注入ProgressClient 實例，直接通過方法名即可通過Feign 完成計劃管理服務(wù)的遠(yuǎn)程接口調(diào)用。部分代碼如下：

@FeignClient（name=${progress-service},fallbackFactory=ProgressClientFactory.class）

Public interfaces ProgressClient｛

@PostMapping（value="/progress/demo/getPrjInfoByPrj-Code"）

R＜List＜ProjectInfo＞＞getPrjInfoByPrjCode（String projectId）;

｝

（4）啟動計劃管理微服務(wù)，通過swagger 驗證服務(wù)的可用性。圖5為接口調(diào)用界面。圖6 為progress-service服務(wù)Nacos注冊圖。

圖5 swagger接口驗證界面

圖6 progress-service服務(wù)Nacos注冊圖

3.3 基于微服務(wù)架構(gòu)的基建全過程管理平臺的部署

基建全過程管理平臺部署在自建云環(huán)境。互聯(lián)網(wǎng)邊界部署了邊界防火墻、Web 防火墻、IPS 進(jìn)行安全防護(hù)。自建云內(nèi)外網(wǎng)環(huán)境中包括4個微應(yīng)用、71 個微服務(wù)、22 臺虛擬機(jī)、MySQL主從提供應(yīng)用服務(wù)、接口服務(wù)。系統(tǒng)采用F5 負(fù)載均衡減輕服務(wù)器壓力。MySQL、Redis 和Elasticsearch等數(shù)據(jù)存儲服務(wù)部署在自建云上。

基建全過程管理平臺部署在自建云環(huán)境。互聯(lián)網(wǎng)邊界部署了邊界防火墻、WEB 防火墻、IPS 進(jìn)行安全防護(hù)。自建云內(nèi)外網(wǎng)環(huán)境中包括4個微應(yīng)用、71 個微服務(wù)、22 臺虛擬機(jī)、MySQL主從提供應(yīng)用服務(wù)、接口服務(wù)。系統(tǒng)采用F5 負(fù)載均衡減輕服務(wù)器壓力。MySQL、Redis 和Elasticsearch等數(shù)據(jù)存儲服務(wù)部署在自建云上。

采用Apache Jmeter 對基建全過程管理平臺中的計劃管理微服務(wù)進(jìn)行高并發(fā)性能壓力測試。為了測試的準(zhǔn)確性，選取了計劃管理微服務(wù)中的項目核準(zhǔn)看板接口進(jìn)行壓測，該接口需要遠(yuǎn)程調(diào)用項目管理微服務(wù)提供的項目單項信息查詢接口。測試數(shù)據(jù)如圖7所示。

圖7 Jmeter測試參數(shù)

其中線程數(shù)設(shè)置為2000，Ramp-Up 時間設(shè)置為10s，循環(huán)次數(shù)設(shè)置為20，即模擬在10s 時間內(nèi)，2000 個用戶上線，每個用戶發(fā)送20 個請求，共計40000次請求。高并發(fā)性能壓力測試結(jié)果如圖8所示。詳細(xì)數(shù)據(jù)見表2。

表2 壓測結(jié)果

圖8 Jmeter測試結(jié)果

由結(jié)果可見，基于微服務(wù)架構(gòu)的基建全過程管理平臺在高并發(fā)的情況下，系統(tǒng)的平均響應(yīng)時常大大降低，同時系統(tǒng)的最大響應(yīng)時常相比單體架構(gòu)也有顯著的提升，減少了接口異常的概率。

3.4 基建全過程管理平臺應(yīng)用效果

基建全過程管理平臺微服務(wù)微應(yīng)用技術(shù)體系實現(xiàn)了基建平臺的全過程數(shù)字化管理。圖9為基建管理平臺控制臺首頁，提供平臺功能的總覽以及跳轉(zhuǎn)功能。圖9橫向菜單中的每一個菜單項代表一個單獨的微服務(wù)模塊。以計劃管理微服務(wù)為例，圖10 展示了計劃管理微服務(wù)在職能管理上提供的相關(guān)功能菜單中的季度預(yù)測模塊，展示了2022 年變電、線路季度預(yù)測，開工預(yù)測與投產(chǎn)預(yù)測。圖11 展示了項目管理中的四個階段。由六大業(yè)務(wù)微服務(wù)支撐實現(xiàn)相關(guān)功能。

圖9 基建全過程管理平臺首頁展示

圖10 計劃管理服務(wù)相關(guān)功能

圖11 項目管理相關(guān)功能

4 結(jié)語

本文研究并實現(xiàn)了一套基于微服務(wù)架構(gòu)的基建全過程管理平臺，基于電網(wǎng)基建項目建設(shè)過程管理的實際業(yè)務(wù)需要，把復(fù)雜的業(yè)務(wù)系統(tǒng)拆分成多個微服務(wù)，以微服務(wù)的形式實現(xiàn)了基建平臺內(nèi)各功能模塊之間的高內(nèi)聚、低耦合。計劃管理、技術(shù)管理等專業(yè)功能可獨立地開發(fā)、部署，大大降低了應(yīng)用開發(fā)的門檻和部署的時間，同時保障了業(yè)務(wù)變更的靈活性。為了基建業(yè)務(wù)的安全平穩(wěn)運(yùn)行，在今后的平臺優(yōu)化工作中，會融合人工智能算法做風(fēng)險預(yù)警和安全施工隱患分析，有效規(guī)避施工建設(shè)中可能出現(xiàn)的安全隱患事故和進(jìn)度滯后風(fēng)險。