IoT平台业务通信Topic设计最佳实践(共享场景为例)

1.背景

当我们的设备和IoT物联网平台建立mqtt连接通道后,会根据业务需求传输不同的数据。本次实战以共享充电宝业务场景讲解topic和payload的设计。

在共享充电宝场景中,我们会涉及到C端用户操作:

  • 在App端扫码下单,借出充电宝,触发后台下发指令到当前机柜,弹出充电宝。
  • 充电完毕,直接归还充电宝到机柜,触发订单结算

商家后台交互操作:

  • 下行指令
    • 弹出充电宝
    • 广告的添加/删除
  • 设备数据处理
    • 用户取走充电宝的消息的处理,订单生效
    • 用户归还充电宝的消息的处理,订单结算
    • 广告播放的记录存储

2.设计方案

总体思路如下:

  • 根据业务不同划分不同topic,每个topic对应payload结构体。
  • 当数据发送到IoT平台,我们通过规则引擎把数据分流到多个mq队列或DB。
  • 不同优先级队列,DB分配不同计算资源,配置降级策略

2.1 上行数据逻辑

下图展示了设备数据上行场景的划分和后台系统不同处理方式
IoT平台业务通信Topic设计最佳实践(共享场景为例)

2.2 下行控制指令

下图展示了云端下行控制指令的来源和完整链路
IoT平台业务通信Topic设计最佳实践(共享场景为例)

3.通信Topic和Payload定义

按照以上分析,整理出在这个场景中的Topic和Payload细节参考表格,如下:

分类 topic 权限 payload 备注
NTP服务 /ext/ntp/${pk}/${dn}/request 发布 {
"deviceSendTime":"1000"
}
IoT平台提供
/ext/ntp/${pk}/${dn}/response 订阅 {
"deviceSendTime":"1000",
"serverRecvTime":"1543475763010",
"serverSendTime":"1543475763020"
}
IoT平台提供
定时上报
每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"
}
IoT平台提供

具体实现过程中,业务payload还会id用于实现消息去重逻辑。

至此,我们完成了IoT场景的需求梳理和业务协议设计。

IoT平台业务通信Topic设计最佳实践(共享场景为例)

上一篇:如何排序 MFC的CStringArray


下一篇:linux服务器限制访问