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