分布式微電網數據監控中心設計與實現*

曲豫賓，李 芳

(江蘇工程職業技術學院，江蘇南通226001)

分布式微電網數據監控中心設計與實現*

曲豫賓，李 芳

(江蘇工程職業技術學院，江蘇南通226001)

微電網建設存在大量的數據采集終端，數據終端的穩定可靠數據采集.以及數據及時保存是項目要解決的問題.系統設計采用Netty框架作為底層通信框架，數據持久層采用RabbitMQ解決數據保存、業務處理中的高IO問題，引入MQTT協議解決跨平臺的消息傳遞.實踐證明，該系統能夠滿足微電網數據采集客戶端信息及時、準確的采集與監控要求.

微電網;Netty;消息中間件;物聯網協議

1 項目研究背景

全球能源短缺和環境污染問題等決定了光伏等新能源發電將成為未來國家重點發展的新興產業.分布式微電網可以有效發揮能源采集優勢，把發電網絡部署到每一個分布式單元中，比如住戶的屋頂等等，這樣就可以更加有效地進行分布式的發電，提高發電量.美國、歐洲已經建立了分布式微電網的示范工程，中國目前也在不斷加大分布式微電網的研究與應用.微電網可以將多個分布式電源、負荷、儲能及控制裝置結合在一起，形成一個統一自治的可控小型發配電系統，微電網“就地消費”的特點可以有效減少對集中式大電廠電力生產的依賴，以及遠距離電能傳輸、多級變送的損耗，能有效解決大電網與分布式電源間的矛盾，充分發揮分布式發電的優勢，消除分布式發電對電網的沖擊，削峰填谷，提高能源綜合利用效率，提高電網的安全性，對推動新能源產業的發展，建設資源節約型社會具有深遠的意義.分布式微電網的研究與建設圍繞著四個方面進行，分別是分布式發電技術、儲能技術、能量管理系統相關技術、分布式發電站的遠程監控技術等.這四個方面的技術圍繞著電能的生產、儲存、管理，遠程監控等形成了完整的生態鏈，從而滿足分布式微電網的運行要求.實現分布式微電網的數據采集監控要考慮的問題包括:數據采集終端的設計，網絡連接協議的設計，智能終端的通信模塊設計，數據采集服務器的設計，推送消息服務器的設計，業務邏輯服務器的設計等等.在本項目中，分布式微電網的數據監控與采集采用了大量的用單片機設計的智能客戶終端，通過DTU與上位機相連接.上位機在進行業務處理的時候，分析并處理協議報文做好相應的業務邏輯，數據持久化在數據庫中.出于項目易用性的考慮，采用較為成熟的物聯網協議，比如MQTT等來設計滿足各種平臺的客戶端，比如Ios、Android等的連接需求.

2 相關技術基礎

2.1 高并發服務器框架Netty

在jdk 1.4以后的Java開發框架中引入了新的IO通信模型，在Java代碼中提供了面向快的高速IO通信接口，通過定義包含數據的類，不用采用低級代碼的優化就能夠以塊的形式來處理IO［1］.新的IO接口為原有的通信框架提供了高速處理IO通信的基礎，然而由于NIO自身的復雜性及Jdk本身的Bug，處理網絡閃斷、客戶端重復接入、客戶端安全認證、消息的編解碼、半包讀寫等問題也給自定義網絡開發框架設置了極大的障礙［2］.基于這些問題，Trustin Lee開發出了工業界比較流行的 Mina與Netty框架，Netty是一個高性能的異步非阻塞通信框架，通過Future－listener機制，用戶可以非常快捷的通過事件通知獲取IO操作結果.

2.2 消息中間件RabbitMQ

消息中間是一類用于系統間通信，進行系統解耦的軟件產品.阿里中間件團隊對Kafka、Rabbit－MQ、RocketMQ消息中間件進行過性能測試對比，結果是Kafka適合產生大量數據的互聯網服務的數據收集業務，而基于Erlang開發語言開發的RabbitMQ適用于對數據一致性、穩定性、可靠性要求比較高的場景，RocketMQ具有高吞吐量、高可用性、適合大規模分布式系統應用的特點［3］.在我們的系統開發中對于系統的穩定性和可靠性有著比較高的要求，因此項目采用RabbitMQ消息中間件.

2.3 物聯網通信協議MQTT

在存在大量物物相連的系統中，原始的請求回答模式已經不能滿足系統的要求，取而代之的是發布訂閱模式，輕量級、可擴展的 MQTT(Message Queuing Telemetry Transport)協議的開發就是為了解決物物相連時存在的低功耗、網絡帶寬有限、網絡帶寬不穩定等情況.該協議由IBM公司提出.通過對比［4］，MQTT協議相對于數據分發服務(DDS)、受限應用協議(CoAP)適合于建立設備監控等設備中心化的信息系統.

3 系統設計架構

根據分布式微電網的功能需求、硬件要求，以及網絡需求，設計了基于Netty的遠程數據管理中心.該管理中心的設計要求是要能夠穩定可靠地滿足系統需求，軟件模塊之間應滿足高內聚低耦合的設計原則，該管理中心應該具有很好的彈性，面對突發的海量數據需求，應該有靈活的擴展方案.因此，系統整體架構如圖1所示.

圖1 分布式微電網數據監控系統設計架構

數據管理中心底層采用Linux操作系統，在數據中心建設過程中，集成了工業界比較成熟穩定的方案.底層網絡通信模塊采用廣泛應用的Netty框架，該框架提供非阻塞異步的網絡IO管理.業務邏輯模塊采用消息中間件RabbitMQ進行緩沖處理，有效地解決了系統的穩定性和健壯性的問題.業務邏輯服務器與消息中間件之間采用AMQP協議進行數據交換.數據的存儲采用MySQL進行持久化.智能終端，比如Ios、Android客戶端與數據中心的物聯網通信模塊之間采用MQTT協議進行數據的交換.同時預留了微電網數據采集終端與物聯網通信模塊之間的通信接口.該物聯網通信模塊使用RabbitMQ的插件獲得對MQTT協議的支持.

分布式微電網通過智能終端采集信息，通過RS232接口將數據發送給DTU，該數據傳輸單元再按照指定的私有協議封裝數據，通過2G/3G/4G網絡將TCP報文發送給移動網絡，連接到指定的服務器端套接字上進行雙向的網絡通信.數據終端既有對數據的采集，也存在對設備的管理控制，因此遠程數據中心設計需要通過該邏輯鏈路發送控制指令給智能客戶端.

3.1 使用Netty解決海量智能客戶端的DTU長連接

微電網數據采集終端通過dtu連接到遠程數據數據采集中心.物聯網大致可以分為三個層次，分別是傳感器層、網絡層、應用層.微電網數據采集終端相對于分布式微電網的傳感器，它負責采集微電網的電流、電壓、功率等實時參數，同時也承擔對于微電網硬件的遠程控制.該數據終端通過無線網絡，比如2G/3G/4G等接入到遠程數據中心.由于無線網絡存在網絡不穩定、野外傳輸速度較慢等問題，而且要求能夠實時傳輸，反向控制，因此在數據中心的設計上特別要考慮該技術要求.

微電網的支持高并發的數據中心采集模塊的設計重點考慮了讀心跳包的處理，基于責任鏈模式的特定報文的業務邏輯處理，通過對Channel的管理實現對于采集終端的管理.該模塊設計結構如圖2所示.

圖2 基于Netty的長連接服務器設計結構

在最底層采用Linux操作系統，使用Epoll模型作為網絡IO處理的底層框架，以該底層框架為基礎，在第二層使用Jdk中的NIO進行非阻塞的網絡IO讀寫，實現IO多路復用模式.在第三層的Netty框架層，使用Reactor設計模式，將服務器端發生的IO事件注冊在Selector上，實現高并發的、非阻塞的、基于事件的高性能網絡處理框架.通過Netty框架，實現自定義的業務邏輯處理、客戶端管理，以及心跳處理.

3.2 引入消息中間件異步處理高IO服務器業務邏輯

盡管Netty已經實現了對高并發的客戶端連接的處理，項目中提供一臺數據存儲服務器，如何保證準確、可靠、快速地進行業務邏輯處理是業務邏輯處理服務器設計中要重點解決的問題.解決問題的方案是采用生產者－消費者模式進行數據處理，待處理的消息存儲在消息中間件，由消費者異步地使用AMQP協議處理消息，處理完業務邏輯結束以后，把電流、電壓、功率等數據信息持久化存儲在MySQL服務器.系統的整體設計結構如圖3所示.大量的客戶端連接在數據中心上，實時地會有大量的數據報文同時需要進行處理，報文處理時候要進行較多的業務處理，引起IO阻塞，通過消息中間的引入就可以把海量的同步信息異步進行處理;同時單臺MySQL服務器要能承擔大量的客戶端連接;業務處理子線程能夠異步、及時準確地將數據消費、解析、存儲到服務器中去.

圖3 基于消息中間件的業務邏輯服務器設計結構

3.3 使用MQTT協議搭建跨平臺的消息服務器

圖4 基于MQTT協議的跨平臺消息服務器設計結構

目前工業界已經有不少可用的跨平臺的消息服務器，比如Google的消息推送服務器，蘋果公司的消息推送服務器，國內有極光、阿里云消息服務器等等.這些服務器目前采用的比較多的都是使用MQTT協議進行數據推送.這些服務器有些在國內不是非常暢通，有些服務器商用以后要收費，更多的是由于無法滿足自定義的業務需求，同時能夠連接物聯網終端和手機終端，因此基于MQTT協議開發了跨平臺的消息服務器.系統設計結構如圖4所示.

整個系統有三種終端，通過dtu設備連接上來的智能終端，未來采用MQTT協議連接的物聯網終端，智能手機終端(比如Ios、Android等客戶端).針對這種低功耗不可靠網絡連接的情況，MQTT協議能夠提供有效的數據通信基礎，基于RabbitMQ消息中間件的MQTT插件實現了物聯網云服務.三種終端通過訂閱發布機制實現物物相連.

4 系統具體實現

4.1 基于Netty的長連接服務器實現

Netty框架為高性能異步服務器的設計提供了良好的接口，在該框架中，需要用到兩個比較重要的模型，一個是前端連接處理的多線程Reactor模型，還有一個是串行化的基于責任鏈模式的處理模型.多線程的Reactor模型的運行過程如圖5所示［5］.

圖5 多線程Reactor模型

Acceptor線程接收客戶端的連接，注冊到Selector選擇器，有新的數據可讀或者可寫的時候在IO線程池中取出一個線程進行數據的讀寫.為了避免多線程上下文的切換，Netty框架采用了串行化的處理理念，在管道中執行Handler，完成用戶自定義的業務需求.一般來講重點處理三類業務，分別是客戶端連接管理，客戶端心跳包處理，自定義業務邏輯處理.

(1)客戶端連接管理.借助于Netty框架提供的接口能夠快速的管理客戶端連接，如圖6所示.支持IO端口多路復用的Selector在取得讀報文事件以后，隨機選擇IO線程池中的一個線程，在注冊的自定義報文處理中，把客戶端連接的上下文發送給客戶端連接管理器，由多線程共享的Map存儲客戶端連接的ID與上下文的鍵值對.這種方式的優點在于責任明確，軟件模塊耦合度很低，用戶連接采用統一模式繼續管理，便于后續的客戶端管理.在代碼實現過程中，DataCenterChannelManager類采用單例模式進行設計，有利于全局調用.

圖6 客戶端連接管理時序圖

(2)客戶端心跳包處理.要保持客戶端的長連接，在無業務數據的時候有必要發送或者接收心跳報文.對于分布式微電網智能客戶端來講，采用DTU連接網絡的客戶端，心跳報文來自于智能客戶端的主動上傳.基于Netty框架的心跳包處理在業務鏈中添加對于心跳的業務邏輯處理即可，如圖7所示.

圖7 客戶端心跳包處理流程

Dtu處于移動網絡的內網，為了減少連接負載，移動網絡會在沒有消息發送的時候斷掉客戶端連接，因此為了保持長連接，DTU終端心跳時間要小于移動網絡斷開連接時間.每個網絡斷開連接時間不確定，根據生產實踐，將DTU心跳時間設置為60秒，而服務器端處理心跳的時間設置為120秒，超過120秒沒有收到心跳報文則斷開當前連接.在事件處理鏈中只需要添加IdleStateHandler事件處理器即可.

(3)基于責任鏈模式的自定義業務邏輯處理.在報文處理過程中除了報文的分拆，心跳的處理，非常重要的就是業務邏輯的處理.在業務邏輯處理階段，為了減少業務處理引起的性能瓶頸，通過異步的消息中間件把同步消息轉換為異步的消息處理.自定義的業務邏輯處理模塊繼承自ChannelInbound－HandlerAdapter，將該模塊注冊到Pipeline中即可.

4.2 支持高IO的業務邏輯處理模塊

在系統中引入消息中間件來支持對于高IO的業務邏輯處理.Netty中的worker線程在解析完成數據報文以后，將要處理的數據封裝發到消息中間件的緩沖區中，由消費者線程從緩沖區中取出，處理完成，存入數據庫.

(1)生產者線程向緩沖區存入消息.生產者線程就是IO處理線程池中的Worker線程，在自定義業務邏輯處理模塊中，對報文做好業務封裝，傳入消息池.業務處理模塊使用AMQP協議連接Host，經過安全驗證以后將消息發到相應的隊列中去，如圖8所示.

圖8 生產者線程存儲消息時序圖

(2)消費者線程處理緩沖區中的消息.消費者子線程在連接到Host的指定隊列以后，進入循環輪詢，查詢到消息隊中有消息時候，取出來進行處理，將結果持久化到服務器中去.

4.3 支持MQTT協議的跨平臺消息服務器搭建

MQTT協議目前已經有較多的成熟的Server/ Broker實現［6］，比如IBM WebSphere MQ Telemetry，IBM WebSphere Message Broker，IBM Lotus Expeditor micro broker，Really Small Message Broker，開源的Mosquitto，基于云計算的 m2m.io等等.RabbitMQ 3.0以后的版本通過插件機制已經可以支持MQTT協議，因此可以在跨平臺消息服務器搭建過程中，采用消息中間件RabbitMQ.目前已經有廣泛的MQTT 的Client包用于支持應用程序的開發，常見的有支持C語言的Liblwmqtt，支持JAVA的Mqtt－client，支持.NET平臺的MQTTDotNet，支持Python語言的MQTT－For－Twisted－Python，支持Arduino設備的Arduino client for MQTT等等.根據Android開發模型的特點，信息的訂閱與發布放在Service內實現，沒有放在Activity里面實現.該模塊的開發充分考慮了智能終端，比如Android、Ios客戶端與微電網客戶端的點對點通信問題，整個結構如圖9所示.

圖9 支持MQTT協議的跨平臺消息服務器架構

智能客戶端，比如 Ios、Android客戶端根據MQTT協議發布或者訂閱消息，消息持久化到消息隊列中去，worker線程獲取到主題消息，根據消息ID的不同來發布微電網客戶端的最新狀態或者是更新微電網客戶端的狀態.

5 小結

本文基于微電網建設的實際情況，根據微電網的項目要求，重點考慮了微電網的基于DTU客戶端的連接管理，跨平臺多種客戶端的通信，業務邏輯高效穩定的處理等多方面的實際需求，采用了開源的方案來解決實際問題，Netty框架解決客戶端連接問題，消息中間件解決數據處理問題，MQTT協議的引入解決跨平臺客戶端連接問題，實踐證明，該方案能夠滿足系統的功能要求，高效穩定的運行.整個系統采用單臺消息中間件，單臺服務器進行處理，后期對于負載不斷增長要做好系統優化工作.基于MQTT協議的分布式微電網智能硬件還在開發中，后期硬件接入也要做好功能測試和性能測試工作.

［1］NIO入門.［EB/OL］.http://www.ibm.com/developerworks/ cn/education/java/j－nio/j－nio.html

［2］李林峰.Netty權威指南［M］.北京:電子工業出版社，2014.

［3］阿里中間件團隊.Kafka、RabbitMQ、RocketMQ消息中間件的對比——消息發送性能［EB/OL］.http://jm.taobao.org/2016/04/ 01/kafka－vs－rabbitmq－vs－rocketmq－message－send－performance/

［4］孔祥龍，王燕.適用于低成本物聯網終端的消息通訊協議比較研究［J］.無線互聯科技，2015(16).

［5］李林峰.Netty系列之 Netty線程模型［EB/OL］.http:// www.infoq.com/cn/articles/netty－threading－model

［6］IBM公司.Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry［EB/OL］.ibm.com/redbooks

(責任編輯:王前)

TP39

A

1008－7974(2016)06－0016－05

10.13877/j.cnki.cn22－1284.2016.12.005

2016－09－15

南通市分布式發電與微電網技術重點實驗室(CP12015007);江蘇工程職業技術學院自然科學研究項目(GYKY/2016/15)

曲豫賓，男，河南南陽人，講師.