基于Netty+WebSocket的社區(qū)增值服務(wù)平臺(tái)的推送設(shè)計(jì)

陳純純

摘 要：通過對(duì)比國內(nèi)外同類軟件，服務(wù)端采用Netty+WebSocket技術(shù)，客戶端采用基于Android平臺(tái)的JSON解析技術(shù)，設(shè)計(jì)并實(shí)現(xiàn)了一款智能小區(qū)增值服務(wù)軟件系統(tǒng)，可以向小區(qū)用戶分組及時(shí)推送重要資訊，向小區(qū)周圍配套服務(wù)系統(tǒng)提供接口。文中主要介紹了該系統(tǒng)推送服務(wù)的設(shè)計(jì)原理。

關(guān)鍵詞：Netty；WebSocket；JSON；增值平臺(tái)

中圖分類號(hào)：TP393.0 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：2095-1302（2016）12-00-03

0 引 言

隨著人們逐漸從PC解放，需求開始轉(zhuǎn)移到移動(dòng)設(shè)備的應(yīng)用上。目前福建地區(qū)的小區(qū)住戶、物業(yè)和周邊配套服務(wù)都還處于離散狀態(tài)，人們迫切希望有一款基于移動(dòng)設(shè)備的智能社區(qū)服務(wù)平臺(tái)，可以通過該系統(tǒng)方便住戶隨時(shí)獲取小區(qū)的重要資訊，了解住宅的實(shí)時(shí)情況，監(jiān)控和控制住宅內(nèi)的電器設(shè)備。而小區(qū)周邊的其他配套服務(wù)系統(tǒng)可以通過該平臺(tái)提供的接口直接與平臺(tái)對(duì)接，向住戶提供服務(wù)。

1 系統(tǒng)設(shè)計(jì)原理圖

本系統(tǒng)建立在J2EE平臺(tái)上，運(yùn)用 MySQL數(shù)據(jù)庫管理系統(tǒng)將 JSON解析與Netty、 WebSocket等技術(shù)相結(jié)合，構(gòu)建更加智能的社區(qū)增值服務(wù)平臺(tái)。社區(qū)增值服務(wù)系統(tǒng)搭建在云平臺(tái)之上，充分利用現(xiàn)代化信息技術(shù)手段實(shí)現(xiàn)社區(qū)管理及服務(wù)的信息化、集約化，依托云平臺(tái)的理念和優(yōu)勢，將已有的專業(yè)系統(tǒng)納入其中，為社區(qū)居民、物業(yè)管理、周邊服務(wù)機(jī)構(gòu)提供便利豐富的終端服務(wù)。系統(tǒng)設(shè)計(jì)原理圖如圖1所示。

該平臺(tái)的亮點(diǎn)是信息的分類推送，開發(fā)之前對(duì)信息推送的兩種方式進(jìn)行分析：

（1）第一種是客戶端使用Pull（拉）的方式，即定時(shí)到服務(wù)器上獲取，看是否有更新的信息。

（2）第二種是服務(wù)器使用Push（推送）的方式，把最新的信息Push到客戶端上。

雖然Pull和Push兩種方式都能實(shí)現(xiàn)獲取服務(wù)端更新信息的功能，但Push方式比Pull方式更優(yōu)越[1，2]。

本文通過對(duì)比分析國內(nèi)現(xiàn)有的移動(dòng)設(shè)備推送解決方案，采用Netty+WebSocket持久連接的方式，實(shí)現(xiàn)了消息的實(shí)時(shí)性推送和分類推送。

2 推送與控制實(shí)現(xiàn)

平臺(tái)可實(shí)現(xiàn)系統(tǒng)用戶的需求，如查看家中的光照強(qiáng)度、室內(nèi)溫度、空氣濕度、煙霧濃度等實(shí)時(shí)數(shù)據(jù)，并對(duì)家中的家居進(jìn)行控制操作，對(duì)硬件與手機(jī)之間的鏈接通信進(jìn)行了詳細(xì)合理的設(shè)計(jì)。Netty與WebSocket的結(jié)合完美解決了此通路問題，為實(shí)現(xiàn)平臺(tái)的實(shí)時(shí)推送和分類推送奠定了基礎(chǔ)。

2.1 推送的設(shè)計(jì)與實(shí)現(xiàn)

平臺(tái)的服務(wù)器分為Netty Server與WebSocket Server兩個(gè)部分。

（1）Netty Server集成了WebSocket Client，用來實(shí)現(xiàn)與各硬件之間的數(shù)據(jù)傳送，Netty Server在初始化時(shí)與WebSocket Server建立長鏈接；

（2）WebSocket Server實(shí)現(xiàn)了與集成在Netty服務(wù)器中的WebSocket Client之間的數(shù)據(jù)傳送以及與用戶手機(jī)端（或網(wǎng)頁）的交互。

推送和控制詳細(xì)設(shè)計(jì)原理圖如圖2所示。

平臺(tái)將傳感器的數(shù)據(jù)推送到用戶的流程描述：單片機(jī)采集各傳感器的實(shí)時(shí)數(shù)據(jù)，將這些數(shù)據(jù)通過TCP上傳到Netty服務(wù)器，當(dāng)TCP與Netty服務(wù)器第一次建立連接時(shí)，觸發(fā)channelActive（）方法建立通道，該通道在傳感器斷開之前一直存在，此后傳感器定時(shí)發(fā)送數(shù)據(jù)，并直接觸發(fā)channelRead0（）方法接收，接收到的數(shù)據(jù)由集成在本服務(wù)器的WebSocket Client模塊處理，通過WebSocketClient.send（）方法發(fā)送給WebSocket服務(wù)器，WebSocket服務(wù)器中的WebSocket Server通過onMessage（）方法接收，接收到實(shí)時(shí)數(shù)據(jù)后，則由client.session.getBasicRemote（）.sendText（msg）將數(shù)據(jù)推送給手機(jī)或網(wǎng)頁終端。

Netty服務(wù)器采用多線程服務(wù)器，對(duì)于每一個(gè)連接請求，dispatcher都會(huì)為其創(chuàng)建并分配一個(gè)線程，該線程負(fù)責(zé)這個(gè)請求的處理，優(yōu)點(diǎn)是執(zhí)行粒度是完整的處理流程，處理邏輯清晰，易于開發(fā)。但也存在隨著處理請求的不斷增加，會(huì)導(dǎo)致并發(fā)執(zhí)行的線程數(shù)量太多等問題。過多的線程數(shù)量會(huì)導(dǎo)致系統(tǒng)在線程調(diào)度和資源爭用上的開銷過大，從而引起系統(tǒng)性能急劇下降，導(dǎo)致系統(tǒng)處理能力下降。該平臺(tái)采用了改進(jìn)措施，引入線程池，系統(tǒng)最多只能創(chuàng)建一定數(shù)量的線程，該平臺(tái)規(guī)定最多能創(chuàng)建的線程數(shù)量為100。當(dāng)所有線程都飽和運(yùn)行時(shí)，新到達(dá)的處理請求只能等待或者被拋棄。

在實(shí)現(xiàn)WebSocket的鏈接過程中， 客戶端和普通的瀏覽器都通過80或者443端口和服務(wù)器進(jìn)行請求握手，服務(wù)器根據(jù)http header識(shí)別是否是一個(gè)WebSocket請求，如果是，則將請求升級(jí)為一個(gè)WebSocket連接，握手成功后就進(jìn)入雙向長連接的數(shù)據(jù)傳輸階段。WebSocket的數(shù)據(jù)傳輸基于幀方式：0x00 表示數(shù)據(jù)開始， 0xff表示數(shù)據(jù)結(jié)束，數(shù)據(jù)以u(píng)tf-8編碼。第一次請求客戶端發(fā)送的是http請求，請求頭中包含WebSocket相關(guān)的信息，服務(wù)器端對(duì)請求進(jìn)行驗(yàn)證，驗(yàn)證成功后，將請求升級(jí)為一個(gè)WebSocket連接，之后的通信就進(jìn)入雙向長連接的數(shù)據(jù)傳輸階段，通過send和onMessage方法通信。

2.2 分類推送

平臺(tái)采用WebSocket協(xié)議不僅實(shí)現(xiàn)了Netty服務(wù)器與WebSocket服務(wù)器的實(shí)時(shí)通信，在分類通信上也做了一定嘗試，如推送工作，推送給哪一類型的用戶，可以根據(jù)數(shù)據(jù)的格式來進(jìn)行劃分，在本平臺(tái)中只做了初步劃分，如數(shù)據(jù)格式為：{ "from"："SMSG"，"room"："1201"，"temperature"："1"，"humidity"："2.0"，"smoke？"："3"}（JSON形式），從“room”字段可以知道該數(shù)據(jù)是準(zhǔn)備傳送給1201室的用戶，目前平臺(tái)只做了這個(gè)分類，平臺(tái)的下一步工作將在數(shù)據(jù)的格式上進(jìn)行進(jìn)一步細(xì)化和分類，如按不同的樓棟，甚至不同的樓層分類，在分類推送上完善平臺(tái)的功能。