基于Go語言的消息推送平臺的設計與實現(xiàn)

王伯槐*，張燁

?

基于Go語言的消息推送平臺的設計與實現(xiàn)

王伯槐1*，張燁2

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

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

實時; 消息推送；android；Go語言

引言

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

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

1.1 整體分析

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

當APP Server要推送消息到APP時，首先將這條消息發(fā)送到推送消息服務器，推送消息服務器首先判斷此App Service對應的App是否存在注冊的移動端，并返回結果給APP Service。如果存在，對這條消息進行過濾、加工，然后發(fā)給移動端APP。

圖1 系統(tǒng)圖

1.2 移動端SDK需求分析

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

表1 移動端SDK用例描述

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

1.3 推送消息服務器需求分析

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

表2 推送消息服務器用例圖描述

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

1.4 APP Server SDK需求分析

APP Server SDK向App Server提供兩種推送方式，一種是面向整個App應用的終端推送廣播消息，另一種是對指定標簽的移動端推送消息。用例描述如表3所示。

表3 APP Server SDK用例描述

2 系統(tǒng)設計

2.1 推送消息服務器設計

推送消息服務器軟件架構設計如圖2所示。

圖2 推送消息服務器軟件架構設計圖

Link（連接組件）負責與移動應用終端與應用服務器的連接并校驗連接的合法性。ORM（數(shù)據(jù)庫映射組件）用來處理數(shù)據(jù)庫操作。

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

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

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

控制臺包括前端頁面組件，webService接口與邏輯處理三個方面。

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

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

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

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

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

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

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

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

push方式需要客戶端和服務器之間維持一個TCP/IP長連接，有新消息更新時，服務器向客戶端推送[4]。

3.1 長連接與斷線重連的實現(xiàn)

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

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

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

表5 斷線重連策略

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

3.2 消息處理與推送

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

推送平臺的服務端接口接收到應用服務器的消息后，先對消息進行一系列的分析與處理，最終確定消息的推送模式。本平臺消息推送模式共有四種，下面以服務端接口收到一條消息為例，描述其消息推送模式。

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

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

3)如果此消息是標簽消息，要發(fā)送給此標簽對應的移動端，移動端在線就直接將消息推送給該移動端。

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

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

推送平臺的服務端接口接收到應用服務器的消息后，先對消息進行一系列的分析與處理，最終確定消息的推送模式。

首先移動端上線后訂閱一個以自己唯一標識符為名的Redis訂閱通道，當服務端接口接收到推送消息后，如果是廣播模式消息則查詢此應用下的所有注冊過的移動端訂閱通道名稱，如果是標簽模式消息則查詢此應用下的這個標簽對應的移動端訂閱通道名稱。得到移動端訂閱名稱后在去移動端的連接管理查詢移動端是否在線，如果在線則直接發(fā)布消息到移動端訂閱的通道，如果離線則將此消息存到移動端對應的離線消息隊列中。移動端的接口訂閱后，當有消息發(fā)布到訂閱通道后，移動端接口就可以立即接收到此消息，然后將消息推送到移動端。

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

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

圖4 消息推送平臺消息記錄

圖5 移動端消息接收圖

4 結語

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

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

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

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

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

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

[6] 律智堅, 吳廣財著.消息推送在移動高級應用中的研究與實現(xiàn)[J]. 廣東電力. 2014. 02.

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

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

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

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

[11] 李濤, 葉昭. 校園統(tǒng)一消息推送平臺的用戶跨業(yè)務關系研究[J]. 華中科技大學學報（自然科學）. 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ù)庫技術。

E-mail:273022401@qq.com

引用：王伯槐,張燁. 基于Go語言的消息推送平臺的設計與實現(xiàn)[J].數(shù)碼設計, 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.