從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平臺。

來自：http://www.infoq.com/cn/news/2016/11/HTTP-MQTT-Mobile-backend