基于調(diào)度云平臺(tái)通用分布式架構(gòu)實(shí)踐

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

（1. 南京南瑞繼保電氣有限公司，南京 211102；2. 中國(guó)南方電網(wǎng)電力調(diào)度控制中心，廣州 510663）

0 引言

近年來，電力系統(tǒng)智能化、數(shù)字化不斷發(fā)展，云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術(shù)給電力行業(yè)注入了新的活力，智能電網(wǎng)建設(shè)得到了深入推進(jìn)。伴隨著氣象、低壓配網(wǎng)、分布式新能源等數(shù)據(jù)接入電網(wǎng)，如何對(duì)大規(guī)模數(shù)據(jù)資產(chǎn)進(jìn)行合理的分析與應(yīng)用，進(jìn)一步提高電網(wǎng)數(shù)據(jù)綜合分析能力和提升電網(wǎng)運(yùn)行效率，已成為一個(gè)重大的研究課題。而云計(jì)算平臺(tái)因其高效計(jì)算能力、動(dòng)態(tài)資源擴(kuò)展等特點(diǎn)受到了廣泛關(guān)注［1-4］。

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

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

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

1 系統(tǒng)典型架構(gòu)

1.1 通用數(shù)據(jù)處理流程

調(diào)度云平臺(tái)作為大數(shù)據(jù)背景下面向電網(wǎng)生產(chǎn)、運(yùn)營(yíng)環(huán)節(jié)的大數(shù)據(jù)解決方案，為區(qū)域現(xiàn)貨、負(fù)荷預(yù)測(cè)、電網(wǎng)氣象等系統(tǒng)提供了可靠的技術(shù)支撐。調(diào)度云系統(tǒng)通用需求服務(wù)包括電網(wǎng)海量數(shù)據(jù)采集、云端多類型數(shù)據(jù)存儲(chǔ)、云端數(shù)據(jù)分析和業(yè)務(wù)應(yīng)用等，其數(shù)據(jù)處理流程如圖1所示。

圖1 調(diào)度云數(shù)據(jù)處理流程圖Fig.1 Scheduling cloud data processing flowchart

數(shù)據(jù)流可分為數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析和業(yè)務(wù)應(yīng)用管理等環(huán)節(jié)。其中數(shù)據(jù)采集將數(shù)量眾多的獨(dú)立定時(shí)任務(wù)耦合成任務(wù)處理中心，并采用分布式部署實(shí)現(xiàn)任務(wù)功能的合理調(diào)配，提升數(shù)據(jù)處理的及時(shí)性、可靠性；數(shù)據(jù)存儲(chǔ)主要包括結(jié)構(gòu)化數(shù)據(jù)的數(shù)據(jù)庫存儲(chǔ)及非結(jié)構(gòu)化文件存儲(chǔ)，其數(shù)據(jù)來源于數(shù)據(jù)采集環(huán)節(jié)或數(shù)據(jù)分析環(huán)節(jié)；數(shù)據(jù)分析通過數(shù)據(jù)分析工具對(duì)海量數(shù)據(jù)源進(jìn)行深層次智能分析，并將分析結(jié)果轉(zhuǎn)發(fā)至數(shù)據(jù)存儲(chǔ)環(huán)節(jié)進(jìn)行存儲(chǔ)；業(yè)務(wù)應(yīng)用環(huán)節(jié)包括前端與后端模塊，實(shí)現(xiàn)前后端分離式部署，并對(duì)上述步驟的分析結(jié)果進(jìn)行綜合展示及人機(jī)交互。

1.2 軟件架構(gòu)

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

圖2 系統(tǒng)典型架構(gòu)Fig.2 Typical system architecture

系統(tǒng)整體運(yùn)轉(zhuǎn)流程是數(shù)據(jù)處理中心高效、及時(shí)處理各類氣象數(shù)據(jù)，數(shù)值類數(shù)據(jù)存入RDS 數(shù)據(jù)庫，文件類數(shù)據(jù)存入OSS，系統(tǒng)所有應(yīng)用部署在容器中，并利用存儲(chǔ)卷聲明（persistent volume claim，PVC）的方式實(shí)現(xiàn)容器與OSS的交互［12-14］。

在數(shù)據(jù)采集環(huán)節(jié)，各數(shù)據(jù)提供商按照規(guī)定格式將數(shù)據(jù)推送至南方電網(wǎng)數(shù)據(jù)中心互聯(lián)網(wǎng)大區(qū)，由內(nèi)外網(wǎng)擺渡平臺(tái)將數(shù)據(jù)轉(zhuǎn)存至安全Ⅲ區(qū)中轉(zhuǎn)節(jié)點(diǎn)，再由中轉(zhuǎn)節(jié)點(diǎn)將數(shù)據(jù)推送至Ⅲ區(qū)調(diào)度云。任務(wù)處理中心將實(shí)況、預(yù)報(bào)、臺(tái)風(fēng)、山火、數(shù)值模式等氣象數(shù)據(jù)解析處理后轉(zhuǎn)存至分布式數(shù)據(jù)庫及OSS中。任務(wù)處理中心采用基于微服務(wù)的分布式技術(shù)架構(gòu)，可及時(shí)依據(jù)任務(wù)數(shù)實(shí)現(xiàn)任務(wù)處理中心執(zhí)行器個(gè)數(shù)的彈性伸縮。

作為任務(wù)處理中心的補(bǔ)充，云平臺(tái)Cronjob 組件在數(shù)據(jù)采集環(huán)節(jié)也發(fā)揮了重要作用。Cronjob 適用于大規(guī)模并行處理任務(wù)或需用獨(dú)立鏡像處理數(shù)據(jù)的場(chǎng)景，如臺(tái)風(fēng)模式預(yù)報(bào)數(shù)據(jù)，其在1h 內(nèi)輸出單個(gè)大小為1G、總數(shù)量為168個(gè)的預(yù)報(bào)文件，通過配置Cronjob 并行任務(wù)數(shù)、時(shí)間序列等參數(shù)，可以在30min內(nèi)將所有數(shù)據(jù)處理完畢。

在數(shù)據(jù)存儲(chǔ)環(huán)節(jié)，主要包括數(shù)據(jù)庫存儲(chǔ)及文件存儲(chǔ)。數(shù)據(jù)庫主要存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)，如實(shí)況、預(yù)報(bào)等；文件存儲(chǔ)主要利用OSS實(shí)現(xiàn)非結(jié)構(gòu)化文件的存儲(chǔ)，如數(shù)值模式預(yù)報(bào)中各類圖片、中央臺(tái)各種文檔產(chǎn)品等。數(shù)據(jù)庫存儲(chǔ)及文件存儲(chǔ)皆采用分布式技術(shù)架構(gòu)，數(shù)據(jù)庫的分布式主要體現(xiàn)在基于數(shù)據(jù)庫代理技術(shù)實(shí)現(xiàn)分庫分表，如實(shí)況信息按月進(jìn)行了分表存儲(chǔ)，但應(yīng)用訪問時(shí)無需跨表查詢，由代理服務(wù)實(shí)現(xiàn)了此功能；文件存儲(chǔ)的分布式主要利用元數(shù)據(jù)理念與OSS實(shí)現(xiàn)海量多重異構(gòu)數(shù)文件的快速存取，如數(shù)值模式預(yù)報(bào)每小時(shí)近1萬張png圖片。

在數(shù)據(jù)分析環(huán)節(jié)，通過數(shù)據(jù)挖掘及大數(shù)據(jù)分析技術(shù)，對(duì)采集到的數(shù)據(jù)進(jìn)行校驗(yàn)清洗、指標(biāo)計(jì)算等。該部分功能集成在業(yè)務(wù)后端應(yīng)用中，通過微服務(wù)的方式實(shí)現(xiàn)分布式部署，并可依據(jù)計(jì)算量實(shí)現(xiàn)彈性伸縮。

在業(yè)務(wù)應(yīng)用環(huán)節(jié)，采用“微服務(wù)+微應(yīng)用”的互聯(lián)網(wǎng)技術(shù)實(shí)現(xiàn)平臺(tái)業(yè)務(wù)應(yīng)用。微服務(wù)主要包括后端模塊，微應(yīng)用主要包括權(quán)限、菜單、審計(jì)、網(wǎng)關(guān)等前端組件。微服務(wù)通過訪問分布式數(shù)據(jù)庫及各類OSS 提供業(yè)務(wù)應(yīng)用接口，微應(yīng)用基于微服務(wù)接口利用多種展示組件構(gòu)建人機(jī)交互的前端應(yīng)用。業(yè)務(wù)應(yīng)用環(huán)節(jié)整體采用分布式架構(gòu)，并利用基于消息隊(duì)列的單向網(wǎng)絡(luò)傳輸技術(shù)將業(yè)務(wù)應(yīng)用集成在4A 系統(tǒng)中，實(shí)現(xiàn)業(yè)務(wù)全網(wǎng)應(yīng)用推廣。

此外，系統(tǒng)在VPC（virtual private cloud）環(huán)境下構(gòu)建一個(gè)私網(wǎng)流量的出入口，通過自定義SNAT（source network address translation ）和 DNAT（destination network address translation）規(guī)則靈活使用網(wǎng)絡(luò)資源，實(shí)現(xiàn)與云外系統(tǒng)的交互。

2 關(guān)鍵技術(shù)

為解決云上系統(tǒng)處理大規(guī)模數(shù)據(jù)時(shí)資源利用率低、可靠性差、易出現(xiàn)瓶頸等問題，本文分別對(duì)任務(wù)處理、文件存儲(chǔ)、數(shù)據(jù)庫存儲(chǔ)、業(yè)務(wù)部署等核心功能研究探索分布式架構(gòu)關(guān)鍵技術(shù)。

2.1 分布式任務(wù)處理中心

數(shù)據(jù)集成類系統(tǒng)核心功能之一是處理錯(cuò)綜復(fù)雜的數(shù)據(jù)。如何及時(shí)、高效地把各類數(shù)據(jù)處理完畢是提升系統(tǒng)用戶體驗(yàn)的關(guān)鍵?；诜?wù)器自身或開源架構(gòu)的定時(shí)任務(wù)處理模式具有版本管理困難、資源易搶占、處理滯后等缺陷［15-18］，因此本文設(shè)計(jì)了一種分布式、模塊化的任務(wù)處理中心。

分布式任務(wù)處理中心構(gòu)建于通用數(shù)據(jù)服務(wù)層，可方便完成對(duì)異構(gòu)數(shù)據(jù)的增刪改查，快速地對(duì)本地及遠(yuǎn)程系統(tǒng)數(shù)據(jù)文件進(jìn)行操作而無需關(guān)心軟件底層實(shí)現(xiàn)，為系統(tǒng)提供數(shù)據(jù)的快速整合能力，架構(gòu)如圖3所示。

圖3 分布式任務(wù)處理中心架構(gòu)Fig.3 Distributed task processing center architecture

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

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

圖4 基于異常任務(wù)回收機(jī)制的綜合負(fù)載調(diào)度流程Fig.4 Integrated load scheduling process based on exception task recovery mechanism

執(zhí)行器模塊專注于任務(wù)的執(zhí)行操作，具有良好的可用性、可擴(kuò)展性?？舍槍?duì)不同的業(yè)務(wù)或數(shù)據(jù)源，劃分不同的數(shù)據(jù)集成模塊，各個(gè)模塊間相互獨(dú)立，不具備耦合性，單個(gè)模塊故障不影響其它業(yè)務(wù)模塊的正常運(yùn)行，開發(fā)、維護(hù)更加的高效。單個(gè)模塊內(nèi)部可配置多個(gè)執(zhí)行器，多執(zhí)行器分布式部署減輕了單個(gè)執(zhí)行器壓力，也避免了單執(zhí)行器出現(xiàn)故障后整個(gè)業(yè)務(wù)模塊不可用的情形，提高了整體架構(gòu)的可用性。

綜上，分布式任務(wù)處理架構(gòu)相較于傳統(tǒng)模式優(yōu)勢(shì)如下。

1） 通用性：支持多種類數(shù)據(jù)集成及信息轉(zhuǎn)換。

2） 易維護(hù)性：所有任務(wù)都集成在統(tǒng)一項(xiàng)目中，版本管理方便，且提供可視化的圖形維護(hù)界面，操作更簡(jiǎn)單直觀。

3） 及時(shí)性：注冊(cè)中心提供任務(wù)的監(jiān)控告警功能，根據(jù)任務(wù)日志和回調(diào)結(jié)果可以清晰地觀察到任務(wù)的執(zhí)行情況，對(duì)執(zhí)行出現(xiàn)故障的任務(wù)，可以通過配置告警，及時(shí)通知運(yùn)維人員處理。

4） 易擴(kuò)展性：對(duì)執(zhí)行器配置彈性伸縮，根據(jù)執(zhí)行器所在容器的CPU、內(nèi)存使用情況及時(shí)調(diào)整執(zhí)行器個(gè)數(shù)，避免任務(wù)的等待。

2.2 分布式文件存儲(chǔ)

數(shù)據(jù)集成類項(xiàng)目接入數(shù)據(jù)龐雜，以電力氣象系統(tǒng)為例，需接入超算中心模式預(yù)報(bào)、氣象局監(jiān)測(cè)站點(diǎn)、保護(hù)大數(shù)據(jù)、覆冰監(jiān)測(cè)、山火監(jiān)測(cè)和臺(tái)風(fēng)等系統(tǒng)數(shù)據(jù)，數(shù)據(jù)類型主要包括Json 數(shù)據(jù)、Xml 文件和圖片等結(jié)構(gòu)與非結(jié)構(gòu)化數(shù)據(jù)。結(jié)構(gòu)化數(shù)據(jù)讀取處理后存入云數(shù)據(jù)庫，非結(jié)構(gòu)化數(shù)據(jù)，特別是模式預(yù)報(bào)數(shù)據(jù)，每小時(shí)有近萬張png 圖片以及近千個(gè)grib 氣象專用文件，常規(guī)圖片存儲(chǔ)方式已不能滿足要求，故探索研究了基于元數(shù)據(jù)存儲(chǔ)管理文件索引、OSS存儲(chǔ)數(shù)據(jù)實(shí)體的分布式架構(gòu)［19-21］。

元數(shù)據(jù)即描述數(shù)據(jù)的數(shù)據(jù)，分為元數(shù)據(jù)采集、元數(shù)據(jù)存儲(chǔ)、元數(shù)據(jù)管理和接口管理等功能。OSS云存儲(chǔ)服務(wù)具有安全、高可靠性特點(diǎn)，其提供與調(diào)度云無關(guān)的Restful API（application programming interface）接口，方便文件的存儲(chǔ)與調(diào)用。元數(shù)據(jù)與OSS 共同實(shí)現(xiàn)文件的分布式存儲(chǔ)架構(gòu)圖如圖5所示。

圖5 分布式文件存儲(chǔ)架構(gòu)圖Fig.5 Distributed file storage architecture diagram

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

OSS 可利用豐富的API、SDK（software development kit ）包和便捷工具進(jìn)行二次開發(fā)。也可以通過控制臺(tái)、圖形化工具、命令行工具對(duì)OSS進(jìn)行操作。根據(jù)數(shù)據(jù)場(chǎng)景使用的不同，提供標(biāo)準(zhǔn)、低頻訪問、歸檔和冷歸檔4 種存儲(chǔ)類型，其中標(biāo)準(zhǔn)存儲(chǔ)類型提供高持久、高可用、高性能的對(duì)象存儲(chǔ)服務(wù)，可作為移動(dòng)應(yīng)用、大型網(wǎng)站存儲(chǔ)方式。同時(shí)，OSS 還支持生命周期管理，對(duì)符合條件的特定數(shù)據(jù)進(jìn)行刪除，優(yōu)化存儲(chǔ)空間。

2.3 分布式數(shù)據(jù)庫存儲(chǔ)

對(duì)于不具備大數(shù)據(jù)處理技術(shù)的云環(huán)境，如何存取海量數(shù)據(jù)是影響系統(tǒng)性能的關(guān)鍵。傳統(tǒng)云環(huán)境數(shù)據(jù)庫如Mysql 對(duì)存儲(chǔ)容量、讀取速率都有一定的瓶頸，不適用大容量數(shù)據(jù)的存儲(chǔ)。以電網(wǎng)氣象系統(tǒng)為例，每小時(shí)有近1G 的增量數(shù)據(jù)，以實(shí)況氣象信息單表為例，每天數(shù)據(jù)增量達(dá)80 萬條，月數(shù)據(jù)增量2 000多萬條，傳統(tǒng)存儲(chǔ)模式下，系統(tǒng)運(yùn)行3個(gè)月以上數(shù)據(jù)讀取速率就開始下降了。

為解決以上問題，傳統(tǒng)做法是數(shù)據(jù)進(jìn)行分庫、分表存儲(chǔ)。分庫是指將一個(gè)大數(shù)據(jù)庫分為多個(gè)小的數(shù)據(jù)庫，分表是指用水平切分、垂直切分等方法將一個(gè)數(shù)據(jù)庫表拆分成多個(gè)數(shù)據(jù)庫表，此種方法應(yīng)用和數(shù)據(jù)耦合度高，當(dāng)數(shù)據(jù)量增加需要對(duì)數(shù)據(jù)庫、表進(jìn)行擴(kuò)展時(shí)，都需要對(duì)應(yīng)用程序進(jìn)行改造，風(fēng)險(xiǎn)高、可維護(hù)性差［22］。

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

圖6 數(shù)據(jù)代理服務(wù)架構(gòu)圖Fig.6 Data broker service architecture diagram

數(shù)據(jù)代理服務(wù)工作流程如下。

1） 配置分庫、分表信息，啟動(dòng)代理服務(wù)時(shí)除讀取分庫分表信息外，還會(huì)生成所有真實(shí)數(shù)據(jù)庫的datasource緩存池。

2） 客戶端連接數(shù)據(jù)代理服務(wù)，并發(fā)送需要執(zhí)行的SQL語句。

3） 數(shù)據(jù)庫代理接收到SQL 語句，利用SQL 解析及優(yōu)化組件完成真實(shí)庫表、分片的信息，并把分析的結(jié)果連同SQL語句一并送入執(zhí)行組件。

4） 執(zhí)行組件按照分析的結(jié)果連接對(duì)應(yīng)數(shù)據(jù)庫執(zhí)行SQL語句，等待結(jié)果返回。

5）執(zhí)行組件將返回結(jié)果發(fā)給結(jié)果處理模塊進(jìn)行排序、合并等操作后返給客戶端。

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

2.4 業(yè)務(wù)系統(tǒng)分布式部署

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

圖7 業(yè)務(wù)系統(tǒng)分布式部署架構(gòu)Fig.7 Distributed deployment architecture of business system

業(yè)務(wù)系統(tǒng)分布式部署分為總體分布式以及前后端模塊分布式兩部分。總體分布式是指系統(tǒng)中所有功能模塊如前端、后端、權(quán)限、網(wǎng)關(guān)、菜單等都是單獨(dú)服務(wù)、分布式部署，通過網(wǎng)絡(luò)服務(wù)（service，SVC）實(shí)現(xiàn)模塊間相互通信并根據(jù)實(shí)際需求配置模塊的副本數(shù)。前后端模塊分布式是指模塊內(nèi)程序與服務(wù)的分離，前端分布式是指除前端副本數(shù)可根據(jù)用戶訪問數(shù)伸縮外，項(xiàng)目程序文件以PVC方式關(guān)聯(lián)前端容器，實(shí)現(xiàn)了前端程序文件的熱部署；后端分布式是指引入負(fù)載預(yù)測(cè)技術(shù)，通過水平伸縮控制器（horizontal pod autoscaler，HPA）實(shí)現(xiàn)后端服務(wù)的彈性伸縮。

業(yè)務(wù)系統(tǒng)分布式部署具有如下優(yōu)勢(shì)。

1） 項(xiàng)目整體分布式實(shí)現(xiàn)了項(xiàng)目高可用性，不因單個(gè)服務(wù)器故障導(dǎo)致系統(tǒng)宕機(jī)。

2） 前端模塊分布式可依據(jù)實(shí)時(shí)訪問量擴(kuò)展副本，如按照兩萬訪問量/單個(gè)前端副本的規(guī)則進(jìn)行伸縮；同時(shí)，Nginx 容器項(xiàng)目目錄通過PVC 方式映射至OSS目錄，系統(tǒng)更新時(shí)不必重新制作鏡像及重啟容器，增強(qiáng)了用戶系統(tǒng)體驗(yàn)及系統(tǒng)可維護(hù)性。

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

3 工程應(yīng)用

上述分布式架構(gòu)已在南方電網(wǎng)試點(diǎn)項(xiàng)目中部署運(yùn)行，基于阿里專有云技術(shù)，所用Kubernetes 集群為1.7 版本，集群開通了4 個(gè)OSS 的訪問權(quán)限，數(shù)據(jù)庫采用RDS數(shù)據(jù)庫，系統(tǒng)所有模塊皆采用上述分布式部署架構(gòu)。

3.1 分布式文件存儲(chǔ)性能分析

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

3.2 分布式任務(wù)處理中心性能分析

分布式任務(wù)處理中心采用單個(gè)注冊(cè)中心、多任務(wù)執(zhí)行器的配置模式。執(zhí)行器的個(gè)數(shù)可根據(jù)任務(wù)負(fù)載情況彈性伸縮，判據(jù)為執(zhí)行器CPU或者內(nèi)存使用率達(dá)到容器分配值的80%，任務(wù)調(diào)度的算法為本文提出的新調(diào)度算法，在容器內(nèi)部通過系統(tǒng)命令測(cè)試了不同任務(wù)數(shù)下平均負(fù)載及網(wǎng)絡(luò)響應(yīng)時(shí)間，如圖8所示，并在云管中心監(jiān)控新調(diào)度算法與普通輪詢算法在不同任務(wù)數(shù)下執(zhí)行器的個(gè)數(shù)，如表1所示。

表1 執(zhí)行器個(gè)數(shù)對(duì)比Tab. 1 Number comparison of actuators

圖8 多執(zhí)行器下系統(tǒng)性能圖Fig.8 System performance diagram under multiple actuators

結(jié)合表1、圖8 可以看出，新調(diào)度算法充分發(fā)揮每個(gè)執(zhí)行器POD 的性能，在完成相同任務(wù)數(shù)的前提下，需要的POD 數(shù)量更少，更節(jié)約資源，在任務(wù)數(shù)為800、1 300等高負(fù)載情況下，分別可節(jié)約40%、33%的資源使用量。此外，得益于執(zhí)行器的分布式及彈性伸縮，隨著任務(wù)數(shù)的增長(zhǎng)，平均負(fù)載及網(wǎng)絡(luò)響應(yīng)時(shí)間皆保持相對(duì)穩(wěn)定水平，避免了因任務(wù)數(shù)激增導(dǎo)致的進(jìn)程卡頓情況出現(xiàn)。

3.3 分布式數(shù)據(jù)庫存儲(chǔ)性能分析

數(shù)據(jù)庫存儲(chǔ)采用上述分布式方案，配置3 個(gè)數(shù)據(jù)庫：實(shí)況數(shù)據(jù)庫、預(yù)報(bào)數(shù)據(jù)庫、其他數(shù)據(jù)庫。氣象實(shí)況類數(shù)據(jù)按月進(jìn)行分表，預(yù)報(bào)類數(shù)據(jù)、臺(tái)風(fēng)數(shù)據(jù)按年進(jìn)行分表，其他類型數(shù)據(jù)根據(jù)實(shí)際情形進(jìn)行分表。為驗(yàn)證分布式數(shù)據(jù)庫存儲(chǔ)的優(yōu)勢(shì)，設(shè)計(jì)了對(duì)比實(shí)驗(yàn)來分析性能優(yōu)化程度，以數(shù)據(jù)庫中實(shí)況站點(diǎn)跨月查詢統(tǒng)計(jì)極值需求為例，實(shí)驗(yàn)組為基于數(shù)據(jù)代理的分布式存儲(chǔ)方案，即本文介紹的方案，對(duì)比組為數(shù)據(jù)集中式存儲(chǔ)方案，即數(shù)據(jù)單表存儲(chǔ)。執(zhí)行相同SQL 語句，通過多次重復(fù)執(zhí)行SQL 獲取消耗時(shí)間的平均值來代表不同讀寫次數(shù)下消耗時(shí)間，對(duì)比結(jié)果如圖9所示。

圖9 數(shù)據(jù)庫讀寫性能對(duì)比圖Fig.9 Database read/write performance comparison chart

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

3.4 業(yè)務(wù)系統(tǒng)分布式部署性能分析

業(yè)務(wù)系統(tǒng)采用圖5 所示的分布式部署架構(gòu)，利用公式（2）計(jì)算得出近一年系統(tǒng)可用率高達(dá)99.8%，相較于傳統(tǒng)集中式部署方式可用率提升近3%。

3.5 應(yīng)用效果

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

4 結(jié)論

本文針對(duì)調(diào)度云環(huán)境下分布式架構(gòu)技術(shù)進(jìn)行分析和研究，取得主要成果如下。

1） 首次將元數(shù)據(jù)管理技術(shù)與調(diào)度云組件相結(jié)合，提升了調(diào)度云環(huán)境中大規(guī)模非結(jié)構(gòu)化文件的存取速度，平均查詢時(shí)間減少了約90%。

2） 首次將數(shù)據(jù)代理技術(shù)與調(diào)度云RDS 相結(jié)合，提升了高頻數(shù)據(jù)的存取性能，讀寫次數(shù)越多，性能提升越明顯。

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

4） 建立了調(diào)度云環(huán)境中全棧分布式架構(gòu)，涵蓋數(shù)據(jù)處理流程全環(huán)節(jié)，有效提升了數(shù)據(jù)集成類項(xiàng)目數(shù)據(jù)處理能力及系統(tǒng)高并發(fā)響應(yīng)能力，具有一定的行業(yè)借鑒性。

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

1） 擴(kuò)展平臺(tái)在電網(wǎng)實(shí)時(shí)監(jiān)控類系統(tǒng)中的應(yīng)用，研究基于調(diào)度云實(shí)時(shí)庫、時(shí)序庫分布式架構(gòu)技術(shù)。

2） 研究分布式內(nèi)存技術(shù)在調(diào)度云環(huán)境中的應(yīng)用，提出分布式內(nèi)存與分布式存儲(chǔ)優(yōu)化調(diào)度算法，進(jìn)一步提升系統(tǒng)存儲(chǔ)性能及用戶體驗(yàn)。