共计 1321 个字符，预计需要花费 4 分钟才能阅读完成。
在基于位置服务的移动应用领域，移动设备端和服务端之间总是存在大量的交互。设备向服务端发送它的位置信息和其它设备信息，服务端接收这些数据，对它们进行处理，并返回给设备端一些命令。设备端根据这些命令执行一些操作，比如 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 平台。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-11/137478.htm
