基于 WebSocket 的 MQTT 移动推送方案
WebSphere MQ Telemetry Transport 簡介
WebSphere MQ Telemetry Transport (MQTT) 是一項(xiàng)異步消息傳輸協(xié)議，是 IBM 在分析了他們的客戶在其業(yè)務(wù)中使用 WebSphere MQ 消息傳遞的情況（包括通過它傳遞數(shù)據(jù)）之后專門為物聯(lián)網(wǎng)所定制的重要的輕量級(jí)消息傳輸協(xié)議。IBM 發(fā)現(xiàn)，數(shù)據(jù)經(jīng)常是在企業(yè)外部的遠(yuǎn)程位置生成的，而且數(shù)據(jù)在從遠(yuǎn)程位置到達(dá)企業(yè)之前通常要經(jīng)歷一個(gè)復(fù)雜的過程。這時(shí)往往將數(shù)據(jù)人工輸入計(jì)算機(jī)，然后只能通過 WebSphere MQ Enterprise 消息傳遞系統(tǒng)傳輸。而 MQTT 的開發(fā)將 WebSphere MQ 消息傳遞的應(yīng)用范圍延伸到這些遠(yuǎn)程位置。
WebSphere MQ 遙測傳輸 (MQTT) 是輕量級(jí)基于代理的發(fā)布 / 訂閱的消息傳輸協(xié)議，設(shè)計(jì)思想是開放、簡單、輕量、易于實(shí)現(xiàn)。這些特點(diǎn)使它適用于受限環(huán)境。例如，但不僅限于此：
- 網(wǎng)絡(luò)代價(jià)昂貴，帶寬低、不可靠。
- 在嵌入設(shè)備中運(yùn)行，處理器和內(nèi)存資源有限。
該協(xié)議的特點(diǎn)有：
- 使用發(fā)布 / 訂閱消息模式，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合。
- 對負(fù)載內(nèi)容屏蔽的消息傳輸。
- 使用 TCP/IP 提供網(wǎng)絡(luò)連接。
- 有三種消息發(fā)布服務(wù)質(zhì)量：
- "至多一次"，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會(huì)發(fā)生消息丟失或重復(fù)。這一級(jí)別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因?yàn)椴痪煤筮€會(huì)有第二次發(fā)送。
- "至少一次"，確保消息到達(dá)，但消息重復(fù)可能會(huì)發(fā)生。
- "只有一次"，確保消息到達(dá)一次。這一級(jí)別可用于如下情況，在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會(huì)導(dǎo)致不正確的結(jié)果。
- 小型傳輸，開銷很小（固定長度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。
- 使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制。
推送服務(wù)
推送服務(wù)表現(xiàn)為客戶端能自動(dòng)收到服務(wù)器發(fā)送過來的數(shù)據(jù)和信息。其目的都是為了給最終客戶方便有效地發(fā)送最新消息或者數(shù)據(jù)。而且推送的模式對以前的數(shù)據(jù)訪問方式提供很好的補(bǔ)充和發(fā)展。首先，給最終用戶帶來了很好的使用體驗(yàn)，可以實(shí)時(shí)的獲取自己感興趣的信息，與此同時(shí)，給服務(wù)器端的應(yīng)用商，也提供了更為便捷和主動(dòng)的數(shù)據(jù)，服務(wù)發(fā)布方式，使得應(yīng)用商能夠控制信息發(fā)布的頻率和時(shí)間，從而能更精準(zhǔn)的投送的最終用戶。
推送服務(wù)本質(zhì)上是服務(wù)器主動(dòng)將消息，數(shù)據(jù)發(fā)送到客戶端，而不是客戶端主動(dòng)去服務(wù)器請求數(shù)據(jù)。這種推送只需要客戶端與服務(wù)器連接后，在有數(shù)據(jù)的情況下，服務(wù)器端馬上將數(shù)據(jù)發(fā)送到客戶端。這里的客戶端可以是多種類型的，比如比較常見的瀏覽器，移動(dòng)應(yīng)用等等。
推送服務(wù)的實(shí)現(xiàn)方式大致可分為 Poll 和 Push 模式。
- Poll 模式
Poll 模式，本質(zhì)上是"偽推送"模式，或者叫短輪詢模式。是客戶端通過設(shè)定固定的時(shí)間間隔，然后在時(shí)間間隔到達(dá)后，客戶端主動(dòng)向服務(wù)器發(fā)送請求，去更新是否有新數(shù)據(jù)。這種模式的特點(diǎn)是，客戶端需要不停的輪詢訪問服務(wù)器獲取信息，其時(shí)間間隔設(shè)定無法真正體現(xiàn)實(shí)時(shí)推送，間隔太長容易導(dǎo)致信息不能實(shí)時(shí)的更新，間隔太短，客戶端需要發(fā)送很多不必要的連接請求，耗費(fèi)很多網(wǎng)絡(luò)流量和服務(wù)器開銷。比如在移動(dòng)終端上，此類模式會(huì)在設(shè)備電能消耗，網(wǎng)絡(luò)流量使用方面存在很多瓶頸。
- Push 模式
Push 模式，一般意義上使用長連接去建立一個(gè)客戶端到服務(wù)器的雙向數(shù)據(jù)通道，只要在連接建立后，一旦一方有數(shù)據(jù)更新，就可以馬上通過雙向的數(shù)據(jù)通道向?qū)Ψ桨l(fā)送數(shù)據(jù)，平時(shí)在沒有數(shù)據(jù)時(shí)，通過一些心跳等機(jī)制維持通道連接。Push 模式的特點(diǎn)，簡化的客戶端的開發(fā)，數(shù)據(jù)能近乎實(shí)時(shí)的發(fā)送到對方。但其在設(shè)備資源消耗和網(wǎng)絡(luò)流量控制方面，根據(jù)其使用的不同協(xié)議會(huì)有很大不同，特別是在移動(dòng)推送領(lǐng)域，長連接對移動(dòng)設(shè)備電量和網(wǎng)絡(luò)流量的消耗要求較高。同時(shí)，由于需要維護(hù)長連接，對服務(wù)器在高并發(fā)連接的處理能力和性能也有很高要求。
移動(dòng)推送服務(wù)
推送服務(wù)在很多領(lǐng)域都有發(fā)展，但特別在移動(dòng)領(lǐng)域，由于其飛速發(fā)展，給推送服務(wù)帶來了很多新的機(jī)遇和挑戰(zhàn)。首先，移動(dòng)市場規(guī)模越來越大，終端種類和數(shù)量越來越多，使得推送服務(wù)的的重要性越來越凸顯；其次，傳統(tǒng)的"偽推送"模式已越來越不能滿足其需要，需要發(fā)展新的推送的技術(shù)，這促使了很多新的協(xié)議和框架的出現(xiàn)；但是，由于移動(dòng)領(lǐng)域的終端設(shè)備和網(wǎng)絡(luò)情況的特點(diǎn)，對推送的協(xié)議和框架又提出了新的挑戰(zhàn)，比如：移動(dòng)終端的計(jì)算和存儲(chǔ)資源的限制，移動(dòng)終端的電量消耗的限制，移動(dòng)網(wǎng)絡(luò)流量和成本的控制等等。主流的移動(dòng)推送解決方案如下：
- SMS 短信
作為傳統(tǒng)的消息通訊，在新型移動(dòng)環(huán)境下，在網(wǎng)絡(luò)成本方面的考量使其地位有逐漸邊緣化的趨勢。
- HTTP 輪詢
使用定時(shí)的 HTTP 輪詢方式，及客戶端在一定的時(shí)間間隔里去重復(fù)向服務(wù)器請求數(shù)據(jù)更新，屬于"偽推送"，由于其協(xié)議復(fù)雜冗余，輪詢間隔的不準(zhǔn)確，耗費(fèi)了不必要的流量，增加了終端用戶網(wǎng)絡(luò)成本等因素，現(xiàn)有的這種方式已經(jīng)不適合做移動(dòng)推送服務(wù)。
- XMPP
XMPP 是基于 XML 的通訊協(xié)議，此協(xié)議已基本上完成了標(biāo)準(zhǔn)化，成熟，強(qiáng)大，可擴(kuò)展性強(qiáng)。但正是由于其協(xié)議復(fù)雜，冗余的設(shè)計(jì)，成為其在移動(dòng)設(shè)備上短板，比如協(xié)議的復(fù)雜帶來其協(xié)議棧的耗電增加，冗余的設(shè)計(jì)使得網(wǎng)絡(luò)流量偏大，用戶成本增加。
- 私有廠商協(xié)議和平臺(tái)
私有廠商推出的推送服務(wù)，由于其協(xié)議私有，其傳輸效率和質(zhì)量上無法量化和考證，而且還往往無法實(shí)現(xiàn)跨平臺(tái)推送。同時(shí)，有些廠商提供的消息服務(wù)器不具備公開性，導(dǎo)致在用戶數(shù)據(jù)安全性特別是服務(wù)器掌控方面存在擔(dān)心。
IBM 基于 WebSocket 的 MQTT 跨平臺(tái)推送服務(wù)方案
IBM 通過對現(xiàn)有移動(dòng)推送平臺(tái)比較之后，對其中存在的問題和缺陷做了很好的分析。這些問題集中體現(xiàn)在如下方面：
- 在網(wǎng)絡(luò)方面
如何適應(yīng)現(xiàn)有網(wǎng)絡(luò)的不可靠，很好的保障數(shù)據(jù)發(fā)送可靠性
如何降低網(wǎng)絡(luò)流量，從而節(jié)省網(wǎng)絡(luò)成本
- 在移動(dòng)設(shè)備方面
如何降低對設(shè)備能力的要求，特別是適應(yīng)計(jì)算和存儲(chǔ)弱的設(shè)備
如何降低對設(shè)備電量的消耗，滿足設(shè)備電源能力的不足
如何降低平臺(tái)依賴性，真正實(shí)現(xiàn)跨移動(dòng)設(shè)備平臺(tái)
- 在數(shù)據(jù)方面
缺少對數(shù)據(jù)安全性的保障，特別是對服務(wù)器的掌控
缺少對大量數(shù)據(jù)的監(jiān)測，優(yōu)化
IBM 針對上面問題，結(jié)合 MQTT 和 WebSocket，提出了更智慧的移動(dòng)推送服務(wù)解決方案。
圖 1. IBM 移動(dòng)推送服務(wù)解決方案
方案中，服務(wù)器端使用 WebSphere MQ 作為 MQTT 的 Server，在移動(dòng)設(shè)備中嵌入 MQTT 的客戶端，并通過客戶端建立到服務(wù)器的雙向數(shù)據(jù)通道，然后在后臺(tái)來自不同應(yīng)用的數(shù)據(jù)通過 WebSphere MQ 推送到移動(dòng)終端。那么，這樣的解決方案，會(huì)有什么特點(diǎn)能夠很好的解決和優(yōu)化上面關(guān)于業(yè)界移動(dòng)推送服務(wù)解決方案中存在的普遍問題，或者說此方案有什么自身的優(yōu)勢。
- 移動(dòng)設(shè)備
能在 8bit 位處理器上很好的運(yùn)行 C /JavaScript/Java 的 client 庫分別只有 30/75/100KB
在移動(dòng)設(shè)備上耗電率低，大約只需要 HTTP 的一半
通過使用基于 WebSocket 的 MQTT 客戶端 JavaScript API，符合 Hybrid 開發(fā)潮流，只要設(shè)備的瀏覽器支持 WebSocket，就能很輕松實(shí)現(xiàn)多移動(dòng)平臺(tái)的跨越
- 很好的適應(yīng)各種復(fù)雜網(wǎng)絡(luò)，特別是受限網(wǎng)絡(luò)
預(yù)期并適應(yīng)頻繁的網(wǎng)絡(luò)中斷，能應(yīng)對低速、低質(zhì)量的網(wǎng)絡(luò)
壓縮優(yōu)化過后的協(xié)議，可以有效降低網(wǎng)絡(luò)流量，從而節(jié)約網(wǎng)絡(luò)成本
完成同樣的數(shù)據(jù)通信，MQTT 只需要 HTTP 約 1/4 得數(shù)據(jù)流量
- 發(fā)布 - 訂閱的消息通信協(xié)議，允許一條消息只發(fā)布一次，便可被多個(gè)消費(fèi)端（應(yīng)用程序 / 設(shè)備）所接收
實(shí)現(xiàn)系統(tǒng)間松耦合，簡化開發(fā)，方便擴(kuò)展，整合。
- 提供靈活便捷的系統(tǒng)整合能力
使用 MQ，MB 提供可靠系統(tǒng)內(nèi)系統(tǒng)整合和通信
Cast Iron 強(qiáng)大的系統(tǒng)間整合帶來巨大的靈活性
- 提供豐富的安全性
使用 SSL 提供的認(rèn)證和加密來保證傳輸安全性
通過 JAAS 接口提供的身份認(rèn)證
OAM 用于資源層面的授權(quán)
- 強(qiáng)大的性能提高系統(tǒng)的高可靠性
高連接數(shù)下系統(tǒng)低計(jì)算資源使用
高連接數(shù)下系統(tǒng)高信息處理速度
- 提供多種消息服務(wù)質(zhì)量，滿足不同場景需求
0 ：消息最多被傳遞一次，比如一般類廣告，通知
1 ：消息會(huì)被傳遞但可能會(huì)重復(fù)傳遞，比如賬戶余額通知
2 ：消息保證傳遞且僅有一次傳遞，比如交易支付批復(fù)通知
應(yīng)用場景
本文是通過介紹使用 WebSphere MQ Telemetry 以及其 SDK 組件中自帶的 MQTT 基本客戶端（WebSocket API）實(shí)現(xiàn)一個(gè) iOS 設(shè)備的推送應(yīng)用場景，來使讀者對使用基于 MQTT 協(xié)議的 WebSphere MQ Telemetry 來構(gòu)建物移動(dòng)推送服務(wù)解決方案有進(jìn)一步的理解，并能夠自己動(dòng)手開發(fā)相應(yīng)的解決方案。
該方案通過 WebSphere MQ Telemetry 自帶的 MQTT 基本客戶機(jī) WebSocket JavaScript API 來實(shí)現(xiàn)客戶端到服務(wù)器的連通。實(shí)現(xiàn)的場景如下：
- Mobile 用戶相互通訊（文本，語音，圖片）
- 后臺(tái)應(yīng)用向 Mobile 用戶推送相關(guān)信息（廣告，通知等等）
圖 2. 移動(dòng)推送服務(wù)場景
開發(fā)步驟及流程
整個(gè)開發(fā)會(huì)涉及到移動(dòng)端開發(fā)和服務(wù)器端配置，以下將會(huì)分別介紹。
Note：開發(fā)工具使用 Worklight，Xcode，WebSphere MQ Explorer。
客戶端開發(fā)
Worklight 平臺(tái)為開發(fā)基于 Web 技術(shù)的手機(jī)客戶端 App 提供了一套完整的解決方案，從開發(fā)、部署、測試到發(fā)布均可在這個(gè)平臺(tái)上完成。App 用 HTML，CSS 和 Javascript 寫成，之后被擴(kuò)展成桌面的（Windows，Mac，Linux），互聯(lián)網(wǎng)的（Facebook 等），本地移動(dòng)設(shè)備上的（iOS，Android，RIM 和 Windows Phone）應(yīng)用程序。開發(fā)者還能把一些流行的 Javascript 構(gòu)架如 jQuery Mobile，Sencha 和 Dojo 整合到 Worklight 中。而且 App 的本地運(yùn)行時(shí)也能用本地代碼來編寫和修改。
MQTT WebSocket JavaScript API 的功能描述如下：
- Connect 連接
MQTT 客戶端負(fù)責(zé)向 MQTT 服務(wù)器發(fā)起連接操作，并開始計(jì)時(shí)，在超時(shí)期里接收到正確連接響應(yīng)，則連接成功，負(fù)責(zé)連接超時(shí)。任何數(shù)據(jù)的發(fā)送或者收到，都將啟動(dòng)新的超時(shí)計(jì)時(shí)，在整個(gè)超時(shí)完成后沒有數(shù)據(jù)的發(fā)送或者接收時(shí)，發(fā)送心跳以維持連接狀態(tài)。
- DisConnect 斷開連接
MQTT 客戶端或者服務(wù)器發(fā)起連接斷開命令。在發(fā)出連接斷開命令后，開始超時(shí)計(jì)時(shí)，在超時(shí)內(nèi)成功收到斷開響應(yīng)，雙方設(shè)置其相應(yīng)連接狀態(tài)為斷開；超時(shí)后尚未成功接收響應(yīng)，則開始重發(fā)連接命令，直到重發(fā)次數(shù)到達(dá)系統(tǒng)設(shè)置上限。否則，設(shè)置對應(yīng)原因。
- Subscribe 訂購
在雙方連接建立后，MQTT 客戶端發(fā)送訂購消息，來訂購主題，并設(shè)置相應(yīng)質(zhì)量服務(wù)級(jí)別，在接收到訂購確認(rèn)后，自動(dòng)接收在此主題上的任何消息。
- UnSubscribe 取消訂購
在雙方連接建立后，MQTT 客戶端發(fā)送取消訂購消息，來取消訂購主題，在接收到取消訂購確認(rèn)后，在原來主題上的任何消息將不再推送到此客戶端。
- Publish 發(fā)布
在雙方連接建立后，MQTT 客戶端將業(yè)務(wù)數(shù)據(jù)放入發(fā)布消息的消息體中，通過發(fā)布消息，發(fā)布在某主題上，此消息按照不同的消息服務(wù)質(zhì)量級(jí)別，發(fā)布到不同的訂購者客戶端。
- Will 主題和消息
在 MQTT 客戶端連接時(shí)設(shè)置，設(shè)定在自己連接中斷后，自動(dòng)往 Will 主題上發(fā)送的通知消息。
圖 3. WorkLight 工程
圖 4. 新建 Worklight Environment
然后在工程中就生成的為 iPad 開發(fā)的模板。
圖 5. iPad 開發(fā)模板
圖 6. 拷貝 MQTT Client 的 JS 庫文件
圖 7. 替換原有展現(xiàn)頁面
然后在 application：WebSocketMQTTApp 上右鍵，選擇 Run As -> Build All and Deploy
圖 8. 打開 Xcode Project
在 Xcode 里，在 Build 成功后，選擇配置過的 iOS 設(shè)備安裝。
服務(wù)器開發(fā)和配置
安裝 WebSphere MQ 7.5.0.1 版本，在安裝過程中選擇 Telemetry 組件，安裝完后打開 WebSphere MQ 管理界面 WebSphere MQ Explorer。
圖 9. WebSphere MQ Explorer
展開新創(chuàng)建的 Queue Manager，點(diǎn)擊 Telemetry 并在右邊的窗口中，選擇 Define sample configuration...
圖 10. 定義 Telemetry 服務(wù)
圖 11. 配置 Telemetry
圖 12. 支持 MQTT 連接的通道
圖 13. MQTT Client Utility 工具
服務(wù)器端的配置就完成了。
部署和驗(yàn)證
本文將通過模擬移動(dòng)推送服務(wù)中的 2 個(gè)基本場景來驗(yàn)證。
- 兩個(gè) iPad 設(shè)備通訊模擬 Mobile 用戶相互通訊
- MQTT Client Utility 向 iPad 發(fā)送消息模擬后臺(tái)應(yīng)用向 Mobile 用戶推送相關(guān)信息
- Server：WebSphere MQ 的安裝機(jī)器的 IP
- Port：在 WebSphere MQ 里配置的 MQTT 的通道的端口號(hào)，默認(rèn)是 1883
- Client ID：頁面會(huì)生成一個(gè)默認(rèn)的，也可以自定義
- Topic Name：用于發(fā)布或者訂購的主題，模擬通訊時(shí)，每個(gè)客戶端有固定的主題，比如：iPad A 主題為 iPadA，iPad B 的主題為 iPadB。在通訊時(shí)每個(gè)客戶端訂購自己的主題接收別的客戶端發(fā)送來的消息，同時(shí)給別的客戶端的主題發(fā)送消息。
- QoS：質(zhì)量服務(wù)等級(jí)
啟動(dòng) App 后，在填寫 Server，port 和 Client Id 后，點(diǎn)擊連接（Connect），然后分別在訂閱的 Topic Name 中填寫自己要監(jiān)聽的主題：iPadA 或者 iPadB。最后，在發(fā)布 Publish 的 Topic 中填入要對話的對方的主題：iPadB 或者 iPadA，輸入想發(fā)送的信息后，點(diǎn)擊發(fā)送就可以開始兩個(gè) iPad 之間的通訊了。這里只是簡單展現(xiàn)，除了文本通訊還可以實(shí)現(xiàn)語音，文件，照片通訊分享等。
圖 14. iPadA
圖 15. iPadB
通過以上兩個(gè)截圖，驗(yàn)證了兩個(gè) iPad 通過基于 WebSocket 的 MQTT 協(xié)議，實(shí)現(xiàn)了通訊，相互給對方發(fā)送了消息。
Note: 在 App 部署到 iPad 上后，如果 WorkLight 的服務(wù)器更換了，修改應(yīng)用的 WorkLight Server 地址如下
圖 16. 應(yīng)用的 WorkLight 服務(wù)器地址
- Topic Name：iPadPush
- Message：This is message from backend system application.
后端采用 JMS 方式發(fā)送數(shù)據(jù)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 | import javax.jms.Connection; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageProducer; import javax.jms.Session; import com.ibm.mq.jms.MQConnectionFactory; public class JMSSender { ????private Connection conn; ????private Session sess; ????private MessageProducer sender; ????public static void main(String[] args) { ????????JMSSender jmsSender = new JMSSender(); ????????jmsSender.createSender(); ????????jmsSender.closeSender(); ????} ????private void closeSender() { ????????try { sender.close(); sess.close(); conn.close(); System.out.println("JMS Sender closed"); ????????} catch (JMSException e) { e.printStackTrace(); if (e.getLinkedException() != null) { ????e.getLinkedException().printStackTrace(); } ????????} ????} ????private void createSender() { ????????MQConnectionFactory connFact = new MQConnectionFactory(); ????????try { // We are connecting to queue manager using client mode connFact.setQueueManager("XRNEW"); connFact.setHostName("localhost"); connFact.setPort(1414); System.out.println("Model"+connFact.getTransportType()); //connFact.setTransportType(1); System.out.println("Model"+connFact.getTransportType()); conn = connFact.createConnection(); sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); sender = sess.createProducer(sess ????????.createQueue("queue://iPadA/iPadPush")); Message msg = sess.createTextMessage( ???????"This is message from backend system application."); msg.setJMSExpiration(10000); sender.setTimeToLive(10000); sender.send(msg); System.out ????????.println("JMS Sender started and published message to topic iPadPush"); ????????} catch (JMSException e) { e.printStackTrace(); if (e.getLinkedException() != null) { ????e.getLinkedException().printStackTrace(); } ????????} ????} } |
圖 17. 終端接收后端推送的消息
結(jié)束語
本文通過介紹使用 WebSphere MQ Telemetry 以及其 SDK 組件中自帶的 MQTT 基本客戶機(jī)的 WebSocket JavaScript API 開發(fā)一個(gè) App，并通過實(shí)現(xiàn)通用的移動(dòng)推送服務(wù)應(yīng)用場景來使讀者對使用基于 MQTT 協(xié)議的 WebSocket JavaScript API 來構(gòu)建移動(dòng)推送服務(wù)解決方案有進(jìn)一步的理解，并能夠自己動(dòng)手開發(fā)相應(yīng)的推送解決方案。
總結(jié)
以上是生活随笔為你收集整理的基于 WebSocket 的 MQTT 移动推送方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SSM框架之MyBatis3专题5：My
- 下一篇： 大型分布式C++框架《四：netio之请