姜 妮，張 宇，趙志軍

(1．中國(guó)科學(xué)院聲學(xué)研究所高性能網(wǎng)絡(luò)實(shí)驗(yàn)室，北京100190;2．中國(guó)科學(xué)院大學(xué)，北京100049)

1 概述

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展和移動(dòng)終端的普及，人們希望能夠隨時(shí)隨地方便地獲取信息和服務(wù)。用戶獲取信息的途徑主要有拉取(Pull)和推送(Push)2種，相比于Pull不斷輪詢查看是否有新數(shù)據(jù)，需要付出大量的網(wǎng)絡(luò)流量和系統(tǒng)資源，Push由服務(wù)器主動(dòng)將不定時(shí)產(chǎn)生的新消息推送給用戶，更加及時(shí)、高效、省流量、省資源?？紤]到移動(dòng)終端內(nèi)存有限、CPU計(jì)算能力弱、電池容量小、網(wǎng)絡(luò)流量資費(fèi)昂貴等多方面因素，移動(dòng)終端需要更加輕量、優(yōu)化、智能的推送技術(shù)［1］。

雖然目前的消息推送方案很多，但均存在大大小小的問(wèn)題，比如服務(wù)受限、需要收費(fèi)、安全漏洞、個(gè)性化智能推送不足等。其中，安全漏洞和個(gè)性化智能推送不足的問(wèn)題較為明顯。安全問(wèn)題體現(xiàn)在:有些系統(tǒng)任何人知道消息服務(wù)器IP和端口就可以連接運(yùn)行，進(jìn)而攔截消息，惡意攻擊篡改;有些系統(tǒng)雖然加入了用戶名、密碼等身份認(rèn)證，但這些信息很容易被攻克，無(wú)法有效保證消息不被篡改。對(duì)于分布式應(yīng)用來(lái)說(shuō)，發(fā)布或者訂閱的消息是否能夠安全及時(shí)地到達(dá)，并且在傳輸過(guò)程中使消息不丟失、不重復(fù)，保證消息的完整性和可靠性，對(duì)通信雙方都具有非常重要的作用［2-3］。個(gè)性化智能推送不足體現(xiàn)在:系統(tǒng)不會(huì)根據(jù)具體的性能要求和用戶需求的不同而采取合適的處理方法。例如無(wú)法根據(jù)消息的類型，用戶訂閱情況，傳輸?shù)目煽啃?、及時(shí)性和高效性等要求的不同［4］，來(lái)智能選擇不同的通信模式，如點(diǎn)對(duì)點(diǎn)、發(fā)布/訂閱;無(wú)法根據(jù)不同用戶的個(gè)性化需求智能選擇不同的發(fā)送方式，如軟件、郵箱等。

本文提出一種安全智能的基于消息隊(duì)列遙測(cè)傳輸(Message Queuing Telemetry Transport，MQTT)的消息推送系統(tǒng)。MQTT由IBM開(kāi)發(fā)，是一種開(kāi)放、精簡(jiǎn)、輕量級(jí)和容易實(shí)現(xiàn)的協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。IBM和St．Jude醫(yī)療中心通過(guò)MQTT開(kāi)發(fā)了一套Merlin系統(tǒng)，用于遠(yuǎn)程醫(yī)療項(xiàng)目，F(xiàn)acebook發(fā)布的IOS應(yīng)用，采用MQTT更新通知、消息和書簽等。此外，國(guó)內(nèi)很多企業(yè)，諸如 Sohu，Cmstop均有使用MQTT作為Android手機(jī)客戶端與服務(wù)器端推送消息的協(xié)議。本文系統(tǒng)采用MQTT消息傳輸協(xié)議，該協(xié)議采用小型傳輸，耗電量小，大幅降低網(wǎng)絡(luò)流量，特別適合代價(jià)昂貴、計(jì)算和處理能力受限的移動(dòng)終端上的應(yīng)用［5-8］;安全方面加入安全認(rèn)證機(jī)制，可以有效保證系統(tǒng)安全;個(gè)性化智能推送方面加入多樣化智能推送，滿足用戶的個(gè)性化需求和消息傳遞性能要求。

2 現(xiàn)有推送方案

2．1 谷歌Android云通訊

谷歌Android云通訊Google Cloud Messaging(GCM)for Android)［9］是 Google 為 Android 提供的推送服務(wù)，第三方應(yīng)用服務(wù)器可利用該服務(wù)向自己的Android客戶端推送消息。客戶端首先將使用GCM功能的賬戶和程序名稱發(fā)送給GCM服務(wù)器來(lái)獲取注冊(cè)ID，并把注冊(cè)ID告訴自己的服務(wù)器，應(yīng)用服務(wù)器通過(guò)訪問(wèn)Google相關(guān)網(wǎng)站獲取Auth Token，并通過(guò)該Auth Token進(jìn)行推送功能［10-11］。

但經(jīng)過(guò)調(diào)研發(fā)現(xiàn)，這個(gè)服務(wù)存在很大的問(wèn)題，推送服務(wù)受到版本限制(必須大于2．2版本)，該服務(wù)在國(guó)內(nèi)不夠穩(wěn)定，經(jīng)常不可用，需要用戶綁定Google賬號(hào)，受限于Google。

2．2 蘋果推送通知服務(wù)

蘋果推送通知服務(wù)(Apple Push Notification Service，APNS)是蘋果公司在2009年發(fā)布 IOS 3．0時(shí)加入的新功能，該服務(wù)可以讓蘋果移動(dòng)終端與其推送服務(wù)器建立一個(gè)認(rèn)證，并保持一個(gè)IP的長(zhǎng)連接［11］。蘋果服務(wù)器接收來(lái)自第三方的應(yīng)用服務(wù)器的消息，并將消息推送到用戶的終端上，即使用戶的程序處于關(guān)閉狀態(tài)，蘋果終端也可以用 Apple Notification的方式(程序圖標(biāo)、信息彈窗、聲音提示等)提示用戶［11］，與GCM類似，服務(wù)同樣受到限制。

2．3 黑莓郵件推送

黑莓Push Mail推送服務(wù)雖然很好，但是門檻高，需與移動(dòng)運(yùn)營(yíng)商合作，尤其對(duì)于個(gè)人用戶，手續(xù)相當(dāng)復(fù)雜，黑莓代理商不提供個(gè)人用戶的郵件服務(wù)器，需要與一家開(kāi)通黑莓業(yè)務(wù)的企業(yè)掛靠，然后向移動(dòng)申請(qǐng)開(kāi)通郵件推送服務(wù)，耗時(shí)較長(zhǎng)，并且價(jià)錢對(duì)于普通用戶高［12］。

2．4 第三方平臺(tái)

目前國(guó)內(nèi)、國(guó)外有一些推送平臺(tái)可供使用，但是涉及到收費(fèi)、保密、服務(wù)質(zhì)量、擴(kuò)展等問(wèn)題，市場(chǎng)占有率并不高。

3 本文解決方案

3．1 安全設(shè)計(jì)

系統(tǒng)中加入安全認(rèn)證機(jī)制，解決現(xiàn)有的消息推送系統(tǒng)存在安全漏洞這一問(wèn)題。該機(jī)制主要分為兩步，即IP驗(yàn)證模塊和數(shù)字簽名認(rèn)證模塊。通過(guò)設(shè)置IP白名單來(lái)驗(yàn)證用戶的合法性，可以阻擋絕大部分非法請(qǐng)求;通過(guò)數(shù)字簽名認(rèn)證可以進(jìn)一步保證系統(tǒng)信息的安全，防止信息在傳輸過(guò)程中遭到篡改以及非法的攻擊等。

在消息發(fā)布客戶端向消息服務(wù)器發(fā)起連接發(fā)布請(qǐng)求時(shí)，消息服務(wù)器需要對(duì)其進(jìn)行安全認(rèn)證，以決定是否接收該客戶端的連接請(qǐng)求，通過(guò)安全認(rèn)證機(jī)制之后，才能使用消息推送服務(wù)，從而保證了消息推送系統(tǒng)的安全性，安全認(rèn)證機(jī)制流程如圖1所示。

圖1 安全認(rèn)證機(jī)制流程

安全認(rèn)證步驟如下:

(1)發(fā)布者客戶端請(qǐng)求消息發(fā)送服務(wù)之前，先調(diào)用服務(wù)器提供的數(shù)字簽名認(rèn)證服務(wù)生成密鑰對(duì);

(2)發(fā)布者使用生成的私鑰加密生成數(shù)字簽名，并將公鑰、簽名以及數(shù)據(jù)發(fā)送給消息服務(wù)器，請(qǐng)求消息發(fā)布服務(wù);

(3)消息服務(wù)器在接收到發(fā)布者客戶端的消息發(fā)布請(qǐng)求服務(wù)之后，先通過(guò)IP驗(yàn)證模塊，判斷發(fā)布者是否合法，驗(yàn)證通過(guò)則進(jìn)行下一步，否則返回錯(cuò)誤提示給消息發(fā)布者;

(4)消息服務(wù)器使用公鑰、簽名對(duì)數(shù)據(jù)驗(yàn)證，驗(yàn)證成功則進(jìn)行后續(xù)的消息服務(wù)，并返回成功提示給消息發(fā)布者，否則返回錯(cuò)誤提示給消息發(fā)布者。

3．2 個(gè)性化智能推送

系統(tǒng)中加入多樣化智能選擇機(jī)制，解決現(xiàn)有的消息推送系統(tǒng)缺乏個(gè)性化智能推送的問(wèn)題，該機(jī)制包括智能選擇發(fā)送方式模塊和智能選擇通信模式模塊。通過(guò)智能選擇發(fā)送方式模塊，系統(tǒng)可以根據(jù)用戶的個(gè)性化需求智能選擇用戶需要的通信方式，如軟件、郵箱、短信等。通過(guò)智能選擇通信模式模塊，系統(tǒng)可以根據(jù)傳遞消息的類型、用戶訂閱情況等來(lái)判斷使用合適的通信模式，如點(diǎn)對(duì)點(diǎn)模式、發(fā)布/訂閱模式。

在消息發(fā)送前，需要對(duì)要發(fā)送的消息進(jìn)行智能選擇，根據(jù)用戶的需求、消息的類型和消息的訂閱情況來(lái)智能選擇應(yīng)用合適的消息發(fā)送方式和消息通信模式，多樣化智能推送機(jī)制判斷的依據(jù)包括消息是否標(biāo)記過(guò)、接收端是否多、特定用戶是否指定、消息是否多等。多樣化智能選擇機(jī)制的流程如圖2所示。

圖2 多樣化智能推送機(jī)制流程

多樣化智能選擇步驟如下:

(1)當(dāng)收到需要傳遞的消息時(shí)，先要進(jìn)行智能選擇發(fā)送方式的判斷;

(2)看是否有標(biāo)記發(fā)送方式，如果消息發(fā)送方已經(jīng)標(biāo)記了用何種發(fā)送方式，比如MQTT推送、郵件推送、短信推送等，消息服務(wù)器就按照發(fā)送方標(biāo)識(shí)的發(fā)送方式進(jìn)行發(fā)送;如果沒(méi)有標(biāo)識(shí)以何種方式發(fā)送就默認(rèn)MQTT推送;

(3)進(jìn)行智能選擇通信模式的判斷;

(4)查看是否有標(biāo)記通信模式，如果消息發(fā)布方已經(jīng)標(biāo)識(shí)采用什么樣的通信模式，那么消息服務(wù)器就按照發(fā)送方標(biāo)識(shí)的通信模式進(jìn)行傳遞;如果沒(méi)有標(biāo)識(shí)通信模式，則繼續(xù)執(zhí)行下一步;

(5)判斷是否是給特定用戶發(fā)送消息，如果是就采用PTP通信模式，并且將其在消息屬性中進(jìn)行標(biāo)記，以便下次再轉(zhuǎn)發(fā)消息時(shí)方便快捷;

(6)如果不是就繼續(xù)判斷消息是否多，消息的多少由用戶自己設(shè)定一個(gè)閾值，如果消息超過(guò)這個(gè)閾值，就將消息先存入待發(fā)送的消息隊(duì)列;如果消息較少?zèng)]有超過(guò)設(shè)定的閾值，就選擇用Pub/Sub通信模式進(jìn)行消息推送并標(biāo)記。

3．3 消息管理機(jī)制

消息管理機(jī)制包括消息隊(duì)列管理模塊、訂閱表管理模塊、消息匹配轉(zhuǎn)發(fā)模塊，通過(guò)這些模塊的配合實(shí)現(xiàn)消息的處理存儲(chǔ)轉(zhuǎn)發(fā)功能。

3．3．1 消息隊(duì)列管理模塊

實(shí)現(xiàn)異步通信的核心本質(zhì)是隊(duì)列化，消息通過(guò)隊(duì)列進(jìn)行存儲(chǔ)轉(zhuǎn)發(fā)的機(jī)制稱作隊(duì)列管理機(jī)制。隊(duì)列管理機(jī)制是消息隊(duì)列模式的具體實(shí)現(xiàn)，主要有發(fā)送隊(duì)列、接收隊(duì)列、延遲隊(duì)列的管理。發(fā)送隊(duì)列接收消息發(fā)布者發(fā)送的消息，指定消息源地址，以便根據(jù)需要回復(fù)該消息時(shí)使用;接收隊(duì)列是訂閱者的消息接收隊(duì)列，指定了消息發(fā)往的目的地，消息服務(wù)器根據(jù)該信息決定發(fā)往哪個(gè)訂閱者;延遲隊(duì)列的作用是，當(dāng)消息無(wú)法發(fā)送出去時(shí)先保存到延遲發(fā)送隊(duì)列中，當(dāng)與客戶端連接成功后再發(fā)送。

3．3．2 訂閱表管理模塊

該模塊負(fù)責(zé)管理和維護(hù)訂閱表信息，訂閱表記錄了訂閱主題及對(duì)應(yīng)的客戶端訂閱信息［13-14］。

訂閱表管理模塊處理客戶端訂閱消息的算法流程如圖3所示。

圖3 訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對(duì)于客戶端的訂閱消息，首先在訂閱表中查詢是否已經(jīng)存在該訂閱主題，如果不存在該主題，則創(chuàng)建該主題，并創(chuàng)建該客戶端訂閱者信息節(jié)點(diǎn)，否則進(jìn)行步驟(2);

(2)查詢?cè)摽蛻羰欠褚呀?jīng)訂閱了該主題的消息，如果已經(jīng)訂閱該主題消息，則對(duì)訂閱者信息節(jié)點(diǎn)更新修改，否則增加該訂閱者信息節(jié)點(diǎn)。

訂閱表管理模塊處理客戶端取消訂閱消息的算法流程如圖4所示。

圖4 取消訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對(duì)于客戶端取消訂閱消息，首先在訂閱表中查詢是否存在該訂閱主題，如果不存在則結(jié)束，否則進(jìn)行步驟(2);

(2)查詢?cè)摽蛻羰欠裼嗛喠舜酥黝}的消息，如果訂閱了，則刪除該客戶端訂閱節(jié)點(diǎn)，繼續(xù)進(jìn)行步驟(3);

(3)如果刪除該客戶端訂閱節(jié)點(diǎn)后，該訂閱主題對(duì)應(yīng)的客戶端訂閱節(jié)點(diǎn)為空，則刪除該訂閱主題。

3．3．3 消息匹配轉(zhuǎn)發(fā)模塊

系統(tǒng)通過(guò)該模塊接收消息發(fā)布者發(fā)布的消息，消息訂閱者的訂閱消息、取消訂閱消息，通過(guò)消息主題的交互匹配，將收到的消息正確地轉(zhuǎn)發(fā)給相應(yīng)的訂閱者。

4 系統(tǒng)實(shí)現(xiàn)

4．1 系統(tǒng)架構(gòu)設(shè)計(jì)

消息推送系統(tǒng)架構(gòu)設(shè)計(jì)如圖5所示，主要包括3個(gè)部分:消息發(fā)布者，消息服務(wù)器，消息訂閱者。

圖5 系統(tǒng)架構(gòu)

4．1．1 消息發(fā)布者

消息發(fā)布者相當(dāng)于消息的生產(chǎn)者，應(yīng)用程序每生產(chǎn)一條消息并不是直接交給消息接收者，而是交給消息服務(wù)器，由服務(wù)器決定將消息發(fā)送給哪些接收者。

4．1．2 消息訂閱者

消息訂閱者相當(dāng)于消息的消費(fèi)者，應(yīng)用程序從收到消息開(kāi)始，根據(jù)消息中的內(nèi)容做出響應(yīng)，并根據(jù)需要決定是否將結(jié)果反饋給消息服務(wù)器。消息的發(fā)布者與接收者的角色并不是固定的，基于異步通信機(jī)制的應(yīng)用程序通常既是消息的發(fā)布者，又是消息的訂閱者。

4．1．3 消息服務(wù)器

消息服務(wù)器是整個(gè)消息推送系統(tǒng)的核心，也是整個(gè)系統(tǒng)的創(chuàng)新設(shè)計(jì)所在，主要包括安全認(rèn)證機(jī)制、多樣化智能選擇機(jī)制和消息管理機(jī)制。安全認(rèn)證機(jī)制能夠避免非法連接，防止信息在傳輸過(guò)程中遭到篡改以及非法的攻擊，有效保證系統(tǒng)安全;多樣化智能選擇機(jī)制包括智能選擇發(fā)送方式和智能選擇通信模式，分別用來(lái)智能選擇用戶需要的發(fā)送查看方式和消息傳遞需要的通信模式;消息管理機(jī)制主要負(fù)責(zé)消息隊(duì)列管理、訂閱表管理、消息主題匹配、消息存儲(chǔ)轉(zhuǎn)發(fā)等。

4．2 系統(tǒng)工作流程

上述系統(tǒng)架構(gòu)的詳細(xì)工作流程如下:

(1)消息訂閱者連接到消息服務(wù)器，訂閱/取消自己的主題，按照訂閱主題監(jiān)聽(tīng)自己的消息隊(duì)列;

(2)消息發(fā)布者將要發(fā)送的數(shù)據(jù)打包成消息的形式發(fā)送給消息服務(wù)器，并給該消息設(shè)定一個(gè)主題;

(3)消息服務(wù)器通過(guò)安全認(rèn)證機(jī)制驗(yàn)證消息發(fā)布者的合法性，驗(yàn)證通過(guò)進(jìn)入下一步，否則消息推送服務(wù)停止;

(4)消息服務(wù)器通過(guò)多樣化智能選擇機(jī)制，選取合適的發(fā)送方式和通信模式;

(5)消息代理服務(wù)器通過(guò)消息管理機(jī)制進(jìn)行主題匹配，并將相應(yīng)主題的消息推送到訂閱了該主題的移動(dòng)終端的消息隊(duì)列;

(6)消息訂閱者監(jiān)聽(tīng)的消息隊(duì)列有新消息，接收推送過(guò)來(lái)的新消息，并查看新消息。

5 測(cè)試結(jié)果與分析

5．1 測(cè)試環(huán)境

基于農(nóng)業(yè)物聯(lián)網(wǎng)平臺(tái)的手機(jī)App軟件，是所在物聯(lián)網(wǎng)項(xiàng)目組開(kāi)發(fā)的一款集農(nóng)業(yè)物聯(lián)網(wǎng)平臺(tái)數(shù)據(jù)監(jiān)測(cè)、反向控制、消息推送接收等功能于一體的手機(jī)應(yīng)用，將它作為功能測(cè)試的終端，功能測(cè)試示意圖如圖6所示。采用的PC服務(wù)器配置情況為Windows 7操作系統(tǒng)，4核處理器，CPU為AMD Athlon(tm)II X4 645 Processor，內(nèi)存 2 GB，硬盤容量 450 GB。

圖6 功能測(cè)試示意圖

5．2 功能測(cè)試

5．2．1 安全認(rèn)證機(jī)制功能測(cè)試

選取未經(jīng)消息服務(wù)器許可的PC客戶端訪問(wèn)消息服務(wù)器，測(cè)試結(jié)果如圖7所示。選取PC的IP為192．168．64．102，雖然該 PC 客戶端知道消息服務(wù)器的 IP 為 192．168．64．131，端口號(hào)為 9095，但由于沒(méi)有通過(guò)消息服務(wù)器的安全認(rèn)證機(jī)制，得到了服務(wù)器返回的“Permission denied”錯(cuò)誤提示，因此該P(yáng)C無(wú)法使用消息推送服務(wù)，從而證明安全認(rèn)證機(jī)制能夠正常工作。

圖7 安全認(rèn)證失敗

5．2．2 多樣化智能選擇機(jī)制功能測(cè)試

物聯(lián)網(wǎng)平臺(tái)發(fā)布三類消息，分別進(jìn)行智能測(cè)試。

(1)群發(fā)消息:發(fā)送通知公告，界面如圖8所示，7月9日周三下午7:39手機(jī)終端收到了物聯(lián)網(wǎng)平臺(tái)推送過(guò)來(lái)的消息，消息主題“通知公告”，消息內(nèi)容“來(lái)自物聯(lián)網(wǎng)平臺(tái)的農(nóng)業(yè)資訊”。

圖8 通知公告消息

消息服務(wù)器上的部分?jǐn)?shù)據(jù)結(jié)果如圖9所示，訂閱主題“通知公告”，消息內(nèi)容:“來(lái)自物聯(lián)網(wǎng)平臺(tái)的農(nóng)業(yè)資訊”，消息級(jí)別 QoS為1，“false”表明是實(shí)時(shí)發(fā)出的消息，消息服務(wù)器 IP 為192．168．64．131。

圖9 消息服務(wù)器上的部分?jǐn)?shù)據(jù)

(2)特定用戶消息:分別給User1和User2 2個(gè)用戶發(fā)送不同的消息，界面如圖10、圖11所示，User1收到了“User 1的報(bào)警信息”;User 2收到了“User 2的報(bào)警信息”。

圖10 User1用戶消息

圖11 User2用戶消息

(3)其他發(fā)送方式:郵箱發(fā)送，郵箱界面如圖12所示，郵件的發(fā)件人為“消息服務(wù)管理系統(tǒng)”，收件人為本文作者的QQ郵箱，用戶名為“Jenny”，消息內(nèi)容為“您好!這是一封來(lái)自農(nóng)業(yè)物聯(lián)網(wǎng)平臺(tái)的郵件，請(qǐng)查收?！?/p>

圖12 郵件詳情信息

通過(guò)上述3類消息的測(cè)試結(jié)果，可以看出該消息推送系統(tǒng)能夠很好地按照消息的不同類型和用戶的個(gè)性化需求，智能選擇合適的消息通信模式和消息發(fā)送方式。

5．3 性能測(cè)試

為了確保消息服務(wù)器在負(fù)載逐漸增加情況下的性能，需要進(jìn)行性能測(cè)試。通過(guò)在PC端實(shí)現(xiàn)客戶端程序，模擬大量用戶對(duì)服務(wù)器發(fā)起連接請(qǐng)求，鑒于服務(wù)器配置條件和時(shí)延需求，連接數(shù)分別為100，200，400，600，800，1 000，并在不同連接數(shù)情況下發(fā)送不同數(shù)量的消息，消息數(shù)分別為 10，100，200，300，400，500，推送成功率及服務(wù)器發(fā)送時(shí)間、接收時(shí)間結(jié)果如表1所示。

表1 消息推送性能測(cè)試結(jié)果

從表1中可以看到，在發(fā)送消息數(shù)一定的情況下，隨著連接數(shù)的增多，消息發(fā)送時(shí)間和接收時(shí)間略有增加，變化幅度不太明顯，可見(jiàn)連接數(shù)對(duì)系統(tǒng)性能影響較小;在連接數(shù)一定的情況下，隨著發(fā)送消息數(shù)量的增多，消息發(fā)送時(shí)間和接收時(shí)間不斷增加，尤其是發(fā)送時(shí)間增加幅度較大，可見(jiàn)消息數(shù)對(duì)系統(tǒng)性能影響較大，面對(duì)大數(shù)據(jù)交互時(shí)易造成服務(wù)器性能瓶頸。從總體來(lái)看，在局域網(wǎng)環(huán)境下，所有推送的成功率都達(dá)到了100%，當(dāng)連接數(shù)為1 000，發(fā)送消息數(shù)為500時(shí)，發(fā)送時(shí)間和接收時(shí)間都在可接受范圍內(nèi)，系統(tǒng)性能良好。

6 結(jié)束語(yǔ)

本文論述了一種基于MQTT安全智能的消息推送系統(tǒng)，通過(guò)與客戶端聯(lián)合，對(duì)不同平臺(tái)上的用戶進(jìn)行高效、準(zhǔn)確的消息推送，目前已應(yīng)用于實(shí)際項(xiàng)目中，經(jīng)過(guò)測(cè)試，系統(tǒng)運(yùn)行良好，滿足大部分企業(yè)級(jí)應(yīng)用的消息推送需求。

隨著物聯(lián)網(wǎng)系統(tǒng)的數(shù)據(jù)規(guī)模爆發(fā)式增長(zhǎng)，大數(shù)據(jù)交互時(shí)消息服務(wù)器的性能瓶頸和單點(diǎn)失效的局限性越發(fā)明顯，嚴(yán)重影響了系統(tǒng)可用性［15］。因此，可以通過(guò)建立服務(wù)器集群，以加強(qiáng)服務(wù)器的穩(wěn)定性和可靠性，并且支持更多的用戶;也可以通過(guò)構(gòu)建高性能低功耗的云計(jì)算平臺(tái)，依托云計(jì)算和智能虛擬化等技術(shù)，實(shí)現(xiàn)靈活高效的計(jì)算資源調(diào)度，充分利用計(jì)算資源，從而改善服務(wù)器性能，增強(qiáng)系統(tǒng)可靠性，為最終用戶提供更加動(dòng)態(tài)，高效和可靠的網(wǎng)絡(luò)體驗(yàn)。對(duì)于企業(yè)中龐大的系統(tǒng)，當(dāng)系統(tǒng)出現(xiàn)故障時(shí)，系統(tǒng)的恢復(fù)能力十分重要?？紤]在消息推送系統(tǒng)中加入消息緩存機(jī)制，以確保系統(tǒng)出現(xiàn)突發(fā)故障或者非正常退出時(shí)，消息依然能夠安全可靠地傳送到目的地，并且不會(huì)重復(fù)傳送。

［1］ 顧正敏．一種面向Android平臺(tái)的輕量級(jí)推送技術(shù)研究與應(yīng)用［D］．北京:北京大學(xué)，2013．

［2］ 姜夢(mèng)蘭．基于消息中間件服務(wù)可靠性保障方案的研究與實(shí)現(xiàn)［D］．成都:電子科技大學(xué)，2010．

［3］ 馬 ?。谙⒅虚g件的Web Services的研究和實(shí)現(xiàn)［D］．大連:大連海事大學(xué)，2007．

［4］ 王廣澤．基于 Pub/Sub模式的智能消息中間件研究［J］．信息技術(shù)，2009，(5):171-173．

［5］ Lee S，Kim H，Hong Dong-kweon，et al．Correlation Analysis of MQTT Loss and Delay According to Qos Level［C］//Proceedings of International Conference on Information Networking．Washington D．C．，USA:IEEE Press，2013:714-717．

［6］ Behnel S，F(xiàn)iege L，Muehl G，et al．On Quality of Service and Publish Subscribe［C］//Proceedings of the 26th IEEE International Conference on Distributed Computing Systems．Washington D．C．，USA:IEEE Press，2006:20．

［7］ Hunkeler U，Truong H L，Clark A S．MQTT-S-A Publish/Subscribe Protocol for Wireless Sensor Networks［C］//Proceedings of Conference on Communication Systems Software and Middleware．Washington D．C．，USA:IEEE Press，2008:791-798．

［8］ Collina M，Corazza G E，Vanelli-Coralli A．Introducing the QEST Broker:Scaling the IoT by Bridging MQTT and REST［C］//Proceedings of the 3rd International Symposium on PersonalIndoorand Mobile Radio Communications．Washington D．C．，USA:IEEE Press，2012:36-41．

［9］ Hansen J，Gronli T M，Ghinea G．Cloud to Device Push Messaging on Android:A Case Study［C］//Proceedings of International Conference on Advanced Information Networking and Applications Workshops．Washington D．C．，USA:IEEE Press，2012:1298-1303．

［10］ 張長(zhǎng)學(xué)，張 偉，董智明．移動(dòng)推送技術(shù)面面觀［J］．移動(dòng)通信，2011，35(5):21-27．

［11］ 王克峰．基于Android的信息推送管理系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)［D］．大連:大連理工大學(xué)，2012．

［12］ 游思佳，趙久成，伏京生．黑莓推送機(jī)制和聯(lián)通黑莓業(yè)務(wù)發(fā)展分析［J］．信息通信技術(shù)，2011，(6):75-79．

［13］ 杜 蕊．智能消息中間件的研究與應(yīng)用［D］．哈爾濱:哈爾濱理工大學(xué)，2012．

［14］ 潘國(guó)偉，宋 瑋，王相南，等．發(fā)布/訂閱模式消息中間件在 SCADA系統(tǒng)中的應(yīng)用［J］．電網(wǎng)技術(shù)，2008，32(18):77-80．

［15］ Bernstein P，Philip A．Middleware:A Model for Distributed Services［J］．Communications of the ACM，1996，39(2):86-97．