新零售电子价签解决方案由阿里云微消息队列 MQTT 推出,通过 MQTT 以实现商场超市、公共场所电子标签、多媒体屏幕的数据更新管理。本文将以电子价签为例详细描述该解决方案的系统架构、数据流设计以及注意事项,其他类似行业可参考该方案修改适配。

名词解释

MQTT
一种物联网和移动互联网领域的行业标准协议,适合移动终端之间的数据传输。微消息队列 MQTT 默认支持该协议。
MQTT 服务器
微消息队列 MQTT 提供的 MQTT 协议交互的服务端节点,用于接收消息并转发消息。
MQTT 客户端
用于和 MQTT 服务器交互的节点,本方案中特指发送或接收价格变更消息的智能 AP。
P2P 消息
微消息队列 MQTT 在标准的 MQTT 协议基础上提供的一种特殊消息,该类型消息无需普通的订阅关系匹配,便可直接发送给指定的单个目标 MQTT 客户端。详情请参见 P2P 消息收发模式(MQTT)
智能 AP
市面常见的智能路由器等网络设备,支持应用编程,可以同时承担互联网接入以及局域网设备控制等工作。
电子价签
实际分布在商场超市等场所中的电子显示屏幕,一般使用蓝牙、ZigBee 等无线传感网络协议和智能 AP 节点组网。
电子价签管控服务
电子价签系统中用于管理电子屏幕显示内容的后台服务,主要承担改价等人工操作的任务管理和查询工作。
RDS
阿里云推出的一种稳定可靠、可弹性伸缩的在线数据库服务。在电子价签系统中用来持久化改价等任务的状态变更。
SLS 日志存储
阿里云推出的日志存储服务,在电子价签系统中用来持久化保存所有操作日志,用于审计和溯源。

方案架构

在电子价签解决方案中,微消息队列 MQTT 与阿里云多个产品结合使用,实现价签的数据更新管理。图 1 展示了针对电子价签系统的解决方案架构。

图 1. 方案架构


图 1 所示,在电子价签系统中,主要包含价签节点、智能 AP 节点、微消息队列 MQTT、消息队列 MQ、电子价签后台管控服务、RDS 以及 SLS。各个组件介绍如下:
  • 智能 AP 负责转发上报价签的状态数据,并接收改价指令。智能 AP 按照门店或者场所分布,内部使用 MQTT SDK 从公网接入阿里云微消息队列 MQTT,该链路采用 SSL/TLS 加密传输,防止数据泄露。
  • 一个智能 AP 下行链路和若干价签节点通过蓝牙、ZigBee 等无线传感网络协议组网,完成局域网内部数据交互。
  • 电子价签后台管理服务部署在云端(云服务 ECS),使用消息队列 MQ 的 SDK 和消息队列 MQ 交互,MQTT 服务端和 MQ 服务端天然互通。
  • 电子价签后台管理服务可以将改价等任务的状态变更持久化到 RDS 数据库以确保任务变更成功,并将价签上报数据和操作日志存储到 SLS,方便溯源和审计。

方案优势

新零售电子价签解决方案的优势如下所述:

  • 服务能力强,可弹性伸缩
    • 微消息队列 MQTT 消息传输能力无限扩展,智能终端数量增加无需担心系统能力不足。
    • 微消息队列 MQTT 支持百万级设备毫秒级推送完成,电子价签屏显更新延迟更小。
  • 适用范围广,通用性好,可快速复制
    • 基于 MQTT 标准协议实现,通用性好,方案只需简单适配数据内容即可快速复制到其他相似场景。
  • 安全可靠
    • 微消息队列 MQTT 服务和智能 AP 节点数据传输支持 SSL/TLS 加密,无需担心媒体商业数据泄露。
    • 所有服务节点高可用,稳定性高。

数据交互

状态上报

  1. 电子价签节点会采用定时轮询机制和智能 AP 节点交换数据,上报自己当前的显示状态、节点电量等信息。
  2. 智能 AP 节点组织数据,并发送 MQTT 消息到 MQTT 服务器。
  3. MQTT 服务器会将上报消息写入业务方指定的消息队列 MQ Topic。
  4. 电子价签管控服务通过接收消息队列 MQ 消息,处理分析当前系统中在线的价签节点的状态,并将数据记录到 SLS。

更新屏显

  1. 电子价签管控服务发送改价的消息队列 MQ 消息,触发改价操作。
  2. MQTT 服务端会路由该消息队列 MQ 消息,将消息通过 MQTT 协议推送给目标智能 AP 节点。
  3. 智能 AP 节点收到改价通知,将任务暂存。
  4. 电子价签节点会采用轮询机制和智能 AP 节点交换数据,感知新的屏显内容。
  5. 目标电子价签节点改价成功后,智能 AP 节点回发一条应答 MQTT 消息,通知电子价签管控服务当前任务已完成。
  6. 电子价签管控服务将当前任务的执行记录写入 SLS 日志,方便后续溯源查询。

注意事项

上述流程简要描述了如何使用微消息队列 MQTT 和消息队列 MQ 来搭建电子价签系统,具体的 SDK 说明请参见微消息队列 MQTT以及消息队列 MQ 文档。

其中使用微消息队列 MQTT 和消息队列 MQ 进行指令传输时,相关的消息类型设计以及参数设计请尽可能遵循如下原则:

  • SDK 和协议选择

    电子价签场景中,一个应用可能存在成百上千的线下门店,一般每个门店配备若干个智能 AP 节点,智能 AP 节点会随着业务规模上升而增加,所以智能 AP 节点适合使用 MQTT 协议接入,而电子价签管控服务由于部署在云端,适合使用云上的消息队列 MQ 接入。

  • 客户端 ID 映射

    MQTT 协议要求每个客户端都有一个全局唯一的 Client ID,Client ID 由以下两部分组成,这两部分通过 “@@@” 分隔符连接,只需要保证最终的 Client ID 唯一且总长度不超过 64 个字符即可:
    • 前缀 Group ID:Group ID 需在微消息队列 MQTT 控制台申请。Group ID 按照平台供应商或者渠道进行粗分类,例如不同的行业、批次分成不同的 Group ID,或者不同版本的客户端使用不同的 Group ID,方便问题定位。
    • 后缀 Device ID:Device ID 由应用生成。Device ID 可以使用智能 AP 节点的 MAC 地址等唯一性信息编码。

    Client ID 的更多信息请参见名词解释

  • Topic 名称映射

    使用微消息队列 MQTT 收发消息需要了解 MQTT 协议订阅关系的模型,详情请参见协议文档官网文档

    MQTT 是遵循发布/订阅模型的消息协议,订阅关系和 Topic 符合目录树格式,Topic 可分为父级 Topic 和子级 Topic,Topic(包含父级 Topic 和子级 Topic)的总长度不能超过 64 个字符:
    • 父级 Topic:通常称目录树第一级的 Topic 为父级 Topic。父级 Topic 需要在微消息队列 MQTT 控制台申请后才可使用,申请后相当于一个 Namespace。
    • 子级 Topic:目录树第一级的 Topic 的后续部分称为子级 Topic。子级 Topic 无需申请,业务方可以随意指定。

    Topic 的更多信息请参见名词解释

    业务方设计用于消息收发的 Topic 时,需要遵循以下原则:

    • 不同类型的任务使用不同的父级 Topic,例如本场景中,改价任务和终端状态上报使用不同的父级 Topic。
    • 对于电子价签系统中,改价任务的交互消息建议使用微消息队列 MQTT 提供的 P2P 消息,P2P 消息不需要订阅,发送方直接指定对端接收即可,详情请参见P2P 消息收发模式(MQTT)
  • 收发消息参数设计

    由于电子价签场景改价任务一般要求实时推送,建议在智能 AP 和 MQTT 服务器交互过程中,智能 AP 做以下配置,以确保智能 AP 无需处理掉线期间的任务:
    • cleanSession 参数设置为 “true”
    • QoS 设置成 “1”
    智能 AP 应该对收到的消息做去重以及时效性校验。

    cleanSession 和 QoS 的更多信息,请参见名词解释