曲豫賓，李 芳

(江蘇工程職業(yè)技術(shù)學(xué)院，江蘇南通226001)

分布式微電網(wǎng)數(shù)據(jù)監(jiān)控中心設(shè)計(jì)與實(shí)現(xiàn)*

曲豫賓，李 芳

(江蘇工程職業(yè)技術(shù)學(xué)院，江蘇南通226001)

微電網(wǎng)建設(shè)存在大量的數(shù)據(jù)采集終端，數(shù)據(jù)終端的穩(wěn)定可靠數(shù)據(jù)采集.以及數(shù)據(jù)及時(shí)保存是項(xiàng)目要解決的問(wèn)題.系統(tǒng)設(shè)計(jì)采用Netty框架作為底層通信框架，數(shù)據(jù)持久層采用RabbitMQ解決數(shù)據(jù)保存、業(yè)務(wù)處理中的高IO問(wèn)題，引入MQTT協(xié)議解決跨平臺(tái)的消息傳遞.實(shí)踐證明，該系統(tǒng)能夠滿足微電網(wǎng)數(shù)據(jù)采集客戶端信息及時(shí)、準(zhǔn)確的采集與監(jiān)控要求.

微電網(wǎng);Netty;消息中間件;物聯(lián)網(wǎng)協(xié)議

1 項(xiàng)目研究背景

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

2 相關(guān)技術(shù)基礎(chǔ)

2.1 高并發(fā)服務(wù)器框架Netty

在jdk 1.4以后的Java開(kāi)發(fā)框架中引入了新的IO通信模型，在Java代碼中提供了面向快的高速IO通信接口，通過(guò)定義包含數(shù)據(jù)的類，不用采用低級(jí)代碼的優(yōu)化就能夠以塊的形式來(lái)處理IO［1］.新的IO接口為原有的通信框架提供了高速處理IO通信的基礎(chǔ)，然而由于NIO自身的復(fù)雜性及Jdk本身的Bug，處理網(wǎng)絡(luò)閃斷、客戶端重復(fù)接入、客戶端安全認(rèn)證、消息的編解碼、半包讀寫等問(wèn)題也給自定義網(wǎng)絡(luò)開(kāi)發(fā)框架設(shè)置了極大的障礙［2］.基于這些問(wèn)題，Trustin Lee開(kāi)發(fā)出了工業(yè)界比較流行的 Mina與Netty框架，Netty是一個(gè)高性能的異步非阻塞通信框架，通過(guò)Future－listener機(jī)制，用戶可以非?？旖莸耐ㄟ^(guò)事件通知獲取IO操作結(jié)果.

2.2 消息中間件RabbitMQ

消息中間是一類用于系統(tǒng)間通信，進(jìn)行系統(tǒng)解耦的軟件產(chǎn)品.阿里中間件團(tuán)隊(duì)對(duì)Kafka、Rabbit－MQ、RocketMQ消息中間件進(jìn)行過(guò)性能測(cè)試對(duì)比，結(jié)果是Kafka適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)，而基于Erlang開(kāi)發(fā)語(yǔ)言開(kāi)發(fā)的RabbitMQ適用于對(duì)數(shù)據(jù)一致性、穩(wěn)定性、可靠性要求比較高的場(chǎng)景，RocketMQ具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)［3］.在我們的系統(tǒng)開(kāi)發(fā)中對(duì)于系統(tǒng)的穩(wěn)定性和可靠性有著比較高的要求，因此項(xiàng)目采用RabbitMQ消息中間件.

2.3 物聯(lián)網(wǎng)通信協(xié)議MQTT

在存在大量物物相連的系統(tǒng)中，原始的請(qǐng)求回答模式已經(jīng)不能滿足系統(tǒng)的要求，取而代之的是發(fā)布訂閱模式，輕量級(jí)、可擴(kuò)展的 MQTT(Message Queuing Telemetry Transport)協(xié)議的開(kāi)發(fā)就是為了解決物物相連時(shí)存在的低功耗、網(wǎng)絡(luò)帶寬有限、網(wǎng)絡(luò)帶寬不穩(wěn)定等情況.該協(xié)議由IBM公司提出.通過(guò)對(duì)比［4］，MQTT協(xié)議相對(duì)于數(shù)據(jù)分發(fā)服務(wù)(DDS)、受限應(yīng)用協(xié)議(CoAP)適合于建立設(shè)備監(jiān)控等設(shè)備中心化的信息系統(tǒng).

3 系統(tǒng)設(shè)計(jì)架構(gòu)

根據(jù)分布式微電網(wǎng)的功能需求、硬件要求，以及網(wǎng)絡(luò)需求，設(shè)計(jì)了基于Netty的遠(yuǎn)程數(shù)據(jù)管理中心.該管理中心的設(shè)計(jì)要求是要能夠穩(wěn)定可靠地滿足系統(tǒng)需求，軟件模塊之間應(yīng)滿足高內(nèi)聚低耦合的設(shè)計(jì)原則，該管理中心應(yīng)該具有很好的彈性，面對(duì)突發(fā)的海量數(shù)據(jù)需求，應(yīng)該有靈活的擴(kuò)展方案.因此，系統(tǒng)整體架構(gòu)如圖1所示.

圖1 分布式微電網(wǎng)數(shù)據(jù)監(jiān)控系統(tǒng)設(shè)計(jì)架構(gòu)

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

分布式微電網(wǎng)通過(guò)智能終端采集信息，通過(guò)RS232接口將數(shù)據(jù)發(fā)送給DTU，該數(shù)據(jù)傳輸單元再按照指定的私有協(xié)議封裝數(shù)據(jù)，通過(guò)2G/3G/4G網(wǎng)絡(luò)將TCP報(bào)文發(fā)送給移動(dòng)網(wǎng)絡(luò)，連接到指定的服務(wù)器端套接字上進(jìn)行雙向的網(wǎng)絡(luò)通信.數(shù)據(jù)終端既有對(duì)數(shù)據(jù)的采集，也存在對(duì)設(shè)備的管理控制，因此遠(yuǎn)程數(shù)據(jù)中心設(shè)計(jì)需要通過(guò)該邏輯鏈路發(fā)送控制指令給智能客戶端.

3.1 使用Netty解決海量智能客戶端的DTU長(zhǎng)連接

微電網(wǎng)數(shù)據(jù)采集終端通過(guò)dtu連接到遠(yuǎn)程數(shù)據(jù)數(shù)據(jù)采集中心.物聯(lián)網(wǎng)大致可以分為三個(gè)層次，分別是傳感器層、網(wǎng)絡(luò)層、應(yīng)用層.微電網(wǎng)數(shù)據(jù)采集終端相對(duì)于分布式微電網(wǎng)的傳感器，它負(fù)責(zé)采集微電網(wǎng)的電流、電壓、功率等實(shí)時(shí)參數(shù)，同時(shí)也承擔(dān)對(duì)于微電網(wǎng)硬件的遠(yuǎn)程控制.該數(shù)據(jù)終端通過(guò)無(wú)線網(wǎng)絡(luò)，比如2G/3G/4G等接入到遠(yuǎn)程數(shù)據(jù)中心.由于無(wú)線網(wǎng)絡(luò)存在網(wǎng)絡(luò)不穩(wěn)定、野外傳輸速度較慢等問(wèn)題，而且要求能夠?qū)崟r(shí)傳輸，反向控制，因此在數(shù)據(jù)中心的設(shè)計(jì)上特別要考慮該技術(shù)要求.

微電網(wǎng)的支持高并發(fā)的數(shù)據(jù)中心采集模塊的設(shè)計(jì)重點(diǎn)考慮了讀心跳包的處理，基于責(zé)任鏈模式的特定報(bào)文的業(yè)務(wù)邏輯處理，通過(guò)對(duì)Channel的管理實(shí)現(xiàn)對(duì)于采集終端的管理.該模塊設(shè)計(jì)結(jié)構(gòu)如圖2所示.

圖2 基于Netty的長(zhǎng)連接服務(wù)器設(shè)計(jì)結(jié)構(gòu)

在最底層采用Linux操作系統(tǒng)，使用Epoll模型作為網(wǎng)絡(luò)IO處理的底層框架，以該底層框架為基礎(chǔ)，在第二層使用Jdk中的NIO進(jìn)行非阻塞的網(wǎng)絡(luò)IO讀寫，實(shí)現(xiàn)IO多路復(fù)用模式.在第三層的Netty框架層，使用Reactor設(shè)計(jì)模式，將服務(wù)器端發(fā)生的IO事件注冊(cè)在Selector上，實(shí)現(xiàn)高并發(fā)的、非阻塞的、基于事件的高性能網(wǎng)絡(luò)處理框架.通過(guò)Netty框架，實(shí)現(xiàn)自定義的業(yè)務(wù)邏輯處理、客戶端管理，以及心跳處理.

3.2 引入消息中間件異步處理高IO服務(wù)器業(yè)務(wù)邏輯

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

圖3 基于消息中間件的業(yè)務(wù)邏輯服務(wù)器設(shè)計(jì)結(jié)構(gòu)

3.3 使用MQTT協(xié)議搭建跨平臺(tái)的消息服務(wù)器

圖4 基于MQTT協(xié)議的跨平臺(tái)消息服務(wù)器設(shè)計(jì)結(jié)構(gòu)

目前工業(yè)界已經(jīng)有不少可用的跨平臺(tái)的消息服務(wù)器，比如Google的消息推送服務(wù)器，蘋果公司的消息推送服務(wù)器，國(guó)內(nèi)有極光、阿里云消息服務(wù)器等等.這些服務(wù)器目前采用的比較多的都是使用MQTT協(xié)議進(jìn)行數(shù)據(jù)推送.這些服務(wù)器有些在國(guó)內(nèi)不是非常暢通，有些服務(wù)器商用以后要收費(fèi)，更多的是由于無(wú)法滿足自定義的業(yè)務(wù)需求，同時(shí)能夠連接物聯(lián)網(wǎng)終端和手機(jī)終端，因此基于MQTT協(xié)議開(kāi)發(fā)了跨平臺(tái)的消息服務(wù)器.系統(tǒng)設(shè)計(jì)結(jié)構(gòu)如圖4所示.

整個(gè)系統(tǒng)有三種終端，通過(guò)dtu設(shè)備連接上來(lái)的智能終端，未來(lái)采用MQTT協(xié)議連接的物聯(lián)網(wǎng)終端，智能手機(jī)終端(比如Ios、Android等客戶端).針對(duì)這種低功耗不可靠網(wǎng)絡(luò)連接的情況，MQTT協(xié)議能夠提供有效的數(shù)據(jù)通信基礎(chǔ)，基于RabbitMQ消息中間件的MQTT插件實(shí)現(xiàn)了物聯(lián)網(wǎng)云服務(wù).三種終端通過(guò)訂閱發(fā)布機(jī)制實(shí)現(xiàn)物物相連.

4 系統(tǒng)具體實(shí)現(xiàn)

4.1 基于Netty的長(zhǎng)連接服務(wù)器實(shí)現(xiàn)

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

圖5 多線程Reactor模型

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

(1)客戶端連接管理.借助于Netty框架提供的接口能夠快速的管理客戶端連接，如圖6所示.支持IO端口多路復(fù)用的Selector在取得讀報(bào)文事件以后，隨機(jī)選擇IO線程池中的一個(gè)線程，在注冊(cè)的自定義報(bào)文處理中，把客戶端連接的上下文發(fā)送給客戶端連接管理器，由多線程共享的Map存儲(chǔ)客戶端連接的ID與上下文的鍵值對(duì).這種方式的優(yōu)點(diǎn)在于責(zé)任明確，軟件模塊耦合度很低，用戶連接采用統(tǒng)一模式繼續(xù)管理，便于后續(xù)的客戶端管理.在代碼實(shí)現(xiàn)過(guò)程中，DataCenterChannelManager類采用單例模式進(jìn)行設(shè)計(jì)，有利于全局調(diào)用.

圖6 客戶端連接管理時(shí)序圖

(2)客戶端心跳包處理.要保持客戶端的長(zhǎng)連接，在無(wú)業(yè)務(wù)數(shù)據(jù)的時(shí)候有必要發(fā)送或者接收心跳報(bào)文.對(duì)于分布式微電網(wǎng)智能客戶端來(lái)講，采用DTU連接網(wǎng)絡(luò)的客戶端，心跳報(bào)文來(lái)自于智能客戶端的主動(dòng)上傳.基于Netty框架的心跳包處理在業(yè)務(wù)鏈中添加對(duì)于心跳的業(yè)務(wù)邏輯處理即可，如圖7所示.

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

Dtu處于移動(dòng)網(wǎng)絡(luò)的內(nèi)網(wǎng)，為了減少連接負(fù)載，移動(dòng)網(wǎng)絡(luò)會(huì)在沒(méi)有消息發(fā)送的時(shí)候斷掉客戶端連接，因此為了保持長(zhǎng)連接，DTU終端心跳時(shí)間要小于移動(dòng)網(wǎng)絡(luò)斷開(kāi)連接時(shí)間.每個(gè)網(wǎng)絡(luò)斷開(kāi)連接時(shí)間不確定，根據(jù)生產(chǎn)實(shí)踐，將DTU心跳時(shí)間設(shè)置為60秒，而服務(wù)器端處理心跳的時(shí)間設(shè)置為120秒，超過(guò)120秒沒(méi)有收到心跳報(bào)文則斷開(kāi)當(dāng)前連接.在事件處理鏈中只需要添加IdleStateHandler事件處理器即可.

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

4.2 支持高IO的業(yè)務(wù)邏輯處理模塊

在系統(tǒng)中引入消息中間件來(lái)支持對(duì)于高IO的業(yè)務(wù)邏輯處理.Netty中的worker線程在解析完成數(shù)據(jù)報(bào)文以后，將要處理的數(shù)據(jù)封裝發(fā)到消息中間件的緩沖區(qū)中，由消費(fèi)者線程從緩沖區(qū)中取出，處理完成，存入數(shù)據(jù)庫(kù).

(1)生產(chǎn)者線程向緩沖區(qū)存入消息.生產(chǎn)者線程就是IO處理線程池中的Worker線程，在自定義業(yè)務(wù)邏輯處理模塊中，對(duì)報(bào)文做好業(yè)務(wù)封裝，傳入消息池.業(yè)務(wù)處理模塊使用AMQP協(xié)議連接Host，經(jīng)過(guò)安全驗(yàn)證以后將消息發(fā)到相應(yīng)的隊(duì)列中去，如圖8所示.

圖8 生產(chǎn)者線程存儲(chǔ)消息時(shí)序圖

(2)消費(fèi)者線程處理緩沖區(qū)中的消息.消費(fèi)者子線程在連接到Host的指定隊(duì)列以后，進(jìn)入循環(huán)輪詢，查詢到消息隊(duì)中有消息時(shí)候，取出來(lái)進(jìn)行處理，將結(jié)果持久化到服務(wù)器中去.

4.3 支持MQTT協(xié)議的跨平臺(tái)消息服務(wù)器搭建

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

圖9 支持MQTT協(xié)議的跨平臺(tái)消息服務(wù)器架構(gòu)

智能客戶端，比如 Ios、Android客戶端根據(jù)MQTT協(xié)議發(fā)布或者訂閱消息，消息持久化到消息隊(duì)列中去，worker線程獲取到主題消息，根據(jù)消息ID的不同來(lái)發(fā)布微電網(wǎng)客戶端的最新?tīng)顟B(tài)或者是更新微電網(wǎng)客戶端的狀態(tài).

5 小結(jié)

本文基于微電網(wǎng)建設(shè)的實(shí)際情況，根據(jù)微電網(wǎng)的項(xiàng)目要求，重點(diǎn)考慮了微電網(wǎng)的基于DTU客戶端的連接管理，跨平臺(tái)多種客戶端的通信，業(yè)務(wù)邏輯高效穩(wěn)定的處理等多方面的實(shí)際需求，采用了開(kāi)源的方案來(lái)解決實(shí)際問(wèn)題，Netty框架解決客戶端連接問(wèn)題，消息中間件解決數(shù)據(jù)處理問(wèn)題，MQTT協(xié)議的引入解決跨平臺(tái)客戶端連接問(wèn)題，實(shí)踐證明，該方案能夠滿足系統(tǒng)的功能要求，高效穩(wěn)定的運(yùn)行.整個(gè)系統(tǒng)采用單臺(tái)消息中間件，單臺(tái)服務(wù)器進(jìn)行處理，后期對(duì)于負(fù)載不斷增長(zhǎng)要做好系統(tǒng)優(yōu)化工作.基于MQTT協(xié)議的分布式微電網(wǎng)智能硬件還在開(kāi)發(fā)中，后期硬件接入也要做好功能測(cè)試和性能測(cè)試工作.

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

［2］李林峰.Netty權(quán)威指南［M］.北京:電子工業(yè)出版社，2014.

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

［4］孔祥龍，王燕.適用于低成本物聯(lián)網(wǎng)終端的消息通訊協(xié)議比較研究［J］.無(wú)線互聯(lián)科技，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

(責(zé)任編輯:王前)

TP39

A

1008－7974(2016)06－0016－05

10.13877/j.cnki.cn22－1284.2016.12.005

2016－09－15

南通市分布式發(fā)電與微電網(wǎng)技術(shù)重點(diǎn)實(shí)驗(yàn)室(CP12015007);江蘇工程職業(yè)技術(shù)學(xué)院自然科學(xué)研究項(xiàng)目(GYKY/2016/15)

曲豫賓，男，河南南陽(yáng)人，講師.