基于MQTTv5的智慧園區消息總線系統設計怎么實現

這篇文章主要講解了“基于MQTTv5的智慧園區消息總線系統設計怎么實現”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“基于MQTTv5的智慧園區消息總線系統設計怎么實現”吧！

MQTT v5服務端實現

為此，我們設計并實現了海舟智慧園區消息總線系統SailMQ。

海舟智慧園區消息總線系統，是一個MQTT服務端的實現，基于gmqtt提供的全面的MQTT v3.1.1和MQTT v5支持，為用戶提供面向未來的智慧園區基礎設施。

海舟智慧園區消息總線系統包含以下子系統：

• 海舟智慧園區管理系統SailUI

• 海舟智慧園區消息總線系統SailMQ

這兩個子系統相輔相成，缺一不可。

設計模型與術語

設備（Device）與 設備管理員（Device Manager）

各種物聯網智能終端設備與用于與舊式系統交互的工控機等被統一稱為設備，是用戶管理的基本單位，設備歸屬于某個特定的設備管理員，一個設備管理員可以管轄多個設備。

App 與 App管理員（App Manager）

用于展示、控制、獲取設備狀態的應用系統被稱為App，App歸屬于某個特定的App管理員，App管理員被授權訪問多個設備，其所管理的App具有同這些設備進行交互的權限。

客戶端

統一將設備和App稱為客戶端。

主題

主題被劃分為三級，例如dm-1/dev-1/DATA，其中dev-1為相應客戶端的Client ID，dm-1為其所屬的管理員的User Name，DATA為通道名（Channel Name）。

所有通道名如下：

• OFFLINE

• DATA

• CONTROL

• CREPLY

• QUERY

• QREPLY

規則引擎

規則引擎是一個用于校驗消息格式的系統模塊，后續章節會進行詳細介紹。

訪問控制

連接

在MQTT協議中，客戶端向服務端發送的第一個報文是CONNECT報文，本系統對此報文中的客戶標識符（Client Identifier）、用戶名（User Name）、密碼（Password）、遺囑主題（Will Topic）和遺囑消息（Will Payload）進行校驗，在MQTT v5協議的客戶端中，如果存在認證方法（Authentication Method），則應將其設置為jwt，并將認證數據（Authentication Data）設置為與密碼相同。

下面詳細介紹以上字段的配置規則：

• 客戶端標識符

應根據其類型配置為 dev-XXX（設備） 或 app-YYY （App）。

• 用戶名

根據客戶端類型進行配置，當客戶端類型為設備，此處應設置為其設備管理員的User Name；當客戶端類型為App，此處應設置為其App管理員的User Name。

• 密碼

如需獲取密碼，請安裝SailPasswordGenerator，打開后按照界面提示輸入相應參數即可獲得密碼。

• 遺囑主題

遺囑主題的設置根據客戶端類型的不同采用不同的設置，如果類型為設備則應設置為dm-XXX/dev-YYY/OFFLINE；如果類型為App則應將其置空。

• 遺囑消息

遺囑主題的設置根據客戶端類型的不同采用不同的設置，如果類型為App則應將其置空；如果類型為設備，遺囑消息需通過規則引擎的驗證，關于規則引擎請參考后續章節。

訂閱

訂閱支持共享訂閱和非共享訂閱，訂閱根據不同的客戶端類型而有所不同：

• 當客戶端類型為設備，其可以訂閱主題dm-XXX/dev-YYY/CONTROL和dm-XXX/dev-YYY/QUERY。

• 當客戶端類型為App，她可以訂閱其所屬App管理員被授權的設備，可以訂閱的通道為DATA、CREPLY、QREPLY；此時也可以訂閱相應的共享訂閱主題。例如有名為app-1的App，其所屬App管理員為am-1，am-1被授權的設備有dev-1，而dev-1所屬的管理員為dm-1，這時app-1可以訂閱的主題有dm-1/dev-1/DATA、dm-1/dev-1/CREPLY和dm-1/dev-1/QREPLY；及相應的共享訂閱主題，例如$share/{ShareName}/dm-1/dev-1/DATA。

發布

發布支持QOS0、1、2。

發布根據不同的客戶端類型而有所不同：

• 當客戶端類型為設備，其可以發布的主題為dm-XXX/dev-YYY/DATA、dm-XXX/dev-YYY/CREPLY和dm-XXX/dev-YYY/QREPLY。

• 當客戶端類型為App，她可以發布消息到其所屬App管理員被授權的設備，可以發布的通道為CONTROL和QUERY。例如有名為app-1的App，其所屬App管理員為am-1，am-1被授權的設備有dev-1，而dev-1所屬的管理員為dm-1，這時app-1可以發布的主題有dm-1/dev-1/CONTROL和dm-1/dev-1/QUERY。

如果以上的發布的訪問控制校驗通過，那么會進行規則引擎的校驗，關于規則引擎請參考后續章節。

規則引擎

當消息進入系統時，規則引擎會對其進行校驗。

首先，規則引擎會根據消息的主題去Redis中尋找相應的規則，例如，當主題為dm-1/dev-1/CONTROL時，規則引擎會按如下的優先級順序查找規則：

• dm-1/dev-1/CONTROL

• dm-1/*/CONTROL

• */*/CONTROL

• */*/*

當規則引擎找到相應的規則后，不會繼續向下查詢。

規則為一段特殊定制的json，下面舉例說明：

{
    "age": "number",
    "books": "list",
    "isStudent": "bool",
    "name": "string",
    "other": "object",
    "score": {
        "math": "number",
        "music": "number",
        "sport": "number"
    },
    "tag": "value"
}

消息若想通過上述規則的校驗，必須滿足其定義：

• age 應設置為number類型

• books 應設置為一個列表

• isStudent 應設置為 true 或 false

• name 應設置為字符串

• other 應設置為一個對象，對象的鍵值對沒有要求。

• score 應設置為一個對象，并且其應該遞歸滿足規則中鍵值對的要求，遞歸的層級沒有限制

• tag 應設置為number、bool或string類型的值

• 消息中不得包含規則中未定義的字段

附錄

已知支持MQTTv5的庫

• paho java

• paho python

• paho c

• paho c++

• MQTT.js

Python示例代碼

import paho.mqtt.client as mqtt
import json

PASSWORD = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJjbGllbnRJZCI6ImFwcC0xIiwidXNlcm5hbWUiOiJhbS0xIn0.fkotiit0lMJhO1FO2P9cvAF8g7KKL9xHF7XgMyq1H-5"


def on_connect(client, userdata, flags, reason, properties):
    print(flags, reason, properties)

    client.subscribe("dm-1/dev-1/CREPLY")
    
    msg = {"light": "on"}
    client.publish("dm-1/dev-1/CONTROL", json.dumps(msg), 2, True)


def on_message(client, userdata, msg):
    print(msg.topic + " " + str(msg.payload))


client = mqtt.Client(client_id="app-1", protocol=mqtt.MQTTv5)
client.username_pw_set("am-1", PASSWORD)
client.on_connect = on_connect
client.on_message = on_message

client.connect("localhost", 1883, 60)

client.loop_forever()

感謝各位的閱讀，以上就是“基于MQTTv5的智慧園區消息總線系統設計怎么實現”的內容了，經過本文的學習后，相信大家對基于MQTTv5的智慧園區消息總線系統設計怎么實現這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！