IoT(Internet of Things),是当下出现频率非常高的一个词汇,无论是可穿戴设备、工业设备、商用设备通过连接互联网,实现彼此协作以及和后端服务协同交互,极大提高了设备灵活性,高可用性。
互联网的基础协议是TCP/IP。而MQTT是基于TCP/IP协议栈构建,相比其他协议更为简单,而且生态系统丰富,受到广大开发者的青睐。相比传统的HTTP协议,MQTT协议有如下优势:

  • 协议轻量级,带宽占用小
  • 通过业务层设计能实现全双工通信
  • 实时通信
  • 灵活的订阅发布模式
  • 协议简单

MQTT协议简介

MQTT 最初由 IBM 于上世纪 90
年代晚期发明和开发。它最初的用途是将石油管道上的传感器与卫星相链接。顾名思义,它是一种支持在各方之间异步通信的消息协议。异步消息协议在空间和时间上将消息发送者与接收者分离,因此可以在不可靠的网络环境中进行扩展。虽然叫做消息队列遥测传输,但它与消息队列毫无关系,而是使用了一个发布和订阅的模型。在
2014 年末,它正式成为了一种 OASIS 开放标准,而且在一些流行的编程语言中受到支持(通过使用多种开源实现)。

模型简介:

1599093713(1).png

在整个MQTT协议中有三个角色,分别是:发布者(Publisher)、代理(Broker)、订阅者(Subscriber)。如果以C-S架构来看发布者和订阅者都是客户端,代理是服务器,发布者和订阅者是独立的也是相对的。

完整流程

启动Broker,订阅者向服Broker订阅相关主题,发布者向Broker代理发布主题信息,订阅和发布没有前后顺序依赖,Broker代理向所有订阅该主题的订阅者推送消息。

客户端 Client

使用MQTT的程序或设备。客户端总是通过网络连接到服务端。它可以

  • 发布应用消息给其它相关的订阅者。
  • 订阅以请求接受相关的应用消息
  • 取消订阅以移除接受应用消息的请求。
  • 从Broker断开连接。

服务端Broker
一个程序或设备,作为发送消息的客户端和请求订阅的客户端之间的中介。Broker

  • 接受来自客户端的网络连接
  • 接受客户端发布的应用消息
  • 处理客户端的订阅和取消订阅请求。
  • 转发应用消息给符合条件的客户端订阅。

订阅 Subscription
订阅包含一个主题过滤器(Topic Filter)和一个最大的服务质量(QoS)等级。其中0标识只投递一次,1标识最少投递一次,2标识有且只投递一次。订阅与单个会话(Session)关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。

主题名 Topic Name
附加在应用消息上的一个标签,服务端已知且与订阅匹配。Broker代发送应用消息的一个副本给每一个匹配的客户端订阅。
主题名称(Topic name)用来标识已发布消息的信息的渠道。订阅者用它来确定接收到所关心的信息。它是一个分层的结构,用斜线“/”作为分隔符。订阅中包含的一个表达式,用于表示相关的一个或多个主题。主题过滤器可以使用通配符。主题还可以通过通配符进行过滤。其中,“+” 可以过滤一个层级,而“#”只能出现在主题最后表示过滤任意级别的层级。
值得注意的是MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。

会话 Session
客户端和Broker之间的状态交互。一些会话持续时长与网络连接一样,另一些可以在客户端和Broker的多个连续网络连接间扩展。

MQTT技术选型

Broker:
Mosquitto https://mosquitto.org/
EMQ https://www.emqx.io/cn/

工具:
eclipse paho

具体业务实践

某网络接入设备运维管理平台设计

该设备主要提供网络接入,上网行为管理,特殊场景下网络接入能力。需要将该设备纳入到管理体系之下,具备在线更新固件、远程配置、批量配置、上网行为远程管理等功能。
通过分析以上需求,结合设备自身能力,我们最终在业务交互层选用了MQTT+HTTP的协议交互方式。HTTP协议简单,但是无状态,需要借助MQTT的实现全双工实时通信能力。
我们将业务层核心分为如下几个方面:

  • 设备状态报告
  • 设备配置下发
  • 设备业务数据上报
  • 控制指令下发

报告类的数据基本都是通过HTTP协议上报到平台,下发类业务走MQTT协议,通过MQTT会话和遗嘱特性实现对设备精准上下线管理。MQTT消息在整个业务系统作为消息通道来使用,
并没有过多参与到整个业务系统中来。

如果单从消息中间件来说有很多可选项,如果客户端没有太多限制可选方案很多,比如:RocktMQ,RabbitMQ等。

经验总结

  • client_id重复问题,如果系统内有两个重复的cient_id会导致抢夺连接的情况,高频词访问的情况下产生冲突,低频次情况下这种隐藏的bug很难排查,如果客户端id不参与业务,则client_id交由Broker维护。
  • Topic设计需要和业务匹配,尽可能的按层次设计,如果有必要需要将不同业务的不同设备也纳入到层次中。
  • 精简,不添加可有可无的功能;
  • 把传输量降到最低以提高传输效率,把低带宽、高延迟、不稳定的网络等因素考虑在内;
  • 理解客户端计算能力可能很低,合理对技术选型;
  • 提供服务质量管理,QoS的使用一定要慎之又慎,否则极易引起业务异常;
  • 假设数据不可知,不强求传输数据的类型与格式,保持灵活性。

Tags: mqtt, 物联网

Related Posts:

Leave a Comment