基于調度云平臺通用分布式架構實踐

鄒文仲，鄧力源，張高峰，王凌梓，章金峰

（1. 南京南瑞繼保電氣有限公司，南京 211102；2. 中國南方電網電力調度控制中心，廣州 510663）

0 引言

近年來，電力系統智能化、數字化不斷發展，云計算、大數據、物聯網等技術給電力行業注入了新的活力，智能電網建設得到了深入推進。伴隨著氣象、低壓配網、分布式新能源等數據接入電網，如何對大規模數據資產進行合理的分析與應用，進一步提高電網數據綜合分析能力和提升電網運行效率，已成為一個重大的研究課題。而云計算平臺因其高效計算能力、動態資源擴展等特點受到了廣泛關注［1-4］。

南方電網“調度云”平臺于2019 年正式上線，其采用阿里云飛天操作系統構建，提供對象存儲（object storage service，OSS）、關系型數據庫（relational database service，RDS）和各類容器編排工具等基礎組件。截至目前，已有調度、科研機構超200 套業務系統在云上運行。受限于對“調度云”平臺理念理解不深，云平臺部署運行的系統中存在單個容器存在多個進程、微服務拆分不合理、未能實現數據持久化等共性問題，這些問題給云平臺整體安全、高效運行帶來了挑戰。同時，云上數據集成類系統中的任務處理、文件存儲、數據庫存儲等核心功能多是集中式部署，此類部署模式資源利用率低、可靠性差、大規模數據處理時易出現瓶頸問題，這使得對調度云中系統標準化部署、大規模數據分布式處理及存取的研究分析成為亟待開展的重要工作。

目前，已有文獻對云平臺系統部署、大規模數據集成處理作了一些研究，文獻［5］利用Hadoop 和數據共享技術設計了一種電力大數據的數據集成平臺；文獻［6-9］介紹了基于云平臺構建的電網狀態監測數據中心及數據治理和數據質量提升方案策略；文獻［10］基于區塊鏈技術提出一種電能量數據分布式采集模式，可以在提高計量設備數據采集效率的前提下保證采集過程數據的安全性；文獻［11］提出基于區塊鏈的分布式電能量數據可信存儲機制，解決了電能量數據中心化存儲安全性和存儲效率低下的問題。可以看出，現階段基于云平臺數據集成的研究主要在數據如何高效計算方面，對于基于云平臺的系統部署、分布式數據處理、文件存儲、數據存儲等鮮有介紹。

為此，本文依據現階段電網調度云實際建設情況構建了一套系統典型架構。首先利用該典型部署架構解決了微服務拆分不合理、數據持久化存儲等共性問題；進而利用分布式任務處理中心、分布式文件存儲、分布式數據庫存儲、分布式業務部署等關鍵技術解決了數據集成系統中大規模數據處理易出現瓶頸的問題。該架構已應用于南方電網調控中心試點項目中，工程應用結果表明，本文所述架構具有數據吞吐量大、資源利用率高、數據處理效率高、存取速度快等特點，具有一定的創新性和行業借鑒性。

1 系統典型架構

1.1 通用數據處理流程

調度云平臺作為大數據背景下面向電網生產、運營環節的大數據解決方案，為區域現貨、負荷預測、電網氣象等系統提供了可靠的技術支撐。調度云系統通用需求服務包括電網海量數據采集、云端多類型數據存儲、云端數據分析和業務應用等，其數據處理流程如圖1所示。

圖1 調度云數據處理流程圖Fig.1 Scheduling cloud data processing flowchart

數據流可分為數據采集、數據存儲、數據分析和業務應用管理等環節。其中數據采集將數量眾多的獨立定時任務耦合成任務處理中心，并采用分布式部署實現任務功能的合理調配，提升數據處理的及時性、可靠性；數據存儲主要包括結構化數據的數據庫存儲及非結構化文件存儲，其數據來源于數據采集環節或數據分析環節；數據分析通過數據分析工具對海量數據源進行深層次智能分析，并將分析結果轉發至數據存儲環節進行存儲；業務應用環節包括前端與后端模塊，實現前后端分離式部署，并對上述步驟的分析結果進行綜合展示及人機交互。

1.2 軟件架構

依據調度云電力氣象系統實際運行環境，分別利用云平臺基礎級IaaS（infrastructure as a service，如RDS數據庫）、平臺級PaaS（platform as a service，如各類容器）、軟件級SaaS（software as a service，如云平臺數據傳輸工具）實現了一套典型業務部署架構。該架構主要解決了單個容器中存在多個進程、微服務拆分不合理、未能實現數據持久化和云平臺組件使用場景錯誤等共性問題。該典型架構對數據采集、數據存儲、數據分析及業務應用等環節采用了全棧分布式架構。其中數據采集采用分布式任務處理中心實現；數據存儲包括分布式文件存儲及分布式數據庫存儲；數據分析及業務應用分布式在業務應用模塊中實現。各應用模塊架構如圖2所示。

圖2 系統典型架構Fig.2 Typical system architecture

系統整體運轉流程是數據處理中心高效、及時處理各類氣象數據，數值類數據存入RDS 數據庫，文件類數據存入OSS，系統所有應用部署在容器中，并利用存儲卷聲明（persistent volume claim，PVC）的方式實現容器與OSS的交互［12-14］。

在數據采集環節，各數據提供商按照規定格式將數據推送至南方電網數據中心互聯網大區，由內外網擺渡平臺將數據轉存至安全Ⅲ區中轉節點，再由中轉節點將數據推送至Ⅲ區調度云。任務處理中心將實況、預報、臺風、山火、數值模式等氣象數據解析處理后轉存至分布式數據庫及OSS中。任務處理中心采用基于微服務的分布式技術架構，可及時依據任務數實現任務處理中心執行器個數的彈性伸縮。

作為任務處理中心的補充，云平臺Cronjob 組件在數據采集環節也發揮了重要作用。Cronjob 適用于大規模并行處理任務或需用獨立鏡像處理數據的場景，如臺風模式預報數據，其在1h 內輸出單個大小為1G、總數量為168個的預報文件，通過配置Cronjob 并行任務數、時間序列等參數，可以在30min內將所有數據處理完畢。

在數據存儲環節，主要包括數據庫存儲及文件存儲。數據庫主要存儲結構化數據，如實況、預報等；文件存儲主要利用OSS實現非結構化文件的存儲，如數值模式預報中各類圖片、中央臺各種文檔產品等。數據庫存儲及文件存儲皆采用分布式技術架構，數據庫的分布式主要體現在基于數據庫代理技術實現分庫分表，如實況信息按月進行了分表存儲，但應用訪問時無需跨表查詢，由代理服務實現了此功能；文件存儲的分布式主要利用元數據理念與OSS實現海量多重異構數文件的快速存取，如數值模式預報每小時近1萬張png圖片。

在數據分析環節，通過數據挖掘及大數據分析技術，對采集到的數據進行校驗清洗、指標計算等。該部分功能集成在業務后端應用中，通過微服務的方式實現分布式部署，并可依據計算量實現彈性伸縮。

在業務應用環節，采用“微服務+微應用”的互聯網技術實現平臺業務應用。微服務主要包括后端模塊，微應用主要包括權限、菜單、審計、網關等前端組件。微服務通過訪問分布式數據庫及各類OSS 提供業務應用接口，微應用基于微服務接口利用多種展示組件構建人機交互的前端應用。業務應用環節整體采用分布式架構，并利用基于消息隊列的單向網絡傳輸技術將業務應用集成在4A 系統中，實現業務全網應用推廣。

此外，系統在VPC（virtual private cloud）環境下構建一個私網流量的出入口，通過自定義SNAT（source network address translation ）和 DNAT（destination network address translation）規則靈活使用網絡資源，實現與云外系統的交互。

2 關鍵技術

為解決云上系統處理大規模數據時資源利用率低、可靠性差、易出現瓶頸等問題，本文分別對任務處理、文件存儲、數據庫存儲、業務部署等核心功能研究探索分布式架構關鍵技術。

2.1 分布式任務處理中心

數據集成類系統核心功能之一是處理錯綜復雜的數據。如何及時、高效地把各類數據處理完畢是提升系統用戶體驗的關鍵。基于服務器自身或開源架構的定時任務處理模式具有版本管理困難、資源易搶占、處理滯后等缺陷［15-18］，因此本文設計了一種分布式、模塊化的任務處理中心。

分布式任務處理中心構建于通用數據服務層，可方便完成對異構數據的增刪改查，快速地對本地及遠程系統數據文件進行操作而無需關心軟件底層實現，為系統提供數據的快速整合能力，架構如圖3所示。

圖3 分布式任務處理中心架構Fig.3 Distributed task processing center architecture

分布式任務處理中心分為注冊中心和任務執行器兩大模塊，注冊中心提供可視化圖形管理工具，負責調度任務的分發、運維、監控。調度任務的分發可自定義調度策略，如輪詢、隨機、指定執行器等，且可以根據實際使用需求開發新策略。本文依據實際使用需求，開發了基于異常任務回收機制的綜合負載調度算法，以解決執行器鏡像更新時執行中任務失敗導致數據缺失以及容器利用率低問題。首先定義執行器容器的綜合負載：

式中：Q為容器的綜合負載；C為CPU 利用率；M為內存利用率；D為磁盤利用率；N為網絡流量。k1、k2、k3、k4為其對應的權重，滿足k1+k2+k3+k4= 1，且ki＞0。合理配置權重可使系統運行在最佳工況，如若待執行任務計算量比較大，對CPU使用率較高，則把k1調高，優先調度到CPU空余多的容器中。其次，執行器鏡像更新時會導致正在執行調度任務異常終止，導致數據處理不完整，影響部分系統功能。為避免此類情況出現，在調度流程中加入了異常任務回收機制，對異常終止的任務重新分配資源調度，整體流程如圖4所示。

圖4 基于異常任務回收機制的綜合負載調度流程Fig.4 Integrated load scheduling process based on exception task recovery mechanism

執行器模塊專注于任務的執行操作，具有良好的可用性、可擴展性。可針對不同的業務或數據源，劃分不同的數據集成模塊，各個模塊間相互獨立，不具備耦合性，單個模塊故障不影響其它業務模塊的正常運行，開發、維護更加的高效。單個模塊內部可配置多個執行器，多執行器分布式部署減輕了單個執行器壓力，也避免了單執行器出現故障后整個業務模塊不可用的情形，提高了整體架構的可用性。

綜上，分布式任務處理架構相較于傳統模式優勢如下。

1） 通用性：支持多種類數據集成及信息轉換。

2） 易維護性：所有任務都集成在統一項目中，版本管理方便，且提供可視化的圖形維護界面，操作更簡單直觀。

3） 及時性：注冊中心提供任務的監控告警功能，根據任務日志和回調結果可以清晰地觀察到任務的執行情況，對執行出現故障的任務，可以通過配置告警，及時通知運維人員處理。

4） 易擴展性：對執行器配置彈性伸縮，根據執行器所在容器的CPU、內存使用情況及時調整執行器個數，避免任務的等待。

2.2 分布式文件存儲

數據集成類項目接入數據龐雜，以電力氣象系統為例，需接入超算中心模式預報、氣象局監測站點、保護大數據、覆冰監測、山火監測和臺風等系統數據，數據類型主要包括Json 數據、Xml 文件和圖片等結構與非結構化數據。結構化數據讀取處理后存入云數據庫，非結構化數據，特別是模式預報數據，每小時有近萬張png 圖片以及近千個grib 氣象專用文件，常規圖片存儲方式已不能滿足要求，故探索研究了基于元數據存儲管理文件索引、OSS存儲數據實體的分布式架構［19-21］。

元數據即描述數據的數據，分為元數據采集、元數據存儲、元數據管理和接口管理等功能。OSS云存儲服務具有安全、高可靠性特點，其提供與調度云無關的Restful API（application programming interface）接口，方便文件的存儲與調用。元數據與OSS 共同實現文件的分布式存儲架構圖如圖5所示。

圖5 分布式文件存儲架構圖Fig.5 Distributed file storage architecture diagram

元數據采集分為手動和自動兩種方式，兩種方式皆通過OSS 接口讀取文件信息完成元數據的更新。元數據的存儲根據實際情況分為公共元數據和實體元數據兩部分。公共元數據是指所有數據都具有的元數據，實體元數據是指根據具體業務數據類型細分出來的元數據。以電力氣象系統業務數據為例，公共元數據主要有：來源、OSS 存儲位置、業務描述、數據更新時間和數據是否解析入庫等。實體元數據以模式預報數據為例，主要有：模式名稱、起報時間、預測時間和氣象要素類型等。采用元數據管理的文件存儲系統將分散、存儲結構差異大的業務數據進行描述、定位、檢索、評估和分析，以描述和分類的形式實現對所有類型數據的格式化，為數據自動處理創造了可能，提升了數據處理及訪問的效率。

OSS 可利用豐富的API、SDK（software development kit ）包和便捷工具進行二次開發。也可以通過控制臺、圖形化工具、命令行工具對OSS進行操作。根據數據場景使用的不同，提供標準、低頻訪問、歸檔和冷歸檔4 種存儲類型，其中標準存儲類型提供高持久、高可用、高性能的對象存儲服務，可作為移動應用、大型網站存儲方式。同時，OSS 還支持生命周期管理，對符合條件的特定數據進行刪除，優化存儲空間。

2.3 分布式數據庫存儲

對于不具備大數據處理技術的云環境，如何存取海量數據是影響系統性能的關鍵。傳統云環境數據庫如Mysql 對存儲容量、讀取速率都有一定的瓶頸，不適用大容量數據的存儲。以電網氣象系統為例，每小時有近1G 的增量數據，以實況氣象信息單表為例，每天數據增量達80 萬條，月數據增量2 000多萬條，傳統存儲模式下，系統運行3個月以上數據讀取速率就開始下降了。

為解決以上問題，傳統做法是數據進行分庫、分表存儲。分庫是指將一個大數據庫分為多個小的數據庫，分表是指用水平切分、垂直切分等方法將一個數據庫表拆分成多個數據庫表，此種方法應用和數據耦合度高，當數據量增加需要對數據庫、表進行擴展時，都需要對應用程序進行改造，風險高、可維護性差［22］。

為此本文設計了一種基于數據代理的分布式存儲方案。它由監控管理、數據庫連接、結果集處理、路由解析和通信協議等模塊組成。當數據量增加，數據庫、表需要擴展時，無需修改應用程序，只需修改中間件配置即可。該代理服務工作原理是攔截應用發過來的SQL，并對SQL 語句作特定分析，如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL傳送至真實數據庫，并對返回結果做適當處理后返給應用。架構如圖6所示。

圖6 數據代理服務架構圖Fig.6 Data broker service architecture diagram

數據代理服務工作流程如下。

1） 配置分庫、分表信息，啟動代理服務時除讀取分庫分表信息外，還會生成所有真實數據庫的datasource緩存池。

2） 客戶端連接數據代理服務，并發送需要執行的SQL語句。

3） 數據庫代理接收到SQL 語句，利用SQL 解析及優化組件完成真實庫表、分片的信息，并把分析的結果連同SQL語句一并送入執行組件。

4） 執行組件按照分析的結果連接對應數據庫執行SQL語句，等待結果返回。

5）執行組件將返回結果發給結果處理模塊進行排序、合并等操作后返給客戶端。

基于數據代理的分布式存儲方案支持多種數據庫類型，易擴展，支持讀寫分離及故障切換。從開發者角度來看，將分表虛擬成一張表，簡化了數據查詢復雜度，提高了開發效率。

2.4 業務系統分布式部署

傳統web 項目前后端放在同一工程項目中，如Spring MVC（model view controller）架構。此種開發模式項目資源耦合程度高、服務器壓力大，一旦宿主服務器故障，系統所有模塊皆不可用，用戶體驗差；此外還存在開發效率低、頁面加載慢等問題，故此種開發模式已逐漸被前后端分離的開發模式替代。本文以前后端分離的開發模式來介紹業務系統分布式部署［23-25］，架構如圖7所示。

圖7 業務系統分布式部署架構Fig.7 Distributed deployment architecture of business system

業務系統分布式部署分為總體分布式以及前后端模塊分布式兩部分。總體分布式是指系統中所有功能模塊如前端、后端、權限、網關、菜單等都是單獨服務、分布式部署，通過網絡服務（service，SVC）實現模塊間相互通信并根據實際需求配置模塊的副本數。前后端模塊分布式是指模塊內程序與服務的分離，前端分布式是指除前端副本數可根據用戶訪問數伸縮外，項目程序文件以PVC方式關聯前端容器，實現了前端程序文件的熱部署；后端分布式是指引入負載預測技術，通過水平伸縮控制器（horizontal pod autoscaler，HPA）實現后端服務的彈性伸縮。

業務系統分布式部署具有如下優勢。

1） 項目整體分布式實現了項目高可用性，不因單個服務器故障導致系統宕機。

2） 前端模塊分布式可依據實時訪問量擴展副本，如按照兩萬訪問量/單個前端副本的規則進行伸縮；同時，Nginx 容器項目目錄通過PVC 方式映射至OSS目錄，系統更新時不必重新制作鏡像及重啟容器，增強了用戶系統體驗及系統可維護性。

3） 后端分布式則采用了彈性伸縮策略。構建了基于Kubernetes 原生自定義指標接口并與HPA 交互完成伸縮，且引入多種預測技術，讓系統提前感知訪問量的變化，做到伸縮先于訪問量，減少系統卡頓。

3 工程應用

上述分布式架構已在南方電網試點項目中部署運行，基于阿里專有云技術，所用Kubernetes 集群為1.7 版本，集群開通了4 個OSS 的訪問權限，數據庫采用RDS數據庫，系統所有模塊皆采用上述分布式部署架構。

3.1 分布式文件存儲性能分析

系統所需分布式存儲的文件主要是模式預報生成的各類圖片文件，每日數據增長約40 G 左右。為驗證分布式存儲性能優勢，本文基于調度云OSS測試了分布式存儲和集中式存儲的性能指標。其中分布式存儲采用2.3 節所述方式，即采用元數據管理模式將文件索引存入RDS庫，文件體存放在OSS中；集中式存儲方式是指對文件不做任何處理采用堆積的方式存入OSS相應文件夾。兩種模式OSS存儲文件內容完全一致，存儲容量為5T，對特定日期的降雨圖片執行查詢、存儲操作，通過多次重復執行程序獲取消耗時間的平均值來代表該項操作的時間。統計結果表明，分布式存儲方式下，單個圖片文件查詢展示及存儲時間分別是95 ms及110 ms，而集中式存儲方式下時間分別是988 ms 及472 ms，查詢展示時間縮減了約90%，存儲時間縮減了約76%，大幅提升了系統數據存儲效率及用戶體驗。

3.2 分布式任務處理中心性能分析

分布式任務處理中心采用單個注冊中心、多任務執行器的配置模式。執行器的個數可根據任務負載情況彈性伸縮，判據為執行器CPU或者內存使用率達到容器分配值的80%，任務調度的算法為本文提出的新調度算法，在容器內部通過系統命令測試了不同任務數下平均負載及網絡響應時間，如圖8所示，并在云管中心監控新調度算法與普通輪詢算法在不同任務數下執行器的個數，如表1所示。

表1 執行器個數對比Tab. 1 Number comparison of actuators

圖8 多執行器下系統性能圖Fig.8 System performance diagram under multiple actuators

結合表1、圖8 可以看出，新調度算法充分發揮每個執行器POD 的性能，在完成相同任務數的前提下，需要的POD 數量更少，更節約資源，在任務數為800、1 300等高負載情況下，分別可節約40%、33%的資源使用量。此外，得益于執行器的分布式及彈性伸縮，隨著任務數的增長，平均負載及網絡響應時間皆保持相對穩定水平，避免了因任務數激增導致的進程卡頓情況出現。

3.3 分布式數據庫存儲性能分析

數據庫存儲采用上述分布式方案，配置3 個數據庫：實況數據庫、預報數據庫、其他數據庫。氣象實況類數據按月進行分表，預報類數據、臺風數據按年進行分表，其他類型數據根據實際情形進行分表。為驗證分布式數據庫存儲的優勢，設計了對比實驗來分析性能優化程度，以數據庫中實況站點跨月查詢統計極值需求為例，實驗組為基于數據代理的分布式存儲方案，即本文介紹的方案，對比組為數據集中式存儲方案，即數據單表存儲。執行相同SQL 語句，通過多次重復執行SQL 獲取消耗時間的平均值來代表不同讀寫次數下消耗時間，對比結果如圖9所示。

圖9 數據庫讀寫性能對比圖Fig.9 Database read/write performance comparison chart

可以看出，基于數據代理的分庫分表技術SQL執行時間在不同讀寫次數工礦下都比單表存儲短，讀寫次數越多，性能提升越明顯，1 000 讀寫次數情形下，實驗組及對比組耗時分別是316 ms、483 ms，耗時減少約35%。

3.4 業務系統分布式部署性能分析

業務系統采用圖5 所示的分布式部署架構，利用公式（2）計算得出近一年系統可用率高達99.8%，相較于傳統集中式部署方式可用率提升近3%。

3.5 應用效果

得益于系統全環節分布式及新任務調度算法的擴展性，目前試點項目南方電網氣象系統在僅有11臺ECS 節點（16 核CPU、32 G 內存）的調度云環境中全面接入了8 000 多個氣象站點、4 套數值模式、南網區域雷達云圖、衛星遙感等氣象數據［26］，系統運行一年半以來，RDS 數據庫存儲容量接近1T，OSS使用容量約5T，在云桌面用瀏覽器查看系統各接口響應時間，統計結果表明數據庫及OSS響應時間均維持在80～420 ms 之間，實現了全網氣象數據的統一采集、存儲及應用。2022年臺風災害天氣期間，系統訪問量激增，高峰時刻約5 000 并發訪問量，而此時在云桌面瀏覽器中多次刷新臺風頁面系統最長響應時間仍保持在2s內，得益于分布式架構優勢，系統保持平穩、高效運行。

4 結論

本文針對調度云環境下分布式架構技術進行分析和研究，取得主要成果如下。

1） 首次將元數據管理技術與調度云組件相結合，提升了調度云環境中大規模非結構化文件的存取速度，平均查詢時間減少了約90%。

2） 首次將數據代理技術與調度云RDS 相結合，提升了高頻數據的存取性能，讀寫次數越多，性能提升越明顯。

3） 提出了基于異常任務回收機制的綜合負載調度算法，解決了分布式任務處理中心因外部操作導致的數據缺失、容器利用率低的問題。

4） 建立了調度云環境中全棧分布式架構，涵蓋數據處理流程全環節，有效提升了數據集成類項目數據處理能力及系統高并發響應能力，具有一定的行業借鑒性。

下一步需在以下兩方面深入研究。

1） 擴展平臺在電網實時監控類系統中的應用，研究基于調度云實時庫、時序庫分布式架構技術。

2） 研究分布式內存技術在調度云環境中的應用，提出分布式內存與分布式存儲優化調度算法，進一步提升系統存儲性能及用戶體驗。