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

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

0 引言

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

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

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

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

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

1 系統(tǒng)架構技術

1.1 微服務架構技術

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

圖1 微服務架構圖

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

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

表1 Spring Cloud和Dubbo功能對照表

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

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

圖2 微服務架構電力基建全過程管理平臺架構圖

2.1 應用層

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

2.2 平臺層

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

圖3 Spring Zuul的處理流程圖

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

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

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

平臺服務支撐層包括流程服務、權限服務、審計服務等基礎服務，保證業(yè)務流程的正常流轉。

2.3 基礎設施層

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

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

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

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

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

圖4 Nacos注冊原理圖

3.2 微服務子系統(tǒng)的構建

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

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

（2）生成服務啟動類，用于啟動微服務。在服務啟動類上添加@EnableDiscoveryClient 注解，開啟服務發(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）微服務相關接口的開發(fā)，包括DAO 層、service 層、controller 層的開發(fā)。對于遠程調用的接口，創(chuàng)建接口時使用@FeignClient 注解，name 中的參數(shù)為注冊在nacos 中的微服務名稱，接口上的value 為接口的調用url，別的微服務調用計劃管理服務progress-service，只需要在接口服務層注入ProgressClient 實例，直接通過方法名即可通過Feign 完成計劃管理服務的遠程接口調用。部分代碼如下：

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

Public interfaces ProgressClient｛

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

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

｝

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

圖5 swagger接口驗證界面

圖6 progress-service服務Nacos注冊圖

3.3 基于微服務架構的基建全過程管理平臺的部署

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

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

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

圖7 Jmeter測試參數(shù)

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

表2 壓測結果

圖8 Jmeter測試結果

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

3.4 基建全過程管理平臺應用效果

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

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

圖10 計劃管理服務相關功能

圖11 項目管理相關功能

4 結語

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