掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

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

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

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
从HTTP到MQTT:一个移动后端案例概述
发布:2016-12-01 14:05:04

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

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

选择想要的接口, 看看能免费获取多少次调用 选择(单选)或填写想要的接口
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 证件识别
  • 企业工商信息
短信API服务
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 证件识别
  • 企业工商信息
  • 确定
选择您的身份
请选择寻找接口的目的
预计每月调用量
请选择预计每月调用量
产品研发的阶段
请选择产品研发的阶段
×

前往领取
讯飞星火认知大模型API
0512-88869195
数 据 驱 动 未 来
Data Drives The Future