基于Go語(yǔ)言的消息推送平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)

王伯槐*，張燁

?

基于Go語(yǔ)言的消息推送平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)

王伯槐1*，張燁2

(1.榆林學(xué)院信息工程學(xué)院,陜西省榆林市719000；2.榆林學(xué)院學(xué)工部,陜西省榆林市719000）

為解決移動(dòng)端應(yīng)用獲取數(shù)據(jù)的實(shí)時(shí)性問(wèn)題和反復(fù)輪詢所產(chǎn)生的流量消耗問(wèn)題，設(shè)計(jì)實(shí)現(xiàn)了android消息推送平臺(tái)。該平臺(tái)由服務(wù)器端與移動(dòng)端兩部份組成，服務(wù)端由Go語(yǔ)言實(shí)現(xiàn)，管理后臺(tái)采用beego框架與Angularjs實(shí)現(xiàn)前后端分離，底層的連接，數(shù)據(jù)讀寫由go協(xié)程和TCP協(xié)議實(shí)現(xiàn)。移動(dòng)端基于Android平臺(tái)，采用自定義的協(xié)議來(lái)建立與服務(wù)器的連接、通信。移動(dòng)端完成包括消息的收發(fā)、解析以及斷線重連等功能。經(jīng)過(guò)測(cè)試，該平臺(tái)滿足移動(dòng)端應(yīng)用中實(shí)時(shí)性和低能耗的要求，解決了移動(dòng)端獲取數(shù)據(jù)的數(shù)據(jù)重復(fù)、流量高消耗問(wèn)題，實(shí)際應(yīng)用中效果良好。

實(shí)時(shí); 消息推送；android；Go語(yǔ)言

引言

在移動(dòng)網(wǎng)絡(luò)時(shí)代，移動(dòng)端獲取數(shù)據(jù)不但要考慮加載數(shù)據(jù)時(shí)產(chǎn)生的數(shù)據(jù)流量問(wèn)題，還要考慮信息的即時(shí)性問(wèn)題。傳統(tǒng)數(shù)據(jù)獲取方式是pull方式，pull方式來(lái)獲取數(shù)據(jù)，用戶需要時(shí)主動(dòng)到服務(wù)器獲取數(shù)據(jù)，不管服務(wù)器中的數(shù)據(jù)有沒(méi)有變化都會(huì)返回當(dāng)前數(shù)據(jù)給移動(dòng)端，由于頻繁訪問(wèn)服務(wù)器，既浪費(fèi)時(shí)間和流量，又占用服務(wù)器資源，使其它有效用戶請(qǐng)求得不到高效處理[1]；另一方面，服務(wù)器有了新數(shù)據(jù)時(shí)，又難以實(shí)時(shí)傳送到移動(dòng)端[2]。因此， pull方式難以滿足實(shí)時(shí)性要求高、低能耗、低帶寬的移動(dòng)操作平臺(tái)要求[3-5]。為解決該問(wèn)題，采用push方式獲取數(shù)據(jù)，由服務(wù)端主動(dòng)向移動(dòng)端推送消息。本文針對(duì)這一需求，實(shí)現(xiàn)了一個(gè)消息推送平臺(tái)，平臺(tái)由服務(wù)器端與移動(dòng)端兩部份組成，服務(wù)端由Go語(yǔ)言實(shí)現(xiàn)，采用beego框架與Angularjs實(shí)現(xiàn)前端和后端分離、底層的連接，數(shù)據(jù)讀寫由go協(xié)程與tcp協(xié)議實(shí)現(xiàn)。移動(dòng)端基于Android平臺(tái)，采用自定義的協(xié)議來(lái)建立與服務(wù)器的連接、通信移動(dòng)端主要包括消息的收發(fā)、解析以及斷線重連等功能。實(shí)現(xiàn)為Android應(yīng)用提供消息推送的功能。

1 系統(tǒng)需求分析

1.1 整體分析

整個(gè)系統(tǒng)工作主要分為三個(gè)部分：App（移動(dòng)應(yīng)用）、推送消息服務(wù)器（消息推送平臺(tái)）和APP Server（移動(dòng)應(yīng)用服務(wù)器），系統(tǒng)示意圖如圖1所示。

當(dāng)APP Server要推送消息到APP時(shí)，首先將這條消息發(fā)送到推送消息服務(wù)器，推送消息服務(wù)器首先判斷此App Service對(duì)應(yīng)的App是否存在注冊(cè)的移動(dòng)端，并返回結(jié)果給APP Service。如果存在，對(duì)這條消息進(jìn)行過(guò)濾、加工，然后發(fā)給移動(dòng)端APP。

圖1 系統(tǒng)圖

1.2 移動(dòng)端SDK需求分析

移動(dòng)端SDK為移動(dòng)應(yīng)用提供的接口包括應(yīng)用初始化設(shè)置、收發(fā)消息、啟動(dòng)和停止消息推送服務(wù)，其中初始化設(shè)置包括獲取移動(dòng)設(shè)備的唯一標(biāo)識(shí)，設(shè)置設(shè)備標(biāo)簽等。用例描述如表1所示。

表1 移動(dòng)端SDK用例描述

用例名稱：移動(dòng)端SDK用例 參與者：移動(dòng)應(yīng)用 前置條件：集成本SDK，配置正確的AppKey 用例功能：應(yīng)用初始化設(shè)置、收發(fā)消息、啟動(dòng)和停止消息推送服務(wù) 事件流：隨APP啟動(dòng)，并在后臺(tái)一直運(yùn)行 異常事件流：連接異常 后置條件：檢查網(wǎng)絡(luò)，等待斷線重連。

1.3 推送消息服務(wù)器需求分析

推送消息服務(wù)器提供的功能有用戶管理、發(fā)送消息、接收消息、推送記錄查詢與SDK使用文檔。其中用戶管理包括用戶信息與應(yīng)用管理，用戶信息主要是記錄開(kāi)發(fā)者的一些信息，應(yīng)用管理主要是管理開(kāi)發(fā)者名下的移動(dòng)應(yīng)用信息。發(fā)送消息指的是向移動(dòng)端推送信息。接收消息指接收APP Server發(fā)送來(lái)的消息。推送記錄查詢查看每個(gè)應(yīng)用所推送的歷史消息。用例描述如表2所示。

表2 推送消息服務(wù)器用例圖描述

用例名稱：推送消息服務(wù)器用例 參與者：開(kāi)發(fā)者 前置條件：擁有推送消息服務(wù)器開(kāi)發(fā)者賬號(hào)，并登錄 用例功能：用戶管理、發(fā)送消息、接收消息、推送記錄查詢、SDK文檔 事件流：開(kāi)發(fā)者創(chuàng)建應(yīng)用，推送消息 異常事件流：消息發(fā)送失敗 后置條件：檢查網(wǎng)絡(luò)，重新發(fā)送。

1.4 APP Server SDK需求分析

APP Server SDK向App Server提供兩種推送方式，一種是面向整個(gè)App應(yīng)用的終端推送廣播消息，另一種是對(duì)指定標(biāo)簽的移動(dòng)端推送消息。用例描述如表3所示。

表3 APP Server SDK用例描述

2 系統(tǒng)設(shè)計(jì)

2.1 推送消息服務(wù)器設(shè)計(jì)

推送消息服務(wù)器軟件架構(gòu)設(shè)計(jì)如圖2所示。

圖2 推送消息服務(wù)器軟件架構(gòu)設(shè)計(jì)圖

Link（連接組件）負(fù)責(zé)與移動(dòng)應(yīng)用終端與應(yīng)用服務(wù)器的連接并校驗(yàn)連接的合法性。ORM（數(shù)據(jù)庫(kù)映射組件）用來(lái)處理數(shù)據(jù)庫(kù)操作。

消息過(guò)濾是指在推送消息服務(wù)器接到需要推送的消息后，對(duì)消息進(jìn)行一系列的過(guò)濾，分析消息發(fā)送方式以及要推送的對(duì)象，并把消息傳遞到相應(yīng)的Redis訂閱通道中。

發(fā)送消息是指監(jiān)聽(tīng)所有的Redis訂閱通道，如果存在要推送的消息，從訂閱通道中取出消息，并發(fā)送到相應(yīng)的移動(dòng)端。

ORM（數(shù)據(jù)庫(kù)映射組件）是用來(lái)處理數(shù)據(jù)庫(kù)操作。

控制臺(tái)包括前端頁(yè)面組件，webService接口與邏輯處理三個(gè)方面。

2.2 消息傳遞數(shù)據(jù)格式定義

本系統(tǒng)采用的通信協(xié)議是自定義的，因此系統(tǒng)需要規(guī)范消息通信格式，系統(tǒng)分別對(duì)應(yīng)用服務(wù)器與移動(dòng)終端消息推送系統(tǒng)、移動(dòng)終端消息推送系統(tǒng)與移動(dòng)終端的消息格式進(jìn)行了規(guī)范定義。移動(dòng)應(yīng)用端數(shù)據(jù)格式與協(xié)議表如表4所示。

消息包格式定義：{"id":long,"typeid":byte,"data":string,"status":Boolean}

表4 移動(dòng)應(yīng)用端數(shù)據(jù)格式與協(xié)議表

類別作用 id消息的唯一標(biāo)識(shí)符，取時(shí)間的納秒值 typeiddatastatus1傳遞APPkey2傳遞設(shè)備唯一標(biāo)識(shí)3心跳包4確認(rèn)包5斷開(kāi)連接6傳遞標(biāo)簽信息7推送消息消息內(nèi)容消息狀態(tài)

2.3 系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)

本推送平臺(tái)的數(shù)據(jù)庫(kù)主要用來(lái)存儲(chǔ)平臺(tái)的用戶信息、用戶的應(yīng)用信息及應(yīng)用的推送消息記錄。主要包含了四張表，pq_user表、pq_user_profile表、pq_user_project表和pq_user_project_message表。

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

push方式需要客戶端和服務(wù)器之間維持一個(gè)TCP/IP長(zhǎng)連接，有新消息更新時(shí)，服務(wù)器向客戶端推送[4]。

3.1 長(zhǎng)連接與斷線重連的實(shí)現(xiàn)

為了讓移動(dòng)端及時(shí)收到推送消息，移動(dòng)端與推送平臺(tái)的連接應(yīng)該是一直保持的，這就是長(zhǎng)連接。服務(wù)端和移動(dòng)端依靠長(zhǎng)連接作為數(shù)據(jù)傳輸通道來(lái)收發(fā)數(shù)據(jù)。

1)心跳機(jī)制，維護(hù)任何一個(gè)長(zhǎng)連接都需要心跳機(jī)制，客戶端隔一定時(shí)間就需要發(fā)送一個(gè)心跳給服務(wù)器，服務(wù)器給客戶端一個(gè)心跳應(yīng)答，這樣就形成客戶端服務(wù)器的一次完整的握手，這個(gè)握手是讓雙方都知道他們之間的連接是沒(méi)有斷開(kāi)，客戶端是在線的[5-7]。智能手機(jī)上的長(zhǎng)連接心跳和在Internet上的長(zhǎng)連接心跳有很大不同，因?yàn)橹悄苁謾C(jī)大部分時(shí)間處于網(wǎng)絡(luò)受限環(huán)境中。因?yàn)镮PV4的IP數(shù)量是固定且有限，因此，終端設(shè)備的IP都是移動(dòng)運(yùn)營(yíng)商所分配的內(nèi)網(wǎng)的地址，移動(dòng)設(shè)備需要通過(guò)NAT(Network Address Translation網(wǎng)絡(luò)地址轉(zhuǎn)換）才能連接到外網(wǎng)，NAT需要運(yùn)營(yíng)商的網(wǎng)關(guān)維護(hù)一個(gè)外網(wǎng)IP地址到內(nèi)網(wǎng)地址的映射關(guān)系。由于絕大多數(shù)移動(dòng)無(wú)線網(wǎng)絡(luò)運(yùn)營(yíng)商為了減少網(wǎng)關(guān)NAT映射表的負(fù)荷，如果一個(gè)鏈路有一段時(shí)間沒(méi)有通信時(shí)就會(huì)刪除其對(duì)應(yīng)表，造成鏈路中斷，正是這種刻意縮短空閑連接的釋放超時(shí)，原本是想節(jié)省信道資源的作用，沒(méi)想到讓互聯(lián)網(wǎng)的應(yīng)用不得以遠(yuǎn)高于正常頻率發(fā)送心跳來(lái)維護(hù)推送的長(zhǎng)連接。因?yàn)槭謾C(jī)上APP必須要通過(guò)運(yùn)營(yíng)商的網(wǎng)關(guān)才能和Internet進(jìn)行通信，為了不讓映射表失效，開(kāi)發(fā)者需要定時(shí)地發(fā)心跳，以刷新表項(xiàng)，避免被淘汰。

2)斷線重連機(jī)制，由于移動(dòng)端的各種原因，導(dǎo)致移動(dòng)端網(wǎng)絡(luò)的不穩(wěn)定性。因此制定有效的斷線重連策略是必不可少的，斷線重連策略如表5所示。

表5 斷線重連策略

持續(xù)連接失敗次數(shù)下次重連時(shí)間間隔(s) <1030 10-2060 20-30300 >30600

3.2 消息處理與推送

消息處理是本平臺(tái)的核心，該模塊基于Redis的功能來(lái)實(shí)現(xiàn)，消息推送的實(shí)現(xiàn)采用Redis的發(fā)布(PUBLISH)/訂閱(SUBSCRIBE)功能來(lái)實(shí)現(xiàn)。

推送平臺(tái)的服務(wù)端接口接收到應(yīng)用服務(wù)器的消息后，先對(duì)消息進(jìn)行一系列的分析與處理，最終確定消息的推送模式。本平臺(tái)消息推送模式共有四種，下面以服務(wù)端接口收到一條消息為例，描述其消息推送模式。

1)如果此消息是廣播消息，要發(fā)給所有移動(dòng)端，移動(dòng)端在線就直接將消息推送給該移動(dòng)端。

2)如果此消息是廣播消息，要發(fā)給所有移動(dòng)端，移動(dòng)端不在線將消息存到Redis隊(duì)列中，等待移動(dòng)端上線后將消息推送到該移動(dòng)端。

3)如果此消息是標(biāo)簽消息，要發(fā)送給此標(biāo)簽對(duì)應(yīng)的移動(dòng)端，移動(dòng)端在線就直接將消息推送給該移動(dòng)端。

4)如果此消息是標(biāo)簽消息，要發(fā)送給此標(biāo)簽對(duì)應(yīng)的移動(dòng)端，移動(dòng)端離線將消息存到Redis隊(duì)列中，等待移動(dòng)端上線后將消息推送到該移動(dòng)端。

消息處理與推送流程圖如圖3所示。

推送平臺(tái)的服務(wù)端接口接收到應(yīng)用服務(wù)器的消息后，先對(duì)消息進(jìn)行一系列的分析與處理，最終確定消息的推送模式。

首先移動(dòng)端上線后訂閱一個(gè)以自己唯一標(biāo)識(shí)符為名的Redis訂閱通道，當(dāng)服務(wù)端接口接收到推送消息后，如果是廣播模式消息則查詢此應(yīng)用下的所有注冊(cè)過(guò)的移動(dòng)端訂閱通道名稱，如果是標(biāo)簽?zāi)Ｊ较t查詢此應(yīng)用下的這個(gè)標(biāo)簽對(duì)應(yīng)的移動(dòng)端訂閱通道名稱。得到移動(dòng)端訂閱名稱后在去移動(dòng)端的連接管理查詢移動(dòng)端是否在線，如果在線則直接發(fā)布消息到移動(dòng)端訂閱的通道，如果離線則將此消息存到移動(dòng)端對(duì)應(yīng)的離線消息隊(duì)列中。移動(dòng)端的接口訂閱后，當(dāng)有消息發(fā)布到訂閱通道后，移動(dòng)端接口就可以立即接收到此消息，然后將消息推送到移動(dòng)端。

圖3 消息處理與推送流程圖

系統(tǒng)測(cè)試結(jié)果如圖4、圖5所示。

圖4 消息推送平臺(tái)消息記錄

圖5 移動(dòng)端消息接收?qǐng)D

4 結(jié)語(yǔ)

目前消息推送平臺(tái)正常運(yùn)行，消息推送平臺(tái)為Android開(kāi)發(fā)者提供廣播消息推送、單獨(dú)推送、離線消息緩存等功能，為Android開(kāi)發(fā)者提供Android SDK、服務(wù)端的jar包和服務(wù)端的js文件，二次開(kāi)發(fā)時(shí)只要引入對(duì)應(yīng)的jar包并且簡(jiǎn)單配置就可以為自己的app添加消息推送功能。滿足實(shí)時(shí)性高要求、低能耗、低帶寬的移動(dòng)操作平臺(tái)要求，解決了移動(dòng)端獲取數(shù)據(jù)的數(shù)據(jù)重復(fù)、流量高消耗問(wèn)題和信息的即時(shí)性問(wèn)題，實(shí)際應(yīng)用中效果良好。

[1] 承驍, 白光偉, 華志翔, 等. 云代理的移動(dòng)消息推送服務(wù)[J]. 小型微型計(jì)算機(jī)系統(tǒng), 2016, 37(8): 1661-1666.

[2] 方仁富. 基于微信的智慧校園個(gè)性化消息推送研究與實(shí)踐[J]. 教育現(xiàn)代化, 2017: 88-89．

[3] 劉永玲, 劉兀, 郭克華著.一種面向移動(dòng)終端的自適應(yīng)消息推送策略[J]. 計(jì)算機(jī)工程與科學(xué), 2013, 35(12): 114-117.

[4] 汪海占, 邸萌, 黃祥林著. 基于XMPP協(xié)議的Android消息推送設(shè)計(jì)與實(shí)現(xiàn)[J]. 科技廣場(chǎng), 2015, 2015(02): 40-45.

[5] 周虹, 張蓓, 姜愛(ài)蓉, 等. 館藏書目信息自助短信推送服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 現(xiàn)代圖書情報(bào)技術(shù), 2011(7-8): 127-131．

[6] 律智堅(jiān), 吳廣財(cái)著.消息推送在移動(dòng)高級(jí)應(yīng)用中的研究與實(shí)現(xiàn)[J]. 廣東電力. 2014. 02.

[7] 李穎, 朱曼玲, 王海濤, 等. 基于移動(dòng)終端的高校統(tǒng)一消息推送平臺(tái)[J]. 華東師范大學(xué)學(xué)報(bào)(自然科學(xué)版). 2015. S1: 46-50.

[8] 許式偉, 呂貴華著. Go語(yǔ)言編程[M]. 北京: 人民郵電出版社. 2012. 9.

[9] Mark Summerfield 著. 許式偉, 呂貴華, 徐立, 何李譯. Go語(yǔ)言程序設(shè)計(jì)[M]. 北京: 人民郵電出版社. 2013. 8.

[10] (英)邁耶著, 佘建偉, 趙凱譯. Android4高級(jí)編程(第3版) [M]. 北京: 清華大學(xué)出版社. 2013. 04.

[11] 李濤, 葉昭. 校園統(tǒng)一消息推送平臺(tái)的用戶跨業(yè)務(wù)關(guān)系研究[J]. 華中科技大學(xué)學(xué)報(bào)（自然科學(xué)）. 2016. 44(sup): 172-175.

Design and Implementation of Message Push Platform based on Go Language

WANG Bohuai1*, ZHANG Ye2

(1. School of Information Engineering, Yulin University, Yulin 719000, China;2. Department of Student, Yulin University, Yulin 719000, China)

The android message push platform is designed and implemented in order to solve the real-time problem of data fetching by mobile applications and the consumption of traffic caused by repeated polling. The platform is composed of Service-Terminal and Mobile-Terminal. The Service-Terminal is implemented by Go language. The management background adopts Beego framework and Angularjs technology to realize the separation of the front and back ends. The connection of the bottom layer is realized by go protocol and TCP protocol. A custom protocol is used to establish the connection and communication with the server by Mobile terminal. The Mobile-Terminal mainly includes the function such as receiving and dispatching, parsing and disconnection of the message. After testing, the platform satisfies the requirements of real-time and low power consumption in mobile applications, and solves the problems of data duplication and high consumption of mobile data, and the effect is good in practice.

real-time；message push；android；Go language

10.19551/j.cnki.issn1672-9129.2017.02.06

TN929.5

A

1672-9129(2017)02-0033-04

2016-12-07；

2017-01-11。

王伯槐(1979-)，男，甘肅民勤，講師，研究生，主要研究方向：軟件工程、嵌入式系統(tǒng)；張燁(1977-)，女，陜西榆林，副教授，研究生，主要研究方向：軟件工程，數(shù)據(jù)庫(kù)技術(shù)。

E-mail:273022401@qq.com

引用：王伯槐,張燁. 基于Go語(yǔ)言的消息推送平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[J].數(shù)碼設(shè)計(jì), 2017, 6(2): 33-36.

Cite：Wang Bohuai, Zhang Ye. Design and Implementation of Message Push Platform based on Go Language [J]. Peak Data Science, 2017, 6(2): 33-36.