朱艷

摘要：隨著智能設備的快速普及和移動應用的迅猛發(fā)展，已進入移動互聯(lián)網(wǎng)時代。消息推送是移動應用的一個顯著特征，是移動互聯(lián)網(wǎng)時代的基礎設施。蘋果和谷歌都提供消息推送服務，但并不能滿足企業(yè)級移動應用的推送要求。MQTT協(xié)議是由IBM提出的面向物聯(lián)網(wǎng)的通訊協(xié)議，其簡潔，高效，可靠等特征非常適合用于構建消息推送服務。文章討論了使用MQTT協(xié)議構建消息推送服務的必要性和適用性，并指出了在具體實現(xiàn)上應注意的一些關鍵問題，同時給出了相關建議。

關鍵詞：移動應用；消息推送；MQTT

1消息推送是移動應用的基礎功能

現(xiàn)今已經(jīng)從互聯(lián)網(wǎng)時代快速進入到了移動互聯(lián)網(wǎng)時代。根據(jù)相關資料，早在2014年，智能手機和平板電腦的銷售量就已經(jīng)超過了傳統(tǒng)Pc的銷售量，而且這一趨勢還在不斷加強，以智能手機為主的移動設備仍然在高速增長。

信息化系統(tǒng)建設也相應地轉向移動設備，傳統(tǒng)的基于桌面瀏覽器的應用系統(tǒng)日漸式微，移動應用（APP）已成為主流趨勢。以前的熱門網(wǎng)站不再受到人們的追捧，取而代之的是運行在手機上的各種APP0一個顯著的例子是微信和QQ，同樣由騰訊公司開發(fā)的社交應用，兩者分別代表了移動互聯(lián)網(wǎng)和傳統(tǒng)互聯(lián)網(wǎng)，微信的歷史只有短短的4-5年，但其活躍用戶數(shù)已經(jīng)遠超歷史悠久的QQ。在企業(yè)內(nèi)部，政府部門、事業(yè)單位內(nèi)部，也紛紛調(diào)整其信息化建設，向移動應用方向傾斜，移動化已成為共識。

移動應用作為一種新的應用類型，與傳統(tǒng)基于桌面的瀏覽器/服務器（Browser/Server）架構相比較，在應用場景，交互方式，開發(fā)技術等方面都有所不同。對于使用者而言，移動應用將其從電腦前解放了出來，使用者可以在任何時間，任意地點打開移動應用，瀏覽自己所需要的信息，或者進行相應的操作，只需設備聯(lián)網(wǎng)即可。這種便利性使得移動應用迅速受到使用者的歡迎。而且，由于移動設備隨身攜帶，并一直保持網(wǎng)絡連接狀態(tài)，移動應用能夠做到主動的消息推送和提醒，而無需使用者不時打開應用去查看，實現(xiàn)了信息主動找人。

消息推送是移動應用的基礎功能，是移動互聯(lián)網(wǎng)時代的重要基礎設施，是移動應用區(qū)別于傳統(tǒng)應用的一個重要特征和優(yōu)勢，可以說，沒有消息推送的移動應用就不能稱之為移動應用。

2現(xiàn)有推送服務及問題

根據(jù)移動操作系統(tǒng)的不同，當前移動領域主要分為兩個體系：蘋果公司的iOS系統(tǒng)和由谷歌公司主導的Andriod系統(tǒng)。這兩大陣營都意識到了移動消息推送在移動應用建設上的基礎性地位，并提供了相應的推送服務，供開發(fā)者或企業(yè)用戶調(diào)用。但是，無論是蘋果還是谷歌的推送服務，都存在服務質量，安全性，處理容量等問題，特別是對于企業(yè)、政府等高端用戶而言，這些推送服務都無法滿足實際需要。

2.1蘋果推送通知服務（APNS，Apple Push NotificationService）

蘋果為全球范圍的lOS設備提供推送通知服務。當服務的提供方（Provider）希望給某個設備上的應用推送消息時，需要調(diào)用蘋果APNS提供的推送服務，將目標設備（設備令牌）和消息內(nèi)容（有效載荷）傳遞給APNS服務，APNS會負責找到相應的目標設備，并將消息傳遞給該設備；該設備收到消息后，會將消息傳給相應的應用APP，由APP處理消息，提醒用戶。其處理過程在蘋果的開發(fā)者網(wǎng)站有詳細描述如圖1所示。

從實際使用情況看，APNS服務比較穩(wěn)定，一般情況下消息也能被及時傳遞，基本能夠滿足一般性消費類移動應用的需要。但是，對于具有更高消息推送要求的企業(yè)級市場，APNS就顯得力不從心，具有以下問題。

（1）不保證消息到達。如果移動設備暫時無法聯(lián)網(wǎng)，服務的提供方也可以推送消息，蘋果會負責暫時保存該消息；當設備再次可用時，保存的消息會被推送。但是，蘋果只會為同一個設備保留最近的一條消息。如果在設備持續(xù)無法聯(lián)網(wǎng)的情況下，服務提供方再次推送消息，會導致上一條推送消息的丟失，而且不會告知。這對于普通消費型應用問題不大，但對于企業(yè)級應用則不然，特別是對于某些重要性很高，而且推送消息很頻繁的移動應用而言，隨意丟棄消息是不可接受的。

（2）不保證消息傳遞時效。APNS服務宣稱會盡快傳遞消息，但不保證多長時間內(nèi)可以傳遞到，不能要求限時到達。而且，它沒有消息優(yōu)先級的設置，所有的消息都按照同樣的優(yōu)先級傳遞，不能對消息區(qū)別對待。

（3）消息大小有限制。如果移動設備的操作系統(tǒng)不是最新的iOS 8，那么推送消息內(nèi)容不能超過256字節(jié)，只能用來傳遞一些最簡單的消息。企業(yè)級應用中，這么小的數(shù)據(jù)量幾乎是無法使用的。如果將移動設備升級到iOS 8，最大推送字節(jié)數(shù)會增加到2000字節(jié)。很多情況下，這一數(shù)值也無法滿足企業(yè)級移動應用的要求。

（4）發(fā)送頻率受控。蘋果官方對單位時間內(nèi)允許推送的消息數(shù)沒有限定，但在實際使用時發(fā)現(xiàn)，如果與推送服務器建立的網(wǎng)絡連接數(shù)過多，或者推送消息的頻率過于密集，都會導致蘋果拒絕服務，無法推送。

（5）不支持消息回執(zhí)。最終用戶有沒有收到消息？如果客戶端收到了，具體是什么時間點收到的？這種需求對于企業(yè)應用很常見，但APNS并沒有提供類似的消息回執(zhí)機制。

（6）無法控制數(shù)據(jù)安全。雖然APNS提供了相應的數(shù)據(jù)傳輸安全機制，確保在傳輸過程中的安全，但數(shù)據(jù)畢竟是經(jīng)過蘋果的服務器傳遞，而且，如果設備不在線，消息還會在蘋果的服務器上保存。這對于一些對數(shù)據(jù)敏感性有要求的組織或機構而言是不允許的。某些要求嚴格的企業(yè)，甚至會要求移動設備全部使用VPN專有網(wǎng)絡，所有的互聯(lián)網(wǎng)服務都不允許訪問，這種情況TAPNS就更無法使用了。

2.2谷歌云推送（GcM，Google Cloud Messaging forAndroid）

與蘋果類似，谷歌也為Android設備提供了一個公共的消息推送服務，其架構如圖2所示。與APNS類似，第三方應用需要推送消息時，只需要連接到一個GCM服務器，調(diào)用消息推送服務，就可以將消息傳遞到指定的移動設備，并喚起相應的移動應用。

谷歌云推送在功能上較APNS有不少增強，支持包括消息回執(zhí)功能，send-to-sync消息機制等，其最大可推送的消息內(nèi)容也較蘋果的大，為4000字節(jié)。

但是，現(xiàn)實的情況是，由于網(wǎng)絡原因，谷歌的推送服務在國內(nèi)根本無法訪問，無法訪問谷歌的GCM服務器，谷歌的GCM服務器也無法與我們的移動手機建立推送連接。而且，消息推送需要手機與服務器兩者的相互配合，手機端必須具備相應的GCM接收服務，才能接收到推送的消息，但由于Android手機廠商的分裂狀態(tài)，幾乎每個手機廠商都會用自己的推送服務替代原有的GCM接收服務，這就導致即使GcM月艮務器可以訪問，手機端也無法接收到消息。除非能全部限定所有的移動設備為同一家供應商，否則也無法使用手機廠商提供的推送服務。而現(xiàn)實中，幾乎不存在這種設備完全由同一個廠商供應的可能性。

需要說明的是，基于谷歌一貫的開放策略，GCM也是一個開放性的標準，任何人或企業(yè)都可以直接使用谷歌提供的推送云服務，也可以自行根據(jù)GCM服務端的標準規(guī)范實現(xiàn)私有的GCM推送服務。不過，GCM在消息通訊協(xié)議上只有HTTP和XMPP兩種選擇，這兩種協(xié)議無論從傳輸效率，可靠性角度，還是從安全的角度看，都不是最適合移動應用的協(xié)議。

綜上所述，消息推送作為一個新的技術話題，在協(xié)議規(guī)范和技術標準方面都還沒有形成業(yè)界標準，蘋果和谷歌作為業(yè)界領先的兩大企業(yè)，雖然提供了針對各自平臺的推送服務，但都存在不同程度的問題，特別是對于企業(yè)級高端用戶而言。

構建消息推送服務是一個系統(tǒng)工程，需要進行完備的架構設計。這其中，推送協(xié)議的選擇至關重要，不同的協(xié)議會直接影響推送的速度，服務質量和用戶滿意度。

3MQTT協(xié)議

消息隊列遙測傳輸（MQTT，Message QueuingTelemetry Transport）協(xié)議是IBM公司提出的開放協(xié)議，最初的設想是應用于大量計算能力有限的傳感器等微型設備，其工作的網(wǎng)絡帶寬低且不穩(wěn)定，但又需要保證網(wǎng)絡節(jié)點之間的可靠通訊。

該協(xié)議目前已經(jīng)被結構化信息標準促進組織（OASIS）接受，并將其建議為物聯(lián)網(wǎng)消息傳遞協(xié)議的首選標準。MQTT已經(jīng)成為物聯(lián)網(wǎng)領域的事實標準，IBM公司已經(jīng)成功將其應用于智能實驗室、遠程醫(yī)療中心等項目，并推出了MessageSight等MQTT中間件產(chǎn)品，其它企業(yè)和機構也相繼跟進，發(fā)布支持MOTT協(xié)議的開源/商業(yè)產(chǎn)品，或采用MQTT協(xié)議構建相關應用。伴隨著物聯(lián)網(wǎng)的迅猛發(fā)展，MQTT協(xié)議未來的發(fā)展不可限量。

由于物聯(lián)網(wǎng)傳感器等設備的計算能力和電量都非常有限，因此MQTT的設計理念從一開始就是簡單，輕量，節(jié)省電力，這正好滿足了移動應用的一個重要訴求。當前電池儲能技術的發(fā)展遠遠不能滿足智能手機的發(fā)展需要，使用智能手機用戶最痛苦的事情就是手機耗電太快，手機的電量甚至不能支持完8小時的工作時間。但如果要保證消息及時到達，手機就必須時刻保持與服務器的連接，并定期與其通訊，檢查是否有新消息。MQTT協(xié)議非常精簡，額外的數(shù)據(jù)傳輸量非常小，可以在最大限度節(jié)省電力，同時也節(jié)省網(wǎng)絡流量。這是選擇MQTT構建消息推送服務的最大原因。

MOTT協(xié)議的消息頭固定為2個字節(jié)，當前只使用了第一個字節(jié)，第二個字節(jié)保留。第一個字節(jié)共8個bit位，前4位為控制類型，可取值為16種，按照功能可以分為連接類，訂閱類，保持活動類幾種，后4位攜帶每種控制類型的特有信息如表1所示。

作為對比，讓我們來看看最常見的HTTP協(xié)議的消息頭，如圖3所示為訪問百度主頁（www.baidu.com）時，HTTP請求所提交的消息頭信息，其數(shù)據(jù)量超過300字節(jié)，是MQTT協(xié)議（2個字節(jié)）的150倍。而且，這只是一個比較小的HTTP消息頭，如果用戶多次訪問同一網(wǎng)站，會有不斷增長的Cookie信息，消息頭的內(nèi)容會更多。

為了實現(xiàn)及時推送，手機需要周期性給服務器發(fā)送請求（心跳），以保持與消息推送服務器的連接不中斷。假設手機每30秒發(fā)送一次心跳，每天就需要發(fā)送2880次，如果采用MQTT協(xié)議，只需5k的通訊流量，而如果采用HTTP方式，則需要的流量為864k，其高下一目了然。而手機需要消耗的電力與需要傳輸?shù)臄?shù)據(jù)量直接相關。

除了短小精悍，節(jié)約帶寬，節(jié)省電量消耗，MQTT協(xié)議還具有其它的特性，非常適合用于構建移動應用的消息推送服務。

（1）保證服務質量。MQTT提供三種消息傳輸?shù)姆召|量保障水平，用戶可以根據(jù)實際需要進行選擇：

QoS0：至多傳遞一次。消息有可能會丟失。這種服務質量下，消息傳遞的速度最快，但不能保證消息的可靠到達。通常適用于網(wǎng)絡環(huán)境差，而且不在意單次數(shù)據(jù)丟失的情況，例如GPS數(shù)據(jù)的采集。

QoS1：至少傳遞一次?？梢源_保消息被可靠傳遞到目標，但可能會有消息被重復傳遞。這種服務質量權衡了傳輸效率和消息可靠性，最常被采用。

QoS2：確定只傳遞一次。消息不會被丟失，也不會被重復傳遞。這種服務質量被用來保證最高的消息傳遞服務質量。

（2）連接中斷通知。與物聯(lián)網(wǎng)類似，手機的網(wǎng)絡質量遠不能與連接網(wǎng)線的臺式機相比，當我們發(fā)生位移時，或者進入電梯，地下室等區(qū)域時，手機經(jīng)常會發(fā)生基站切換，網(wǎng)絡信號消失，連接中斷等情況。MQTT協(xié)議可以很好地適應這種不穩(wěn)定的網(wǎng)絡環(huán)境，并且保證數(shù)據(jù)的可靠傳輸。而且，當發(fā)生網(wǎng)絡異常中斷時，MQTT還支持遺囑機制，將網(wǎng)絡中斷事件通知給指定的目標對象。

（3）信息廣播機制。MQTT采用發(fā)布/訂閱機制來傳遞信息，多個手機終端可以訂閱同一個主題；服務端只需要針對主題發(fā)布信息，所有訂閱者都可以收到，而無需對逐個手機發(fā)送，簡單高效。例如，股票價格信息，不同的人可以訂閱關注同一個股票的價格信息，當該股票的價格發(fā)生變化時，服務端只需發(fā)布一次最新價格，所有的訂閱者都會收到同樣消息。

4其它問題

在采用MQTT協(xié)議構建移動應用的消息推送服務時，也應當了解MQTT的不足，并妥善處理如下問題。

4.1避免客戶端越權訂閱

MQTT采用發(fā)布/訂閱模式處理消息傳遞，消息是針對主題傳遞，而不是目標客戶端?？蛻舳酥灰M行訂閱，就可以收到消息。理論上，如果某個客戶端訂閱了根主題，就可以收到所有人的消息，這是不可接受的。

可以啟用MQTT的用戶認證機制，只有經(jīng)過認證的用戶才可以訂閱主題，但這只能防止非認證用戶的惡意訂閱，對于認證通過的用戶則不起作用。

徹底的解決方法需要在服務端進行控制，不允許用戶訂閱其沒有權限的主題。另外，一些MQTT產(chǎn)品對此也有處理，例如，IBM的MessageSight產(chǎn)品就支持點對點和發(fā)布/訂閱兩種方式，而使用點對點方式時，任意訂閱都不起作用。

4.2處理iOS后臺服務運行

ios系統(tǒng)對于后臺服務的長時間運行有很多限制，MQTT要求與服務端—直保持連接，在iOS系統(tǒng)下不容易做到。當移動APP在前臺運行時，MQTT可以建立并保持與推送服務器的連接，但是，一旦移動APP被推入后臺，所有的活動，包括連接都會被中斷。

iOS允許某些應用在后臺保持運行，但需要經(jīng)過蘋果的-審核，而且服務端還需要定期給移動設備發(fā)送數(shù)據(jù)以保持網(wǎng)絡連接，相對而言較為繁瑣。

另4中解決方式是將MQTT推送與APNS相結合，當MQTT連接被中斷時，推送改為使用APNS通道。當有新消息需要推送時，推送服務器發(fā)送一個APNS的提示消息（沒有具體消息內(nèi)容），然后由APNS消息激活移動應用，喚起MQTT月艮務，再通過MQTT渠道具體的推送消息內(nèi)容。這種方式只將APNS作為一個旁路提醒通道，不傳遞消息內(nèi)容，保證了數(shù)據(jù)的安全性。

4.3可擴展的MQTT服務端

消息推送需要移動設備與推送服務器保持長連接，這與傳統(tǒng)應用不同。傳統(tǒng)的B/s應用是短連接模式，客戶端向服務端發(fā)起請求，服務端處理完成后返回結果給客戶端，然后釋放連接。如果不考慮業(yè)務邏輯處理對服務器資源的使用，單個服務器可以輕松支持幾十萬，甚至上百萬的用戶訪問。但是，如果拿一臺普通的服務器當做消息推送服務器，單臺服務器的連接能力大約在2萬到10萬之間，如果要保證穩(wěn)定的服務能力，客戶端的連接數(shù)通常不允許超過5萬。IBM的MessageSight可以支持100萬的客戶端連接。但不論其數(shù)值多少，單臺服務器的處理能力總有極限。

如果要推送的設備數(shù)量超過了單臺的處理能力，就需要考慮服務端集群。MQTT在服務端的集群擴展方面沒有規(guī)定，需要自行設計實現(xiàn)水平擴展架構。