从 HTTP 到 MQTT:一个移动后端案例概述

  • 薛命灯

2016 年 11 月 23 日

话题:移动语言 & 开发架构运维

在基于位置服务的移动应用领域,移动设备端和服务端之间总是存在大量的交互。设备向服务端发送它的位置信息和其它设备信息,服务端接收这些数据,对它们进行处理,并返回给设备端一些命令。设备端根据这些命令执行一些操作,比如 GPS 数据的收集和发送频率等。

设备端和服务端之间可以通过多种通信协议进行交互,比如 HTTP(同步)或者基于消息传递的异步协议。因为移动网络的不稳定性,在选择通信协议时要综合考虑它的稳定性和性能。同时,考虑到移动设备对电池使用时间的敏感度,最好能够选择一个相对比较节省资源的协议,这样可以减少对电池的消耗。

HTTP 是一种同步无状态的协议,不支持推送,设备端需要通过轮询模拟推送,反复的轮询需要耗费额外的资源。相比之下,另一种基于消息传递的协议MQTT在这种情况下似乎更有优势:

  • MQTT 可以保持设备与服务器之间的长连接,避免反复的轮询,减少资源消耗,所以更加省电
  • MQTT 可以在设备和服务器之间建立双向连接,从而可以使用推送

有一个基于位置服务的移动项目,最开始使用的是 HTTP 协议,但是基于上述的原因,需要使用 MQTT 来替换 HTTP。下面来看看如何实现这个架构的演变。

首先,在 EC2 上安装一个Mosquitto代理。设备端把原先 HTTP 里的消息头和消息体合并到一个 MQTT 消息里,并发送到 Mosquitto 代理的一个主题上。后端的 API 端点对这个主题进行订阅,然后处理接收到的消息。API 服务对消息进行处理后,把相应的响应消息发回 Mosquitto 代理,再推送给设备端。

不过在有多个 API 服务器的情况下,存在重复处理消息的问题。因为多个 API 服务器同时订阅相同的主题,它们会收到一个消息的多个拷贝。为了解决这个问题,在系统里引入了 AWS 的IoT。AWS IoT 在它的内部使用了 MQTT 代理,同时包含了一个强大的规则引擎,可以利用这个引擎对 Mosquitto 的消息进行处理,比如把它们保存起来,发送通知或者使用 lambda 函数处理消息的响应。不过这里需要先把 Mosquitto 和 AWS IoT 桥接起来,这样消息就可以进入到 AWS IoT。然后使用 lambda 函数对消息进行处理,抽取消息里的消息头和消息体,最后调用后端的 HTTP API 服务。

使用这套架构会涉及到:

  • QoS - MQTT 提供了三层 QoS。这个是非常重要的,因为在底层网络不是很稳定的时候,MQTT 仍然能通过重试等手段保证消息可以被正确送达。
  • 消息保留 - MQTT 可以为每个主题保留最后一个消息。这对客户端来说,可以反应主题的状态。
  • 处理 MQTT 消息 - 设置一个 Mosquitto 代理并让消息流入这个代理是很容易的,但因为缺少第三方包,要让一般的规则引擎来出来这些消息有点棘手。所以最后选用了 AWS IoT 自带的规则引擎。
  • 日志 - 需要对 Mosquitto 的日志进行捕捉,并保存起来,方便监控和问题定位。可以使用 remote syslog 来把日志传输到Papertrail

除了服务器端,在客户端也需要使用 MQTT 的客户端包。MQTT 有各种语言客户端,并支持 Android、iOS 平台。


感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

移动语言 & 开发架构运维