萬洪莉 李雨晨

摘? 要：基于MQTT協(xié)議，進行物聯(lián)網(wǎng)工程項目服務(wù)器端的架構(gòu)和開發(fā)，并針對服務(wù)器應(yīng)用架構(gòu)進行性能分析。采用MVC設(shè)計模式進行服務(wù)器端架構(gòu)設(shè)計，采用JSP技術(shù)進行開發(fā)。服務(wù)器和硬件、移動端的通信協(xié)議采用MQTT協(xié)議，搭建Apollo服務(wù)器實現(xiàn)對該協(xié)議的支持。經(jīng)分析，可提高物聯(lián)網(wǎng)服務(wù)器與感知層、應(yīng)用層的通信性能。

關(guān)鍵詞：物聯(lián)網(wǎng)通信協(xié)議;服務(wù)器;MQTT

Abstract： Based on MQTT （Message Queuing Telemetry Transport） protocol， the study conducts architecture construction and development of the Internet of Things （IoT） project server， and carries out performance analysis of the server application architecture. Model-View-Controller （MVC） mode is used to design the server architecture， and JSP technology is used to develop the server. MQTT is adopted as the communication protocol among the server， hardware and mobile terminal， and Apollo server is built to support the protocol. The analysis proves that the proposed method effectively improves the IoT server communication performance at perception layer and application layer.

Keywords： IoT communication protocol; server; MQTT

1? ?引言（Introduction）

1.1? ?現(xiàn)有物聯(lián)網(wǎng)項目架構(gòu)

HTTP是Web服務(wù)器開發(fā)中廣泛使用的協(xié)議。但當(dāng)研究物聯(lián)網(wǎng)服務(wù)器的系統(tǒng)架構(gòu)時，響應(yīng)時間，吞吐量，更低的電池和帶寬使用率成為衡量系統(tǒng)的主要性能指標(biāo)，MQTT協(xié)議在這類問題的解決中更具優(yōu)勢[1-3]。在文獻[4]中，基于物聯(lián)網(wǎng)體系架構(gòu)，以智能超市為業(yè)務(wù)背景，建設(shè)了物聯(lián)網(wǎng)實訓(xùn)教學(xué)體系。服務(wù)器架構(gòu)基于HTTP協(xié)議，采用硬件感知端、服務(wù)器端、移動端和數(shù)據(jù)流、控制流的“三端兩流”架構(gòu)。如圖1所示。

在圖1所示的架構(gòu)中，數(shù)據(jù)流由硬件感知端起始。硬件感知端將采集的數(shù)據(jù)發(fā)送至服務(wù)器端，移動端通過輪詢從服務(wù)器端獲得數(shù)據(jù)流，刷新UI界面進行遠程監(jiān)測。架構(gòu)的控制指令流由移動端起始。移動端發(fā)起控制指令，服務(wù)器端修改指令的相應(yīng)數(shù)據(jù)庫字段。硬件感知端發(fā)起輪詢操作，查詢服務(wù)器端控制指令的相應(yīng)狀態(tài)，根據(jù)控制指令控制執(zhí)行部件的動作。

物聯(lián)網(wǎng)的感知層研究與設(shè)計也依賴于項目所采用的物聯(lián)網(wǎng)應(yīng)用系統(tǒng)的典型模型。面向軟件測試的物聯(lián)網(wǎng)節(jié)點模擬單元開發(fā)[5]所做工作主要集中在節(jié)點單元的開發(fā)和測試，物聯(lián)網(wǎng)服務(wù)器端與感知層、應(yīng)用層的通信協(xié)議也采用HTTP協(xié)議。

在項目架構(gòu)的應(yīng)用中，存在請求響應(yīng)較慢、電池消耗高的情況。采用傳統(tǒng)的基于HTTP的服務(wù)器作為物聯(lián)網(wǎng)項目的服務(wù)平臺的應(yīng)用場景越來越少。

1.2? ?實際應(yīng)用領(lǐng)域的物聯(lián)網(wǎng)服務(wù)器

目前在實際應(yīng)用中已普遍采用物聯(lián)網(wǎng)服務(wù)平臺進行實際項目開發(fā)。例如百度“天工”智能物聯(lián)網(wǎng)平臺[6]、阿里云Link物聯(lián)網(wǎng)平臺[7]、QQ物聯(lián)智能硬件開放平臺”[8]、中國移動物聯(lián)網(wǎng)設(shè)備云—OneNET[9]等。

產(chǎn)業(yè)級的物聯(lián)網(wǎng)服務(wù)器平臺不再局限于傳統(tǒng)Web服務(wù)器的HTTP協(xié)議，而是支持HTTP、CoAP、MQTT等多種協(xié)議適配，為城市消防、畜牧業(yè)、共享經(jīng)濟、環(huán)境監(jiān)控等多場景提供解決方案。

2? 基于MQTT協(xié)議的物聯(lián)網(wǎng)服務(wù)器架構(gòu)（IoT server architecture based on MQTT protocol）

2.1? ?HTTP和MQTT在物聯(lián)網(wǎng)服務(wù)器通信中的對比

基于HTTP協(xié)議的物聯(lián)網(wǎng)項目架構(gòu)已經(jīng)滯后于實際應(yīng)用開發(fā)的技術(shù)發(fā)展。瓶頸在于服務(wù)器的HTTP通信協(xié)議。HTTP協(xié)議作為一種無狀態(tài)通信協(xié)議，適于開發(fā)Web應(yīng)用程序，進行業(yè)務(wù)邏輯處理和門戶展示。在物聯(lián)網(wǎng)項目體系架構(gòu)中，服務(wù)器還兼具感知層和應(yīng)用層的通信接口功能。感知層數(shù)據(jù)上傳需求頻繁，一般的家用智能系統(tǒng)以秒為單位產(chǎn)生感知數(shù)據(jù)的上傳需求。應(yīng)用層由用戶通過移動端發(fā)送控制指令至服務(wù)器，而基于HTTP協(xié)議的服務(wù)器架構(gòu)不具備主動推送功能，不能將控制指令狀態(tài)推送給感知層的執(zhí)行器件。在基于HTTP協(xié)議的服務(wù)器架構(gòu)中，感知層的執(zhí)行器件需要向服務(wù)器發(fā)起輪詢操作，獲知指令狀態(tài)，從而產(chǎn)生相應(yīng)動作。這種輪詢操作造成了數(shù)據(jù)流的冗余，占用大量的系統(tǒng)資源。

為解決此類問題，需要在物聯(lián)網(wǎng)服務(wù)器平臺中引入“發(fā)布/訂閱”機制的協(xié)議規(guī)范。MQTT協(xié)議作為消息隊列遙測傳輸協(xié)議，是一個基于TCP/IP協(xié)議的發(fā)布/訂閱協(xié)議。設(shè)計的初始目的是為了極有限的內(nèi)存設(shè)備和網(wǎng)絡(luò)帶寬很低的網(wǎng)絡(luò)中進行通信，非常適合物聯(lián)網(wǎng)通信[10-13]。

2.2? ?基于MQTT協(xié)議的物聯(lián)網(wǎng)服務(wù)器架構(gòu)設(shè)計

MQTT協(xié)議是廣泛應(yīng)用的物聯(lián)網(wǎng)協(xié)議，使用該協(xié)議需要MQTT消息代理及服務(wù)。有兩種方法使用MQTT服務(wù)，一是租用現(xiàn)成的MQTT服務(wù)器，使用公用的MQTT服務(wù)器的好處是功能全面，易用性高。但需要注冊賬號，靈活性差，有些平臺還需要付費。另一方法是自己使用開源的MQTT組件來搭建。圖2以物聯(lián)網(wǎng)工程項目中溫度數(shù)據(jù)在服務(wù)端、感知端、移動端的數(shù)據(jù)流向為例，設(shè)計了基于MQTT的物聯(lián)網(wǎng)服務(wù)器架構(gòu)的物聯(lián)網(wǎng)項目體系。

在圖2的物聯(lián)網(wǎng)服務(wù)器系統(tǒng)架構(gòu)中，Web服務(wù)器、感知端和移動端都作為Client，在MQTT消息代理上注冊并連接。針對系統(tǒng)中的溫度信息，三個Client都訂閱名為“temperature”的topic。感知端發(fā)布消息，內(nèi)容為溫度數(shù)據(jù)，Web服務(wù)器訂閱“temperature”，消息代理則會把溫度消息推送給Web服務(wù)器，Web服務(wù)器發(fā)布溫度消息，消息代理將其推送給訂閱了該主題的客戶端（移動端）。整個架構(gòu)采用發(fā)布/訂閱機制，數(shù)據(jù)幀格式即主題格式（topic），比HTTP協(xié)議的請求頭短很多，通信效率高，在系統(tǒng)中沒有數(shù)據(jù)更新，沒有數(shù)據(jù)流發(fā)生時，各個客戶端通過消息代理維持心跳連接即可。

本案例采用apollo的MQTT消息代理，將Web服務(wù)器、移動端、硬件端都注冊為apollo MQTT消息代理上的客戶端，實現(xiàn)發(fā)布/訂閱功能。下面主要闡述將傳統(tǒng)的基于HTTP的Web服務(wù)器包裝成MQTT Client，從而將其角色轉(zhuǎn)換為兼容MQTT協(xié)議的服務(wù)器的架構(gòu)過程。

2.3? ?基于MQTT協(xié)議的物聯(lián)網(wǎng)服務(wù)器開發(fā)

2.3.1? ?物聯(lián)網(wǎng)服務(wù)器的消息發(fā)布功能

物聯(lián)網(wǎng)服務(wù)器的消息發(fā)布功能接收移動端的控制指令，并以發(fā)布者的角色，通過apollo MQTT消息代理，推送給硬件執(zhí)行器所在的MQTT客戶端，過程如圖3所示。

由于服務(wù)器兼具傳統(tǒng)的HTTP服務(wù)器的業(yè)務(wù)邏輯功能和MQTT的消息發(fā)布訂閱功能，因此，可選取HTTP Web組件監(jiān)聽移動端發(fā)送的控制指令。在本課題中，選用Servlet監(jiān)聽器實現(xiàn)對移動端控制指令的監(jiān)聽功能。

本文所討論的HTTP服務(wù)器功能基于JSP模型二設(shè)計模式開發(fā)，由中央控制器對所有View層發(fā)出的請求進行處理，所有View層發(fā)出的請求以“.action”做結(jié)尾標(biāo)識。因此，本文所設(shè)計的監(jiān)聽器主要監(jiān)聽中央控制器的“change.action”請求。一旦監(jiān)聽到“change.action”請求，說明移動端發(fā)出了控制指令，監(jiān)聽器將監(jiān)聽到的控制指令包裝為名為“instructions”的主題（topic），主題內(nèi)容即為控制指令內(nèi)容。并將該topic通過apollo MQTT消息代理推送給訂閱了該主題的硬件執(zhí)行器件，從而實現(xiàn)對硬件執(zhí)行器件的主動推送控制功能。

2.3.2? ?物聯(lián)網(wǎng)服務(wù)器的消息訂閱功能

物聯(lián)網(wǎng)服務(wù)器的消息訂閱功能接收硬件感知層上傳的感知數(shù)據(jù)，調(diào)用MVC模型中的業(yè)務(wù)邏輯層，完成感知層數(shù)據(jù)的持久存儲。過程與圖3的發(fā)布功能類似，圖中的控制流變?yōu)閿?shù)據(jù)流。

消息訂閱功能和HTTP服務(wù)器接口的數(shù)據(jù)上傳功能數(shù)據(jù)流向一樣。但基于MQTT協(xié)議的數(shù)據(jù)幀長度很短，可定制格式，適于內(nèi)存有限的感知層硬件處理器，也適于數(shù)據(jù)流頻繁、帶寬有限的物聯(lián)網(wǎng)環(huán)境。

3? ?功耗分析（Power analysis）

3.1? ?無線網(wǎng)絡(luò)初始化期間功耗對比

物聯(lián)網(wǎng)服務(wù)器主要起到對數(shù)據(jù)流的持久存儲和UI展示，對控制流的接收接口和對感知層執(zhí)行器件的指令發(fā)送功能。因此，基于MQTT協(xié)議的物聯(lián)網(wǎng)服務(wù)器不再基于HTTP協(xié)議，采用請求/響應(yīng)模式提供這兩大服務(wù)。通過MQTT協(xié)議架構(gòu)的物聯(lián)網(wǎng)服務(wù)器與移動端、感知層建立了常連接，可基于MQTT的心跳響應(yīng)維持三者在消息代理上的連接狀態(tài)。數(shù)據(jù)流和控制流的傳輸都基于發(fā)布/訂閱機制。在與服務(wù)器建立初始化連接期間，HTTPS協(xié)議比MQTT協(xié)議的電池消耗略少，如表1所示。

3.2? ?無線網(wǎng)絡(luò)保持連接期間通信功耗對比

物聯(lián)網(wǎng)工程項目通信過程過程中，電池消耗指標(biāo)在保持連接中更具衡量代表性。保持連接所需要的電源消耗對比如表2所示。

通過對電池消耗表的分析，可以看出，HTTPS和MQTT通信方式在電源消耗上，隨著保持連接時長的增加，在4G和WiFi聯(lián)網(wǎng)的情況下，都會大幅減少，但總體來說，MQTT比HTTPS通信方式電源消耗減少50%左右。

4? ?結(jié)論（Conclusion）

通過分析目前物聯(lián)網(wǎng)工程架構(gòu)下通信協(xié)議的應(yīng)用現(xiàn)狀，以物聯(lián)網(wǎng)服務(wù)器與感知層和應(yīng)用層的通信協(xié)議為入手點，架構(gòu)并開發(fā)了一個基于MQTT的物聯(lián)網(wǎng)服務(wù)器。通過分析，采用MQTT協(xié)議的物聯(lián)網(wǎng)服務(wù)器在與物聯(lián)網(wǎng)感知層和應(yīng)用層的通信過程中，在網(wǎng)絡(luò)初始化之后的連接保持期間，功耗有顯著下降。

參考文獻（References）

[1] Vishal Kumar， Gayatri Sakya， Chandra Shankar. WSN and IoT based smart city model using the MQTT protocol[J]. Journal of Discrete Mathematical Sciences and Cryptography， 2019， 22（8）： 1423-1434.

[2] Jameel Ahamed， Md. Zahid， Mohd Omar， et al. AES and MQTT based security system in the internet of things[J]. Journal of Discrete Mathematical Sciences and Cryptography， 2019， 22（8）： 1589-1598.

[3] Arlen Nipper. MQTT's role as an IoT message transport[J]. Control engineering： Covering control， instrumentation， and automation systems worldwide， 2019， 66（1）： 20-21.

[4] 顧兆旭，焦戰(zhàn)，崔鵬.基于物聯(lián)網(wǎng)的智能超市實訓(xùn)室建設(shè)方案初探[J].軟件工程，2018，21（12）：60-62.

[5] 李曉明，Thierno Gueye.面向軟件測試的物聯(lián)網(wǎng)節(jié)點模擬單元開發(fā)[J].軟件工程，2019，22（7）：1-5.

[6] 百度.天工-智能物聯(lián)網(wǎng)[EB/OL].https：//cloud.baidu.com/solution/iot/index.html.2019

[7] 阿里.阿里云Link平臺正式發(fā)布[EB/OL].http：//www.kmykt.com/hy_new/644.html，2017.

[8] 騰訊.QQ物聯(lián)智能硬件開放平臺[EB/OL].https：//iot.open.qq.com，2014.

[9] 中國移動.OneNet物聯(lián)網(wǎng)開放平臺[EB/OL].https：//open.iot.10086.cn，2019.

[10] 侯敏，劉倩，楊華勇，等.基于MQTT協(xié)議的海洋觀測數(shù)據(jù)推送系統(tǒng)[J].計算機工程與應(yīng)用，2019，55（20）：227-231.

[11] 郭力，胡偉，張政成.試析MQTT協(xié)議在物聯(lián)網(wǎng)中的應(yīng)用[J].電腦知識與技術(shù)，2019，15（28）：31-32;37.

[12] 蔣樹慶，房瀅.一種基于MQTT協(xié)議的數(shù)據(jù)采集控制系統(tǒng)[J].信息通信，2019（8）：80-82.

[13] 耿錫濤.基于MQTT協(xié)議的電力設(shè)備溫度在線監(jiān)測系統(tǒng)應(yīng)用研究[J].工業(yè)控制計算機，2019，32（10）：73-74.

作者簡介：

萬洪莉（1978-），女，碩士，副教授.研究領(lǐng)域：物聯(lián)網(wǎng)工程，Web應(yīng)用開發(fā).

李雨晨（1979-），男，碩士，工程師.研究領(lǐng)域：控制理論與控制工程，電氣工程.