智慧配電網輔助規劃平臺分布式計算數據通信實現方法

朱佳明 王浩國 方燁陽 楊金濤 楊松坤 吳 倩

（1.國網浙江省電力有限公司杭州市錢塘區供電公司 2.天地電研（北京）科技有限公司）

0 引言

配電網規劃軟件平臺對于實現智慧配電網智能輔助規劃十分重要。配電網規劃要求獲取電網的現狀態數據和規劃態數據。現狀態數據包括電網模型信息、一次設備的電氣參數、連接關系以及二次設備的配置和臺賬數據。規劃狀態數據是根據多元負荷預測和分布式電源歷史運行數據合理預測得出的未來年份配電網數據。在配電網規劃業務中，除了大量計算所需的數據之外，還需要大量的地理接線圖數據和拓撲圖數據。這些數據來自不同系統，需要解決系統之間的數據通信問題。另外，配電網的規模龐大，規劃離不開各種輔助計算，如拓撲計算，潮流計算等，計算過程需要處理大量的節點，耗費時間長；如果計算速度慢，將無法滿足規劃工作的需求。

可見，輔助規劃平臺的設計要想達到大范圍工程化實用的目的，需要進行分布式架構設計并解決大規模節點快速計算的問題。目前主流的分布式設計架構[1-4]通常基于微服務架構、容器化部署、消息隊列和事件驅動等技術，將多種技術組合在一起，能夠構建高效、可伸縮和可靠的分布式計算服務系統，以滿足大規模系統或平臺的應用需求[5-10]。

為此，本文提出一種基于RabbitMQ 消息中間件的分布式計算架構，以有效支撐智慧配電網輔助規劃平臺業務應用的信息交互和快速計算。本文開展的工作為采用RabbitMQ 消息中間件作為平臺通信架構基礎，以解決跨機器和跨系統之間的異構系統數據交互的問題。該架構具備可伸縮、可擴展和負載均衡性，即使在單點故障情況下，仍能支持基于數據級任務分解的分布式計算。數據交互和模塊協同均通過消息傳遞實現；另外，為滿足規劃業務的具體需求，還設計了一種可擴展的通信數據格式以支持多類型的消息傳輸。

1 數據通信實現

1.1 RabbitMQ 技術

RabbitMQ 是一款強大的面向消息的中間件，適用于復雜的全局拓撲和消息路由。獨立于傳輸協議，可在不同網絡和傳輸層協議上運行；其套接字能夠感知路由和網絡拓撲，通過交換機和綁定定義消息路由，可實現消息的精確控制[11-13]。

其構成實體中，Exchange（交換機）用于接收消息并將其路由到一個或多個隊列中。Queue（隊列）用于存儲消息，接收任務或消息。Consumer（消費者）是訂閱隊列的應用程序，用于從隊列中接收和處理消息。Producer（生產者）是發布消息到Exchange的應用程序。RabbitMQ 可通過使用不同類型的隊列和交換機來實現不同的Request/Response（請求/響應）模式。

分布式快速計算需要高吞吐量的消息傳遞和隊列管理以支持任務分發、并行計算和結果匯總等操作。因此，本文使用AMQP 套接字用于應用程序之間的通信，選擇WebSockets 套接字用于Web 應用程序與服務器之間的通信。

1.2 通信架構設計

根據智慧配電網規劃系統的業務功能需求，輔助規劃平臺由客戶端、服務實例、執行進程、管理模塊4個部分組成[14-15]，與輔助規劃平臺進行數據交互的系統為外部數據源。平臺內部及外部數據源均通過RabbitMQ 消息中間件進行數據交換。

信息交互圖如圖1 所示，客戶端主要功能包括后臺服務的啟停管理、計算參數設置、計算請求發起、計算結果展示。外部數據源為電網資源業務中臺和數據中臺，提供電網模型數據、年份斷面數據、臺賬數據等。管理模塊包含負載均衡中間件和實例心跳監測模塊，負責任務和數據的全局負載均衡、服務實例的心跳管理、后臺服務管理等；還負責計算任務切分、計算結果回收等。服務實例是基于Redis 內存數據庫的數據平臺，支持符合公共信息模型（CIM 2.0）文件導入，可向外部數據源請求所需時間斷面的電網數據、接收外部數據源推送的動態更新準實時數據。執行進程是包含若干算法模塊的程序，如分布式電源出力概率性分析、源網荷儲一體化平衡計算等。

圖1 輔助規劃系統信息交互圖

實際部署時，可配置多臺輔助規劃服務器，每臺服務器分別部署1 個管理模塊（Master）、若干個服務實例、若干個執行進程、若干個輔助規劃客戶端，分布式快速計算通信架構設計如圖2 所示。

圖2 分布式通信架構

圖2 中，智慧配電網輔助規劃平臺服務器集群的初始化、計算任務請求的數據流向以及配合關系如下：

1）客戶端通過Exchange 向服務實例發起計算請求，啟動服務實例，并可獲取可用服務實例信息。

2）服務實例在啟動后首先必須向Master 管理模塊“注冊”自己的信息，包括所在機器的IP、綁定的端口號等。注冊后，所有實例和Master 管理模塊進行心跳互測。服務實例注冊成功后再通過Response-Request 從電網資源業務中臺或數據中臺主動請求電網數據，通過Producer-Queue/Consumer 接收地理接線圖/ 臺賬變化更新數據，初始化電網模型數據（CIM）、配網地理接線圖形數據（GIS）及各類設備臺賬數據后，服務實例還將任務切分生成子任務及計算所需數據集以完成任務分解，隨后子任務和數據集被推送至并列運行的管理模塊。

3）Master 管理模塊通過Producer-Queue/Consumer將子任務均衡派發給各個執行進程，并監視各執行進程的心跳信息。

4）執行端啟動后先從Master 管理模塊獲取服務實例綁定信息，再連接至服務實例完成初始化；然后按照自身獲得的子任務業務類型調用相應算法模塊進行計算，計算完畢后通過Producer-Queue/Consumer返回給對應的服務實例。

5）服務實例在子任務結果收集完畢后進行結果組裝，并將結果寫入數據庫后通知客戶端計算完畢。

6） 客戶端可以通過Master 管理模塊對后臺服務程序進行管控，通過Response-Request 向管理模塊發送啟、停信號，管理模塊判斷服務實例狀態之后可對實例進行啟停操作。

1.3 通信模式選擇

根據規劃業務的需求使用不同的隊列和交換機組合來實現以下各類消息的通信模式：

1）設備發現消息（discovery/hello 消息）是簡單的一對一通信，用于建立基本的連接，選取交換機類型為直接交換機。方法是創建一個簡單的隊列（discovery/hello _queue），發送discovery/hello 消息的應用程序將消息發布到discovery_queue 隊列，接收discovery/hello 消息的應用程序訂閱并從此隊列中接收消息。

2）控制消息使用自定義消息格式來定義，包含指令或控制信息的數據，需要特定的路由規則，因此選取交換機類型為主題交換機。發送控制消息的應用程序將消息發布到特定的主題交換機或隊列，以便接收方可以按需訂閱并處理這些消息。

3）連接請求/回復消息是建立通信連接的一部分，需要精確的路由，選取交換機類型為直接交換機或隊列。發送連接請求的應用程序將連接請求消息發布到一個直接交換機或隊列，服務器應用程序訂閱并接收連接請求消息，然后發送連接回復消息以響應連接請求。

4）同步消息使用請求/響應模式中，客戶端發送請求消息，服務器接收并處理請求并發送響應消息，需要兩者之間匹配以實現同步通信，選擇直接交換機或主題交換機類型，使用專門的隊列或交換機來處理同步請求和響應。

5）心跳及回復用于維持連接的活躍狀態，需要廣播給所有連接設備，因此選用的交換機類型為扇出交換機。心跳消息定期發送到一個專用的隊列或交換機，以保持連接的活躍狀態；接收端定期檢查心跳隊列并響應心跳消息。

6）服務管理請求/回復用于管理和監控系統狀態，使用自定義消息格式，包括管理命令和操作，使用特定的路由規則，因此選用的交換機類型為主題交換機。發送管理請求的應用程序將請求消息發布到管理隊列，接收方接收并處理請求，然后發送回復消息以響應管理操作。

1.4 消息格式設計

在配電網輔助規劃平臺中，所有功能模塊之間的配合與數據交互都是基于消息的，合理的通信消息格式設計非常重要。圖3 為通信消息通用格式，由消息幀頭、消息體、附加信息3 部分組成。

圖3 通信消息格式

消息幀頭用于確保消息的正確處理和路由。其中，幀類型用于標識消息幀的類型，表示這是一個方法幀、請求幀或心跳幀等。規劃平臺中各類高級應用或計算大部分屬于方法幀，例如各類計算及結果返回、出錯處理、啟停控制、數據更新等。通道號表示消息幀所屬的通道號，用于多通道復用。幀大小表示消息幀的長度，以字節為單位。消息類別用于標識消息的類別，如連接、通道、交換機、隊列等。方法ID用于標識執行的具體方法，與消息類別相關聯。

消息體包含需要傳遞的實際數據內容。其中，消息標識符是消息ID，用于消息的唯一性檢查。消息屬性提供了消息的類型、優先級、時間戳、編碼方式等。消息的附加信息通常包含在消息屬性中：消息類型代表消息的類型或用途；消息優先級允許接收端根據消息的重要性或緊急性來優先處理消息；時間戳是消息創建時的時間；消息過期時間指定消息的有效期限；消息編碼方式指定消息內容的編碼方式，本文采用UTF-8 編碼方式；消息內容類型指示消息內容的類型，本文使用JSON 或XML 方式；關聯ID 用于關聯請求和響應消息，在請求消息和響應消息之間傳遞相同的關聯ID；回復隊列指示接收端可以將響應消息發送到的隊列，用于實現請求-響應模式；消息持久性指示消息是否持久化，本文選用持久化方式；用戶ID 指示發送消息的用戶或應用程序的標識符。消息內容是消息的主要數據內容，本文采用文本、JSON 或XML 格式，消息的實際有效載荷就存在于消息內容中，用于傳遞應用程序所需的信息。

附加信息并不是必需的，可根據應用程序需求按需配置。

discovery/hello 消息是AMQP 協議握手的一部分，心跳消息、連接請求/回復消息、同步消息均由RabbitMQ 自動處理，無需用戶干預。需要用戶自行定義消息格式的是控制消息和服務管理請求/回復消息，本文所設計消息格式如下：

（1）控制消息包含指令或控制信息，使用JSON對象描述，包含命令類型和相關參數。

定義其以十六進制表示的幀頭信息為：[0x01][0x03] [0x01] [0x0018] [0x03E8] [0x000A]，幀起始標識0x01 代表消息幀的起始；幀類型0x03 表示這是一個內容幀（Content Frame）；通道號0x01 指示消息幀所屬的通道號；幀大小0x0018 表示整個消息幀的大小為24 字節；消息類別0x03E8 表示這是一個控制消息類別；方法ID0x000A 表示這是控制消息類別中的具體方法。

消息體格式為：

{

"消息標識符"："message_12345"，

"目標設備"："device_1"，

"消息屬性"：{

"命令類型"："balance_calc"，

"參數1"："value1"，

"參數2"："value2"

……

}，

"消息內容"："源網荷儲一體化平衡計算"

}

（2）服務管理/請求消息包含管理命令和相關參數，服務管理回復消息包含執行結果。

以管理模塊查看某執行端的服務管理請求消息為例進行說明，定義其以十六進制表示的幀頭信息為：[0x1] [0x15] [0x11] [0x0028] [0x04F8] [0x001A]，幀類型0x15 表示這是一個方法幀；消息類別0x04F8 表示這是一個服務請求消息類別；方法ID0x001A 表示這是服務請求消息類別中的方法，1 表示啟動服務，2 表示停止服務。

消息體按以下方式構建：

{

"命令"："process.start"，

"服務名稱"：XXX，

"參數項"：{

" process_name"："XXXX"， // 進程名稱

" process_id "："XXXX"， // 進程ID

"operation"：start， // 操作類型

}

}

其余的控制消息和服務管理請求/回復類消息均需按照協議規范和操作流程要求構建消息幀頭和消息體，以確保消息格式正確、協議符合要求。需要注意的是，消息格式不是一成不變的，可根據需求進行擴展和修改。

1.5 可伸縮性和健壯性設計

各功能模塊間相互配合，通過消息中間件不同套接字的配合使整個分布式系統具備可伸縮性和健壯性。

1）架構可伸縮性設計

部署前，用戶可根據需求配置Master 管理模塊、服務實例個數，執行進程和客戶端可任意部署；部署后，Master 管理模塊、服務實例、執行進程均可動態增減。

Master 管理模塊使用AMQP 套接字和消息隊列實現服務實例的任務分發和負載均衡。通過配置心跳檢測，定期向服務實例發送心跳請求，如果服務實例未能響應，則將其標記為斷開連接。當有一個或幾個實例發生異常，管理模塊會通知所有執行進程實例發生變化的消息，執行進程隨后刷新連接，從而達到系統運行時計算服務實例動態增刪、執行進程動態連接的目的。

另外，發布-訂閱模式使用扇出交換機，將消息廣播給多個綁定的隊列，使多個消費者訂閱相同的消息流。復雜的消息路由和篩選使用主題交換機，生產者根據消息主題發布消息，消費者使用通配符訂閱感興趣的消息，使不同消費者接收特定類型的消息。使用負載均衡器確保系統能夠處理大量消息流和連接流，以應對不斷增長的負載。

2）架構健壯性設計

由于采用異步的方式處理消息，可能出現任務丟失、結果未按時回收的情況，故每個執行進程在收到Master 管理模塊派發的任務后，首先通過“同步消息”與管理模塊同步。如果管理模塊探測到某個執行進程在規定的時間內3 次均未同步成功，則刪除此執行進程，并重啟另一個進程，將未派出的子任務重新派發給新的執行進程。如果多個執行進程在規定的時間內3 次均未與某個管理模塊同步成功，則認為此管理模塊故障，自動同步至其他管理模塊，向同步成功的管理模塊重新注冊，接收并回應其發出的心跳請求。還配置有消息重試策略以處理由于臨時問題而失敗的消息，將無法處理的消息發送到死信隊列，以便稍后進行分析和處理。

另外，實施限流策略防止消息發送者過快地向消息代理（RabbitMQ 服務器）發送消息，導致系統不穩定。通過建立RabbitMQ 服務器集群以確保消息代理的高可用性，如果一個節點失敗，其他節點仍可繼續處理消息，避免單點故障。最后，使用備份還原機制還原消息代理的狀態，并在災難恢復時提供支持。

2 應用實例

以某縣級市項目為例驗證實際運用的結果。

（1）數據交互性能測試

配置16 臺PC 機及千兆交換機測試大數據架構的通信性能，操作系統為Win 10，CPU 型號為Intel（R） Xeon（R） CPU E5-2643 v4 @ 3.40GHz；內存為DDR4 128G，內存帶寬為85.2GB/s；硬盤型號為INTEL SSDSC2KB480GB，容量為5T，硬盤帶寬為 SATA 3.2 - 6.0GB/s。RabbitMQ 消息中間件版本為3.12.8，內存數據庫為Redis。該縣級市配電網包含87 個供電網格、14876 個節點。大數據塊情況下的數據交互性能測試結果如圖4 所示。

圖4 大數據塊通信速率測試

由圖4 可知，當規劃平臺進行大數據塊通信時，隨著數據塊的增大其通信速率快速上升，當數據塊大小超過8.7×103kB 時，通信速率接近局域網通信上限。

圖5 顯示了大量小數據頻繁交互時架構的通信性能，其中單個數據塊大小為1000kB。圖5 中通信時間隨著交互次的增加而線性增加，說明在頻繁交互時仍能保持較好的穩定性。

圖5 小數據塊頻繁交互測試

（2）功能模塊工程實測

本文以碳排計算、潮流計算和源網荷儲各要素時序仿真計算為例，測試復雜度不同的任務在分布式環境下的通信和計算速度效果。

由于全斷面數據獲取由配電網輔助規劃平臺觸發，因此，測試時包括了請求消息通信時間和數據中臺、電網資源業務中臺準備數據時間。系統全斷面數據初始化可在3s 內完成，動態更新時間為毫秒級，可以滿足規劃業務的需求。

圖6 顯示了不同復雜度算法和在分布式集群規模下的通信用時與計算用時分布圖。

圖6 不同算法不同規模的用時分布

隨著分布式集群規模的不斷增大，碳排計算功能模塊總計算時間維持在2s 以內。潮流計算、源網荷儲各要素時序仿真計算的計算時間隨著執行端規模的增大顯著減少，由串行的1.2h 降至10s 以下，潮流計算的計算時間由串行的近60s 降至8s。

通過分析不同算法不同規模的用時分布可知，碳排計算算法簡單，單個任務計算時間短，多執行端并行計算時加速效果不明顯；全網潮流計算、源網荷儲各要素時序仿真計算的算法較為復雜，串行計算時時間開銷大。采用分布式并行計算后，可并行化計算項包括源、網、荷、儲各部分的計算，不可并行化計算項包括全系統運行模擬、計算任務請求、子任務分發、結果回收、通知客戶端的通信代價，以及任務分解、數據準備、結果組裝、結果寫庫等操作。例如，全系統運行模擬將電源、電網、負荷和儲能系統集成在一起仿真，模擬整個配電系統的運行狀態，需要協調各子系統的計算結果。不可并行化計算耗時約4s，核心算法并行化計算時間約6s，總耗時約10s。

當計算規模增大到原來的10 倍以上，計算規模達到省級電網，通信耗時陡增，這時將千兆交換機換成萬兆交換機即可縮短通信時間。因為對于路由器和交換機之類的網絡設備，將千兆帶寬提高到萬兆以后，總背板帶寬的提高不僅提升了每個端口的交換速度，也會帶動整個網絡速度的提高。

綜合上述測試結果可知，使用較小的通信代價即可換取較大的計算時間縮減，加速后的計算效果滿足規劃業務需求。

3 結束語

本文立足于工程實踐提出了一種基于RabbitMQ消息中間件的分布式通信架構，并且設計了滿足各模塊間交互的通用消息格式，解決了配電網輔助規劃平臺異構數據獲取問題和快速計算問題，滿足了分布式計算平臺的數據通信及模塊間相互配合的需要，為配電網規劃平臺分布式計算提供了算力支持。

下一步將關注根據負載變化自適應地進行計算資源的靈活調度，例如開展計算負載錯峰調度。更進一步地，將數據挖掘算法和資源調度結合起來，構建負載隨著時間變化的模型，并基于此提前預測和調度，以減少負載急劇變化時資源分配不合理造成的延遲驟升，或者根據目標性能和當前集群資源，自動給出資源的最優調度方案。