代超++鄧中亮

摘要：隨著智能手機和平板電腦等移動多媒體終端的普及和4G的加速發(fā)展，移動互聯(lián)網(wǎng)近年呈現(xiàn)了迅猛的發(fā)展態(tài)勢?；贏ndroid操作系統(tǒng)的各類APP應(yīng)用如雨后春筍，影響著人們的生活習(xí)慣。面向移動端的推送服務(wù)通過分析用戶喜好給用戶推送其感興趣的內(nèi)容，能大大提升用戶的活躍度和留存率，因此成為了APP應(yīng)用不可或缺的重要組成部分。然而由于Android官方的消息推送機制C2DM（Cloud to Device Messaging）卻有著覆蓋率偏低的缺陷，APP開發(fā)者需要自己開發(fā)消息推送系統(tǒng)。本文通過研究開源消息推送和即時通信系統(tǒng)，分析比較常用的網(wǎng)絡(luò)通信協(xié)議和網(wǎng)絡(luò)10框架，最終采用Java NIO網(wǎng)絡(luò)框架Netty和開源數(shù)據(jù)序列化工具Protocol Buffers實現(xiàn)了輕量級的面向移動端的推送服務(wù)系統(tǒng)。

關(guān)鍵詞：計算機應(yīng)用技術(shù)；Netty網(wǎng)絡(luò)框架；推送；Protocol Buffers

中圖分類號：TP311.1

文獻(xiàn)標(biāo)識碼：A

DOI：10.3969/j.issn.1003-6970.2015.12.001

本文著錄格式：代超，鄧中亮.基于Netty的面向移動終端的推送服務(wù)設(shè)計[J].軟件，2015，36（12）：01-04

0 引言

互聯(lián)網(wǎng)時代，推送技術(shù)在各行各業(yè)得到應(yīng)用。隨著移動瓦聯(lián)網(wǎng)的發(fā)展，很多APP應(yīng)用都集成了推送服務(wù)，如微信、網(wǎng)易新聞等。消息推送主要有兩種實現(xiàn)方式，客戶端定時“拉取”和服務(wù)器主動“推送”?！袄　狈绞绞强蛻舳税凑疹A(yù)設(shè)的觸發(fā)條件和時間間隔，不停地向服務(wù)器查詢更新，然后發(fā)出拉取請求以獲取最新消息；而“推送”的方式則是在客戶端和服務(wù)器之間保持一條連接通道，當(dāng)服務(wù)器有新消息時豐動將消息直接發(fā)送給客戶端，減少交瓦次數(shù)，提高了推送效率。以上兩種方式各有利弊，但是為了實現(xiàn)移動終端的低功耗和低流量，通常采用服務(wù)器豐動“推送”技術(shù)。由于服務(wù)器豐動“推送”需要在客戶端和服務(wù)器之間保持TCP長連接，當(dāng)用戶量龐大時，單臺服務(wù)器可能要保持上卣萬個TCP連接，這對于網(wǎng)絡(luò)服務(wù)器的開發(fā)要求很高。傳統(tǒng)的網(wǎng)絡(luò)服務(wù)器使用BIO（阻塞10）開發(fā)，多采用一連接一線程（One thread per connection）的線程模型，即每接受一個連接請求則產(chǎn)牛一個子線程處理該請求，這種模型導(dǎo)致服務(wù)器無法承受大量客戶端的并發(fā)連接，而且頻繁的線程上下文切換導(dǎo)致CPU利用效率不高。Netty是一個基于NIO的客戶端/服務(wù)器框架，NIO采用反應(yīng)堆（Reactor）模型，其單線程模型如圖l所示，其中一個Reactor線程聚合一個多路復(fù)用器Selector，可以同時注冊、監(jiān)聽和輪詢成千上萬個客戶端連接。Netty可以通過調(diào)整參數(shù)靈活配置成Reactor單線程、多線程和豐從多線程模型，用少量的線程即可以處理上萬條TCP連接，同時Netty中集成了豐流的編解碼框架和靈活的自定義編解碼器實現(xiàn)，能輕松實現(xiàn)私有的協(xié)議棧，很適合開發(fā)基于TCP長連接的推送服務(wù)。

1 傳輸協(xié)議的制定和編解碼實現(xiàn)

網(wǎng)絡(luò)服務(wù)器主要任務(wù)是處理與客戶端之間的數(shù)據(jù)交互，為了實現(xiàn)高效率可擴展的推送服務(wù)，數(shù)據(jù)傳輸協(xié)議的制定尤為重要。

1.1 數(shù)據(jù)傳輸協(xié)議的制定

當(dāng)前能直接用于生產(chǎn)環(huán)境的協(xié)議主要有XMPP、MQTT及部分私有協(xié)議。XMPP是一種基于XML的實時通信協(xié)議，具有很強的擴展性，但是由于XML文本協(xié)議帶來的數(shù)據(jù)冗余使其不太適合于移動端使用。MQTT是一種輕量級的、基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議，專門為低帶寬、不穩(wěn)定網(wǎng)絡(luò)所設(shè)計，協(xié)議小巧可擴展性強，比較適合作為移動端的消息協(xié)議，但是其不夠成熟、實現(xiàn)復(fù)雜且沒有成熟的Java開源實現(xiàn)。協(xié)議就是原數(shù)據(jù)和消息協(xié)議數(shù)據(jù)之間的一組關(guān)系映射，可看作是一種序列化機制，本文基于開源數(shù)據(jù)序列框架Protocol Buffers實現(xiàn)了一個可擴展的私有消息協(xié)議。Protocol Buffers是一個靈活、高效、結(jié)構(gòu)化的數(shù)據(jù)序列化框架，支持跨語言使用，在擁有.proto文件和知悉POJO對象類型的情況下可以進(jìn)行POJO對象的編解碼。利用Protocol Buffers的特點設(shè)計的具體的數(shù)據(jù)傳輸協(xié)議如圖2所示，幀末尾是將POJO對象序列化后的二進(jìn)制數(shù)據(jù)，由于Protobuf對POJO解碼一般來說需要知悉POJO對象的類型，所以在Protobuf Data之前采用兩個字節(jié)來表示消息對象的類型。TCP是個“流協(xié)議”，TCP協(xié)議層不保證消息的完整性，TCP協(xié)議底層存在粘包和拆包的問題，所以需要應(yīng)用層協(xié)議來保證消息邊界的正確性，一般可以通過在消息頭中添加表示消息總長度的字段FrameLen來解決。

1.2 協(xié)議編解碼框架實現(xiàn)

由于TCP協(xié)議的粘包/拆包等特點，白行實現(xiàn)該協(xié)議并不簡單，幸運的是Netty提供的眾多編解碼工具可以幫助我們輕松實現(xiàn)該數(shù)據(jù)傳輸協(xié)議的編解碼。Netty提供了基于責(zé)任鏈模式的編解碼及業(yè)務(wù)處理框架ChanneIPipeline，同時提供對主流編解碼框架如Protocol Buffers、Marshalling的原生支持。Netty中提供的LengthFieldBasedFrameDecoder/Length-FieldPrepender編解碼器能通過在消息頭添加長度域解決TCP粘包/拆包問題。協(xié)議整體的邏輯框架圖如圖3所示，Netty為了盡可能的提升性能，采用了串行無鎖化設(shè)計Cha nneIPipeline，在10線程內(nèi)部各個Handler依次被調(diào)用，避免線程競爭導(dǎo)致的性能下降。在接收消息時LengthFieldBasedFrameDecoder讀取消息長度域，根據(jù)長度讀取對應(yīng)長度的二進(jìn)制數(shù)據(jù)并遞交給NameFieldBasedProtobufDecoder進(jìn)行處理。NameFieldBasedProtobufDecoder先讀取兩個字節(jié)的消息類型名（Message TypeName），通過服務(wù)端維護(hù)的消息類型名-POJO的Java類型的查找表得到具體的Java類型，通過Protobuf工具類將二進(jìn)制數(shù)據(jù)轉(zhuǎn)化成POJO對象傳遞給MessageHandler進(jìn)行業(yè)務(wù)處理。在發(fā)送消息時，NameFieldPrepender根據(jù)發(fā)送的消息類型名將POJO對象轉(zhuǎn)換成Protobuf二進(jìn)制數(shù)據(jù)并在數(shù)據(jù)幀加上TypeName域后遞交給LengthFieldPrepender， LengthFieldPrepender計算出長度在數(shù)據(jù)幀前加上后通過網(wǎng)絡(luò)發(fā)送。整個推送服務(wù)的私有協(xié)議設(shè)計簡單，增加消息類型時只需重編譯.proto文件和在服務(wù)端添加對應(yīng)的消息類型名-POJO的Java類型項即可，可擴展性強。

2 服務(wù)端設(shè)計與實現(xiàn)

推送系統(tǒng)的主要任務(wù)是將消息通過TCP長連接發(fā)送到客戶端，根據(jù)業(yè)務(wù)需求的不同，會有多種不同的推送方式，例如廣播消息（推送給全體用戶），根據(jù)標(biāo)簽（Tag）推送等。同時面向移動端的推送服務(wù)還需要處理由于移動無線網(wǎng)絡(luò)不穩(wěn)定性帶來的TCP斷連，消息丟失等問題。下文闡述了使用Netty及數(shù)據(jù)庫存儲實現(xiàn)廣播消息和基于標(biāo)簽推送，同時采用心跳機制、消息回執(zhí)等方法來保證消息到達(dá)率和穩(wěn)定性。

2.1 心跳機制的設(shè)計

移動終端連上移動網(wǎng)絡(luò)獲得的IP實際上是運營商內(nèi)網(wǎng)IP，移動終端連接Internet需要通過運營商的GGSN（GateWay GPRS Support Note）模塊進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)化。運營商為了減少網(wǎng)絡(luò)NAT映射表的負(fù)荷，會清除一段時間內(nèi)沒有通信的鏈路對應(yīng)的NAT映射表，造成鏈路中斷。解決該問題的常用方法就是心跳機制，即客戶端或服務(wù)端每隔一段時間發(fā)送心跳包激活鏈路。心跳機制同時也能檢測鏈路可用性，幫助客戶端或服務(wù)端即時斷開失效鏈路，釋放寶貴的10資源。心跳機制原理主要如圖4所描述，圖中描述的是Ping-Pong型心跳，通常由通信一方定時發(fā)送Ping消息，對方收到Ping后，立即返回Pong消息。如果連續(xù)N次心跳檢測都沒有收到對方的Pong應(yīng)答消息，則認(rèn)為鏈路已經(jīng)發(fā)生邏輯失效，可以關(guān)閉該鏈路以節(jié)約資源。Android端可以利用白帶的AlarmManager機制定時發(fā)送Ping消息，客戶端檢測到斷線時可以啟動重連機制；服務(wù)端可以利用Netty的空閑檢測機制來完成心跳檢測。Netty中集成的空閑檢測機制ReadTimeoutHandler在時間t內(nèi)沒有收到任何消息時發(fā)生超時異常，可以利用其檢測t時間內(nèi)有無收到Ping消息，如果連續(xù)N次發(fā)生超時，則及時關(guān)閉鏈路避免產(chǎn)生過多的CLOSE WAIT狀態(tài)占用服務(wù)器10資源。

2.2 離線消息推送與消息回執(zhí)

心跳檢測和斷線重連的機制能夠保證客戶端與服務(wù)器之間有穩(wěn)定的TCP長連接。Netty采用NIO實現(xiàn)，采用Channel表示一條連接。當(dāng)客戶端需要使用推送服務(wù)時，必須先連接、注冊并登陸到服務(wù)器。Android客戶端可以使用隨機生成的用戶名和密碼進(jìn)行注冊，服務(wù)器驗證合法后Android端將用戶名和密碼持久化存儲以備以后登陸使用。Android客戶端將注冊成功的用戶名和密碼發(fā)送給服務(wù)端，服務(wù)端驗證成功后將該通道Channel及用戶信息封裝成UserSession存入用戶名Username-UserSession表中。推送功能一般都是以服務(wù)的形式提供給其他用戶或者其他應(yīng)用，采用Spring管理Netty可以很方便地對外提供RestFul接口的推送服務(wù)。采用Spring管理Netty并提供HTTP調(diào)用接口，整個推送服務(wù)的流程圖如圖5所示。最常用的推送服務(wù)類型為廣播類型，即推送給當(dāng)前在線或者離線的全體用戶。為了使暫時離線用戶在以后也能收到該條消息，必須采用數(shù)據(jù)庫存儲離線消息。在數(shù)據(jù)庫中建立兩張表，message（id.content，type...）、user_message（id.username.message_id，state...）。message表中type表示推送消息類型，如廣播，tag等，user_message中message_id為message表的id，state表示消息狀態(tài)，如未讀、已讀、過期等。當(dāng)服務(wù)器通過HTTP收到服務(wù)使用者推送消息請求時，會先判斷推送消息的類型并往message表中添加該條消息，然后根據(jù)消息類型查找數(shù)據(jù)庫中相應(yīng)的用戶集合，例如廣播消息類型會取出所有用戶，基于標(biāo)簽推送會取出關(guān)注該標(biāo)簽的用戶。遍歷用戶集合如用戶在線則根據(jù)Username取出Usersession中的Channel利用其write（）方法將消息推送給用戶，如果不在線則往user_message表中添加一條消息記錄。為了確保將離線消息推送給用戶，用戶每次上線后將取出user_message及message表中的未讀消息，如果已經(jīng)過期則修改state為過期，如果未過期則將消息推送給用戶。由于網(wǎng)絡(luò)的不確定性，服務(wù)端推送出去的消息可能不能到達(dá)用戶端，為此還需要有回執(zhí)確認(rèn)的機制來保證達(dá)到率。即客戶端收到推送消息后，將發(fā)送回執(zhí)ACK消息給服務(wù)端，服務(wù)端根據(jù)ACK中的message_id信息改變user message表中對應(yīng)消息的state為已讀。有了消息回執(zhí)機制，可以保證消息的到達(dá)率，大大提高用戶體驗和留存率。

3 系統(tǒng)測試

3.1 功能測試

系統(tǒng)測試分為功能測試和性能測試。功能性測試需要驗證兩個方面。首先客戶端需要能注冊登錄到服務(wù)器并接收到服務(wù)器推送的消息，其次客戶端在斷線情況下需要能夠發(fā)起重新連接。為了方便測試與觀察，采用安卓模擬器連接到服務(wù)器。模擬器收到的推送結(jié)果如圖6所示。為了測試客戶端的斷線重連機制，先斷開服務(wù)器端的網(wǎng)絡(luò)連接，通過LogCat可以看到客戶端檢測到了斷線并發(fā)起了重連請求，當(dāng)恢復(fù)服務(wù)器端網(wǎng)絡(luò)連接后，客戶端成功連接上服務(wù)器，能夠接收到推送消息。

3.2 性能測試

性能測試用于測試服務(wù)端能夠承載多少在線用戶。由于無法使用Android平臺模擬大量的TCP連接，這里在PC上實現(xiàn)了一個客戶端程序來模擬大量的用戶連接到服務(wù)器，服務(wù)器配置如表1所示，測試網(wǎng)絡(luò)結(jié)構(gòu)如圖7所示。

采用三臺PC機連接到服務(wù)器，每臺PC最多發(fā)起15000個連接，在服務(wù)器接受所有連接以后，分別測試基于標(biāo)簽的推送（擁有某標(biāo)簽的用戶占總用戶的l0%）和廣播消息。根據(jù)客戶端的消息回執(zhí)機制測試各種情況下發(fā)送到客戶端所需的時間，推送成功率以及服務(wù)器負(fù)載情況，所得結(jié)果如表2所示。

從結(jié)果可以看到，在客戶端與服務(wù)器在局域網(wǎng)環(huán)境下，推送成功率達(dá)到l00%，最大推送延時在12s內(nèi)，單臺服務(wù)器可以完成45k在線用戶的推送服務(wù)。

4 結(jié)論

本文論述了基于Netty的面向移動端的推送服務(wù)設(shè)計與實現(xiàn)。目前已完成廣播消息和基于標(biāo)簽的推送服務(wù)，單臺服務(wù)器能支撐45k在線用戶。下一步的工作將集中在增加富媒體消息的推送功能，進(jìn)一步提高單臺服務(wù)器的并發(fā)連接數(shù)和穩(wěn)定性以及構(gòu)建服務(wù)器集群以支撐百萬級用戶量。