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 | 發佈QoS=1 | { "device":2 } |
|
| 開門指令 用戶App觸發->Server->IoT->機櫃 |
/${pk}/${dn}/user/pop | 訂閱QoS=1 | { "device":2 } |
|
| 設備上報 開門是否響應 |
/${pk}/${dn}/user/borrow | 發佈QoS=1 | { "device":2 } |
|
| 廣告播放 播放記錄 |
/${pk}/${dn}/user/ad/play | 發佈QoS=1 | { "adId":14323 } |
|
| 添加廣告資源 | /${pk}/${dn}/user/ad/new | 訂閱 QoS=1 |
{ "adId":732124, "uri":"https://ad.com/732124" } |
|
| 刪除廣告資源 | /${pk}/${dn}/user/ad/delete | 訂閱 QoS=1 |
{ "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場景的需求梳理和業務協議設計。