基于MQTT的物聯網平臺研究與設計

郭翠娟，暴 寧，榮 鋒

(1.天津工業大學 電氣與電子工程學院，天津 300387； 2.天津工業大學 天津市光電檢測技術與系統重點實驗室，天津 300387)

0 引 言

物聯網平臺作為設備集中接入、數據統一管理及提供應用服務的重要環節，是實現物聯網智能化管理的有效基礎[1]。物聯網平臺代替了傳統通過人力獲取多監測現場情況的方式，使得用戶可遠程查看多個監測環境信息及通過可視化界面與現場設備交互，有效改善了傳統監測方式人工投入大，監測效率低的問題。目前，物聯網平臺較多是針對某一特定物聯網環境進行獨立開發，更注重于需求的實現[2-4]，對平臺架構的穩定性、普適性及通信協議的一致性問題關注則相對較少。同時前后端開發語言的不一致及模板引擎的開發方式[5-7]，使得前后端代碼邏輯耦合程度高，開發周期長且擴展性差。

本文結合物聯網平臺開發需求及現在Web技術的發展，研究并設計了基于MQTT協議的物聯網平臺，對平臺的架構及功能實現進行介紹。該物聯網平臺具有如下特點：①基于Nodejs環境，采用前后端分離架構分層開發物聯網平臺，降低前后端服務器的耦合度，提升客戶端并發請求處理速度。②基于功能和業務邏輯進行模塊化開發，解決頁面結構冗雜問題的同時易于平臺實現功能擴展。③統一通信協議和數據傳輸格式，基于MQTT協議實現平臺同時與多個網關設備的連接通信。

1 物聯網平臺總體架構

物聯網技術是智能時代最直接的產物，其主要由感知層、傳輸層及應用層3部分組成。物聯網平臺屬于物聯網系統的應用層，向上提供可視化頁面與客戶端進行交互，向下與設備端進行通信實現數據的解析存儲，是物聯網系統中服務應用于數據分析的重要環節。

本設計在Nodejs環境下，統一前后端開發語言，結合Web技術開發設計物聯網平臺。采用前后端分離架構、JavaScript語言分別開發前端頁面和后端服務器，并基于MQTT協議與網關設備建立雙向通信，完成網關物理實體與虛擬注冊網關設備的映射，實現平臺對多個監測現場底層傳感數據的接入、傳輸、處理及可視化。授權用戶通過前端頁面實時查看監測現場數據信息以及對底層設備下發控制命令。物聯網平臺總體架構如圖1所示，分為頁面視圖層、業務處理層、物接入層及數據存儲層4部分。

圖1 物聯網平臺總體架構

(1)頁面視圖層主要實現與用戶交互。用戶通過瀏覽器基于HTTP協議訪問該物聯網平臺，通過提供的UI界面可查詢用戶、網關設備等信息及實現監測數據可視化，并可通過平臺所提供的附加功能，如歷史數據查詢、日志記錄等信息進行決策。

(2)業務處理層向上提供REST API接口，為前端用戶操作提供后臺服務支持[8]，完成用戶注冊、設備注冊及信息查詢等邏輯操作。向下對物接入層提交的數據信息進行解析并存儲至數據庫。

(3)物接入層主要實現與網關設備的雙向通信，完成網關設備的認證連接。基于MQTT協議實現平臺與網關設備之間的數據傳輸。

(4)數據存儲層作為數據的存儲倉庫，主要用于存儲用戶、設備和監測數據及狀態等信息。

2 物聯網平臺具體設計

物聯網平臺基本功能應包括與多個網關設備通信、對監測現場數據解析存儲及以網頁的形式實現監測數據可視化，本文設計的物聯網平臺滿足上述需求并具有普遍的適用性。本文將以該平臺應用于監測溫室大棚環境信息為例，完成平臺功能的開發和測試。

2.1 頁面視圖層設計實現

頁面視圖層直接與用戶交互，提供給客戶端可視化界面及功能選擇。基于前后端分離架構，前端可視化頁面采用目前流行的Vuejs前端框架[9]結合ElementUI組件庫實現。Vuejs屬于MVVM(model view view model)架構，它幫助我們屏蔽了具體的DOM操作和輸出格式，并分模塊設計頁面樣式和邏輯控制，只需聲明各部分之間的綁定關系便可實現數據和頁面的同步，改善了模板引擎開發過程中數據綁定速率慢及修改維護困難的問題。基于模塊化的思想，在設計語言分模塊開發的基礎上，根據平臺功能需求進行模塊化開發，一個模塊對應平臺的一個功能實現，使得在不改變原有代碼的基礎上便可進行功能擴展。

物聯網監測平臺有登錄模塊、地圖首頁、用戶管理、設備管理、功能實現、實時數據、歷史數據、日志記錄和報警記錄9大模塊。授權登錄的用戶可通過可視化頁面實現數據監控及下發控制指令。每一個請求基于HTTP協議轉發至后端服務器進行處理，如查詢歷史數據、設備注冊和數據同步等操作。用戶與平臺交互的過程如圖2所示。

圖2 用戶與平臺交互流程

(1)登錄頁面主要對用戶身份進行驗證。在開發過程中，對用戶的密碼進行了MD5加密及格式控制，只有在用戶名及密碼與數據庫中存儲的用戶信息一致的情況下才可登錄到本平臺。驗證通過后將進入平臺首頁，即地圖頁面。地圖頁面通過在VUE框架中引入baidu-map插件實現，通過該頁面可以查看不同網關設備分布的地理位置及在線狀態等信息。

(2)用戶管理模塊顯示注冊用戶的信息，并提供給用戶可視化操作按鈕，實現用戶信息的增刪改查。設備管理模塊展示已注冊設備的信息，只有注冊的設備才能基于MQTT協議實現與平臺的數據傳輸。日志記錄模塊和報警模塊分別記錄所有用戶的命令操作和底層數據的報警信息，便于管理者對平臺集中管理和對監測設備作出相應決策和維護。以上四模塊均采用分頁功能實現數據的緩存顯示，提高了用戶的交互體驗。

(3)功能實現模塊主要包括物聯網平臺所具備的基本功能，包括OTA升級功能、設備分組功能及影子數據同步功能。其中OTA升級功能負責對網關設備實現軟件系統升級，如軟硬件系統版本。設備分組功能主要實現對批量設備下發同一指令，實現對底層設備的統一控制。影子數據同步功能保證了平臺與底層設備的狀態同步。

(4)實時數據頁面主要實現監測現場的實時環境信息和設備開關狀態以可視化形式展示給客戶端。為保證數據的時效性，采用輪詢及Websocket兩種通信機制監測實時數據。實時數據頁面將通過定時函數，周期性的查詢實時數據表中的數據。若在這期間，后端服務器監測到實時數據更新，將通過Websocket機制通知前端頁面[10]，真正實現瀏覽器與服務器的全雙工通信。

(5)歷史數據頁面通過引入Echarts圖表插件實現，可以根據不同參數量和時間查看對應參數的歷史數據曲線，便于用戶對棚內監測環境進行分析決策。

2.2 業務處理層設計實現

業務處理層作為中間層，是實現頁面視圖層、物接入層與數據庫交互的重要環節。該層采用當下流行的Thinkjs框架搭建Web服務器，提供REST API接口響應頁面視圖層和物接入層的請求。Thinkjs作為面向未來開發的Nodejs框架，繼承了Nodejs基于事件驅動，異步I/O及單線程的特點，解決了同步請求導致的資源浪費及多線程處理請求帶來的死鎖問題。Nodejs摒棄了一個線程處理一個請求的傳統方式。在實現異步I/O的過程中，主進程負責監聽，并將其將監聽到的請求作為事件加入到事件循環隊列中，連續的執行循環體輪詢將待處理事件交由底層I/O線程異步處理，待處理完成后將響應結果返回給應用程序[11]。Nodejs異步處理請求如圖3所示。

圖3 Nodejs異步處理請求

2.2.1 處理客戶端請求

本文基于REST風格設計API，并根據功能需求同樣進行模塊化開發，不同的功能模塊對應不同的邏輯響應模塊，并在模塊中對各個響應函數進行異步封裝，利用Nodejs基于事件循環的處理機制實現前端頁面的快速響應。當前端頁面提交請求后，后端Web服務器通過控制函數根據請求API將請求分別送至相應功能模塊進行處理。對于簡單的查詢請求，將與數據庫進行交互并將異步查詢結果以JSON格式返回至前端頁面；對于設備注冊等表單請求，則將注冊信息存入數據庫。如果是對底層設備控制命令的下發，則將控制命令交由物接入層進行轉發處理。業務處理層在監聽到實時數據更新時，基于Websocket協議將數據傳輸至前端頁面以展示給客戶端。業務層處理客戶端請求流程如圖4所示。

2.2.2 處理數據請求

業務處理層向下需對物接入層轉發的數據進行處理，基于Nodejs事件循環、異步I/O的特點，主線程無需等待響應結果返回便可繼續處理剩余請求，實現數據的快速解析和存儲。在接收到物接入層提交的數據處理請求后，消息處理模塊對接收的消息根據類型和主題分模塊處理。對于網關設備的連接狀態或系統軟件版本號等實時性不強的消息，解析后直接存入數據庫。若消息為監測現場的實時數據，則根據請求體中的消息主題交由相應函數處理。業務處理層處理數據請求如圖5所示。業務層主要處理以下4種主題的數據請求。

(1)監測現場的傳感器消息。

(2)監測現場的開關變量消息。

(3)客戶端向設備端下發指令，設備端回復確認消息。

(4)設備端主動向服務端獲取狀態同步的消息。

圖5 業務處理層處理數據請求

對于存在不確定量的網關設備向平臺同步發送實時數據的情況，如傳感數據或開關變量，則將數據緩存至消息隊列，待服務器空閑時進行存儲，并根據存儲在緩存數據庫中MessageId判斷是否該消息已被成功接收，保證了數據時效性的同時避免因數據阻塞丟包問題的發生。

2.3 物接入層設計實現

物接入層負責與網關設備連接通信，實現平臺對監測現場底層數據的接收管理及對底層監測設備狀態的反向控制。

2.3.1 物聯網服務器

物接入層利用MQTT協議完成網關設備的接入認證及數據的實時雙向傳輸。MQTT是一種基于代理的輕量級發布/訂閱消息傳輸協議, 其可在低帶寬、不可靠網絡中進行數據的有效傳輸，已成為物聯網標準傳輸協議[12]。MQTT協議主要由消息代理服務器和客戶端兩部分組成，其中客戶端包括消息的發布者和訂閱者。消息的發布者和訂閱者基于IP地址和端口連接到消息代理服務器，由代理服務器實現消息的接收和轉發。消息傳輸質量等級分為QoS0、QoS1及QoS2這3種，代理服務器根據消息傳輸等級判斷是否向客戶端發布消息確認。其中傳輸的消息主要由主題和元數據兩部分構成，主題可理解為一種消息類型，元數據為主要的消息內容，訂閱者根據約定主題才可獲得相應的元數據信息。MQTT協議通信過程如圖6所示。

圖6 MQTT協議通信過程

本文選用EMQX作為消息代理服務器，即物聯網服務器。EMQX是支持大規模連接和分布式集群，發布訂閱模式5G時代下的開源物聯網消息服務器，可同時處理百萬條消息數據，足夠滿足中小型企業的應用需求。基于開發需求，在EMQX服務器中加載數據庫插件，實現設備的認證連接；加載Wekhook插件，實現代理服務器向訂閱者轉發消息。

2.3.2 平臺與網關設備通信實現

平臺與網關的通信主要包括3種形式，即設備的認證連接、網關設備向平臺發送數據和平臺向網關設備同步信息，只有鑒權通過的設備才可與平臺進行數據傳輸。在本設計中，物聯網服務器為MQTT代理服務器，業務處理層和網關設備端為MQTT客戶端。

(1)設備連接認證

本文采用三元組即產品名、設備名和密鑰來標識一個邏輯設備。在本設計中規定設備接入本平臺的用戶名為ProductName/DeviceName(用戶名/設備名)，密鑰是由shortid插件產生的隨機且唯一的字符串。在物聯網服務器數據庫插件中設置連接條件實現設備的認證連接。當有網關設備請求連接時，物聯網服務器將查詢數據庫網關設備表，若是已注冊的網關設備，則通過用戶名和密鑰連接到物聯網平臺。

(2)網關設備向平臺傳輸數據

引入EMQX自帶的Hook機制[13]，實現代理服務器向客戶端的數據轉發，包括設備端的連接狀態及其發布的數據消息。網關設備在注冊時，同步的將其可發布訂閱主題的權限存入了其對應的數據庫集合中。物聯網服務器只會接收客戶端根據約定發布的主題，并將其封裝在請求體中，基于hook機制以POST請求方式將數據轉發至即業務處理層的消息處理模塊進行處理。以物聯網平臺為描述對象，平臺與網關設備通信的主題及函數見表1。

表1 網關設備向物聯網平臺發布數據的主題及處理函數

(3)平臺向設備端傳輸數據

使用EMQX服務器的訂閱功能實現設備端的自動訂閱。即當有設備連接到該平臺時，在EMQX服務器中便會根據主題權限定義當前設備所能訂閱的主題，一旦監聽到平臺發布主題，設備端便可根據物聯網服務器中的訂閱列表實現消息的獲取。在業務處理層封裝publishTo()函數實現平臺向網關設備端傳輸數據，如通過前端頁面操作開關狀態，OTA升級功能及影子數據同步等功能實現。

網關設備經過認證連接至物聯網平臺，頁面視圖層、業務處理層及物接入層協同與網關設備通信過程如圖7所示。

圖7 物聯網平臺與網關設備通信

2.4 數據存儲層

本設計選擇MongoDB數據庫結合Redis緩存數據庫和Rabbitmq消息隊列構成數據存儲層。MongoDB屬于非關系型數據庫，支持多功能查詢語句，其基于內存的存儲方式相比于關系數據庫可實現更快速的數據讀取。同時MongoDB支持JSON格式的數據結構，與本平臺和設備端通信的數據格式相一致，大大加速數據解析效率，用于存儲用戶、設備、傳感數據及歷史數據等信息。

Redis緩存數據庫和Rabbitmq消息隊列主要實現對設備端上傳的數據進行異步處理。每條消息有唯一標識MessageId，從主題中提取并存入緩存數據庫，便于平臺快速查詢消息是否已被正確接收，保證設備端消息的不重不漏。對于多臺設備同時上傳數據至平臺的情況，則先將數據緩存至消息隊列，待服務器空閑時將數據輪流取出存放至數據庫，解決了因數據存儲不及時產生的丟包問題，同時提高平臺處理數據的并發能力。

3 平臺測試及分析

3.1 性能測試

3.1.1 平臺服務器性能測試

本平臺以網頁形式展示給客戶端可視化頁面，平臺處理請求的速度直接影響用戶體驗。因此在本地對基于Nodejs搭建的Web服務器和Tomcat服務器處理客戶端并發請求的吞吐率進行測試，服務器端統一返回一串字符。以不同并發數向服務器發送請求,每次并發測試持續30 s，分別得到各服務器的平均吞吐率，測試結果如圖8所示。由測試結果可知，隨著客戶端并發請求數的增加，Nodejs下的Web服務器處理的平均吞吐率高于Tomcat服務器，即基于Nodejs搭建的Web服務器可更快處理客戶端的并發請求。

圖8 服務器平均吞吐率測試結果

3.1.2 數據通信性能測試

本文采用Jmeter測試工具模擬多個MQTT客戶端連接到平臺并發布數據，設置MQTT客戶端連接超時的時間為10 s，對平臺同時與多個網關設備之間的通信進行測試。選取實時數據為發布內容，長度為189字符/消息，MQTT客戶端的個數即為并發數據的條數。每次數據并發測試10次取平均值，通信結果見表2。由測試結果可知，當超過2000個MQTT客戶端同時向平臺發布數據時，由于業務層基于HTTP協議接收數據存在單點故障的問題，將出現丟包的現象；但當MQTT客戶端并發連接數不大于2000時，平臺可準確接收全部數據，滿足平臺的設計需求。

表2 通信性能測試結果

3.2 通信測試

物聯網平臺與網關設備的通信將以設備端上傳數據，平臺對現場環境信息實時顯示說明。物聯網平臺與網關設備通信測試結果(實時數據頁面)如圖9所示，包括對棚內環境參數及底層設備開關狀態信息。平臺基于輪詢機制每十分鐘自動刷新實時數據頁面，若在兩次刷新頁面時間內，基于Websocket機制監聽到實時數據的更新，則將最新的實時數據綁定至該頁面。并可通過開關按鈕實現對底層設備的反向控制。

圖9 通信測試結果(實時數據頁面)

3.3 UI界面

平臺服務端其它主要功能設計結果如圖10所示，包括地圖首頁、設備詳情頁及歷史曲線頁。

圖10 功能頁面

4 結束語

隨著智能時代的到來，物聯網平臺作為實現人與物交互的窗口，是物聯網技術不可或缺的部分。本文將Web系統架構應用于物聯網開發，并基于MQTT協議利用EMQX服務器的Hook機制和管理機制，構建了一個設備匯聚、信息集中管理和顯示的物聯網監測平臺。經測試，該平臺可實時獲取多個監測現場的信息并提供給客戶端可視化服務，滿足物聯網平臺功能需求，可作為多種物聯網環境下實現人物交互的監測平臺。本文接下來將致力于安全快速處理并發數據問題的研究，結合云計算技術提高平臺分析數據、處理數據的能力。