1.背景
當我們的裝置和物聯網平台建立mqtt連接配接通道後，會根據業務需求傳輸不同的資料。本次以共享快遞櫃業務場景講解topic和payload的設計。
在共享快遞櫃場景中，我們會涉及到C端使用者操作：
- 在App端掃碼，操作快遞存取，觸發背景下發指令到目前機櫃，執行相關操作。
- 使用者存取完畢，觸發訂單結算或其他操作
營運商背景互動操作：
- 下行指令
-
- 開關快遞櫃門
-
- 廣告的添加/删除
- 裝置資料處理
-
- 使用者取走快遞的消息的處理，訂單結算
-
- 使用者寄存的消息的處理，訂單結算
-
- 廣告播放的記錄存儲
2.設計方案
總體思路如下：
- 根據業務不同劃分不同topic，每個topic對應payload結構體。
- 當資料發送到物聯網平台，我們通過規則引擎把資料分流到多個mq隊列、DB、時序資料庫等。
- 不同優先級隊列，DB配置設定不同計算資源，配置降級政策
2.1 上行資料邏輯
下圖展示了裝置資料上行場景的劃分和背景系統不同處理方式
2.2 下行控制指令
下圖展示了雲端下行控制指令的來源和完整鍊路
3.通信Topic和Payload定義
按照以上分析，整理出在這個場景中的Topic和Payload細節參考表格，如下：
| 分類 | topic | 權限 | payload | 備注 |
|---|---|---|---|---|
| NTP服務 | /ext/ntp/${pk}/${dn}/request | 釋出 | { "deviceSendTime":"1000" } | 物聯網平台提供 |
| /ext/ntp/${pk}/${dn}/response | 訂閱 | "deviceSendTime":"1000", "serverRecvTime":"1543475763010", "serverSendTime":"1543475763020" | ||
| 定時上報 每5分鐘 | /${pk}/${dn}/user/bizheart/post | QoS=0 | "battery":69, "devices":[0,1,0,0,0,1,0], "net":84 | |
| 裝置上報 指令響應 | /${pk}/${dn}/user/borrow | 釋出QoS=1 | "device":2 | |
| 使用者上報 使用者開門觸發 | /${pk}/${dn}/user/return | |||
| 開門指令 使用者App觸發->Server->IoT->機櫃 | /${pk}/${dn}/user/pop | 訂閱QoS=1 | ||
| 開門是否響應 | ||||
| 廣告播放 播放記錄 | /${pk}/${dn}/user/ad/play | "adId":14323 | ||
| 添加廣告資源 | /${pk}/${dn}/user/ad/new | QoS=1 | "adId":732124, "uri":"https://ad.com/732124" | |
| 删除廣告資源 | /${pk}/${dn}/user/ad/delete | "adId":32546 | ||
| 裝置狀态變更 | /as/mqtt/status/${pk}/${dn} | "status":"online/offline", "productKey":"pk13543", "deviceName":"dn1234", "lastTime":"2018-08-31 15:32:28.195", "clientIp":"123.123.123.123" |
具體實作過程中，業務payload還會id用于實作消息去重邏輯。
至此，我們完成了IoT場景的需求梳理和業務協定設計。
參考資訊：企業基于物聯網平台最佳業務實作