基于Netty的IoT終端通信服務系統設計

顧振德 劉子辰 龍 隆 牟林宏

1(重慶郵電大學通信與信息工程學院 重慶 400065) 2(移動計算與新型終端北京市重點實驗室(中國科學院計算技術研究所) 北京 100190)

0 引 言

傳統的IoT系統由三部分構成：傳感器、網絡傳輸、數據交互平臺[1]。傳感器技術已經取得了長足發展，市場上存在各種類型設備，網絡傳輸的部署和應用都日趨成熟[2-4]。隨著IoT的發展，終端的應用規模都在百萬級別，終端向服務器并發地發送數據請求在某一時刻急劇增加，如何在短時間內提高服務器并發處理能力是數據通信服務系統開發面臨的一個急需解決的問題[5]。傳統的數據通信服務系統采用Java原生NIO技術方式實現，如果直接基于NIO類庫和API編程，會降低開發效率，同時出現epoll bug,導致Selector空輪詢，最終使CPU的占用率達到100%。羅文韜[6]采用異步處理和基于事件驅動的機制來提高服務器高并發處理的效率。汪佳文等[7]提出一種動態負載均衡算法，并結合優化的Pick-K算法方案實現高并發傳輸。

本文提出一種基于Netty的通信服務系統的設計方案。該方案借助Netty的異步非堵塞、事件驅動等性能構建高性能網絡通信程序[8]，并通過結合自定義功能模塊設計和自定義線程池進一步提高服務系統的并發處理能力。

1 Netty簡介與優化

1.1 Netty介紹

Netty是業界NIO框架中最流行的框架，它的健壯性、可擴展性、可定制性都是首屈一指的[9]，可進行如TCP、UDP套接字服務器的開發。本系統因終端與服務器之間的數據通信要求實時性，因此終端與服務系統建立TCP長連接實現。基于Netty實現終端通信服務系統，可以不用過多關注連接的建立、數據的編解碼等底層通信的實現，進而能夠更好地關注業務模塊的實現，極大地簡化了網絡編程。

1.2 Netty優化設計

長鏈接需要維護每個鏈路自己消息接收和發送的緩沖區，而JDK原生NIO類庫[10]無法動態擴容，從而給服務器帶來沉重的內存負擔。Netty提供的ByteBuf支持容量的動態調整，選擇AdaptiveRecByteBufAllocatorv在創建服務端時候指定RecvByteBufAllocator，緩沖區的大小設置為消息的平均大小，避免額外的內存浪費。TCP層面的接收和發送緩沖區的大小設置，對于長連接設置為32 K。每個長連接就是一個會話，每個會話都有心跳等數據結構，給通信服務器帶來沉重GC(Garbage Collection)壓力，同時消耗大量的內存[11]。本系統在設計通信服務端的時候采用ByteBuffer內存池技術來解決上述問題。

2 系統設計

2.1 協議設計

終端向服務器發送的數據是一連串的字節數據，為了讓服務器識別這些字節數組，制定特殊的協議格式，服務器響應終端也要通過該協議。圖1為協議的設計。

圖1 協議圖

8個字節的終端序列號，2個字節的消息體長度和1個字節的協議版本，最后是消息體[12]。消息體設計代碼如下：

public class ProtocolFrame{

private long seriaNumber;

private byte version;

private short contentLength;

private byte[] content

…

}

serialNumber為終端的序列號，每一個終端將有唯一的序列號；version表示協議的版本號；contentLength為消息體的長度；content表示消息體，消息體包含終端運行的各種參數等。

2.2 服務器設計

服務器設計劃分為6模塊，分別是異常處理、日志記錄、數據接收、業務處理、數據發送、session管理等模塊。異常處理模塊主要負責捕獲IoT通信服務系統自身的異常，以及客戶端的異常，從而提高系統的穩定性。處理異常日志記錄模塊主要滿足性能測試和維護工作需要，設置輸出內容，輸出到控制臺和文件等。數據接收模塊首先對客戶端的連接IP進行過濾，驗證客戶端的合法性。其次根據自定義通信協議解碼接收的數據，對解碼后的數據進行解密，驗證數據的有效性和封裝數據。同時添加空閑超時處理邏輯，設計失效時間為180 s，若服務器180 s沒有接受到數據包，則及時關閉超時的客戶端連接。業務處理模塊實現具體的業務邏輯，將來自客戶端的數據分類存儲到MYSQL數據庫中，實現數據的持久化。數據發送模塊主要負責將來自業務處理模塊的數據進行處理并下發到終端，對數據加密，根據協議對發送數據編碼，之后發送出去。session管理模塊在終端連接服務器時將session信息進行保存，從而管理和操作連接，定時清除非活躍的連接，釋放內存，減輕服務器連接壓力。終端通信服務系統的功能模塊如圖2所示。

圖2 通信系統功能模塊圖

利用Netty框架構建服務器的大致流程：

1) 配置服務器的NIO線程組。

//該線程組用于處理服務器接收終端的連接；

master=isLinux()?new EpollEventLoopGroup(DEFAULT_THREAD_NUM, threadFactory)

:new NioEventLoopGroup

(DEFAULT_THREAD_NUM, threadFactory);

//該線程組用于處理來自中端的網絡讀寫；

worker=isLinux()?new EpollEventLoopGroup

(DEFAULT_THREAD_NUM,threadFactory)

:new NioEventLoopGroup

(DEFAULT_THREAD_NUM, threadFactory);

2) 創建 ServerBootstrap對象，傳遞master、work兩個線程池。

bootstrap=new ServerBootstrap();

3) 調用ServerBootstrap類的childHandler方法傳入接口實現類處理具體的業務，綁定I O事件的處理類，監聽端口IP地址，處理網絡IO事件。

bootstrap.group(master, worker);

bootstrap.channel(serverChannelcls);

bootstrap.localAddress(ipaddress, port);

bootstrap.childHandler(handler);

網絡IO事件處理類的部分關鍵代碼塊：

@Override

protected void initChannel(SocketChannel channel) throws Exception {

//IP過濾，對黑名單中IP拒絕連接

channel.pipeline().addLast(filter);

//數據解碼

channel.pipeline().addLast(getProtocolFrameDecoder());

//數據編碼

channel.pipeline().addLast(protocalFrameDecrypt);

//數據解密

channel.pipeline().addLast(protocalFrameEncoder);

//數據加密

channel.pipeline().addLast(protocalFrameEncrypt);

//添加空閑超時的工具，關閉超時連接，刪除

channel.pipeline().addLast(messageProcessofEventLoopGroup, new IdleStateHandler(180, 0, 0));

//具體業務處理

channel.pipeline().addLast(messageProcessofEventLoopGroup, messageProcessor);

//異常處理

channel.pipeline().addLast(messageProcessofEventLoopGroup, exceptionHandler);

}

4) 使用創建的ServerBootstrap對象綁定，開始監聽，用于異步操作的回調通知。

ChannelFuture f=bootstrap.bind().sync();

經過以上操作，服務系統成功啟動，等待終端的連接請求，服務器接收到終端的數據后，將從過濾IP模塊開始傳遞數據并處理。

2.3 業務處理線程池設計

業務處理需要訪問數據庫，如果直接使用Netty的worker線程進行業務處理，可能會因不確定的執行時間導致線程被阻塞，最終導致服務器宕機。因此采用自定義業務線程池來處理比較耗時的業務邏輯，進而提高通信系統性能。ThreadPoolExecutor類從JDK1.5開始被提供自定義線程池[13]。newFixedThreadPool可創建固定大小的線程池和可控控制線程最大并發數，當線程池中的線程數達到其設定的核心線程大小時，新創建的線程會在無界隊列中等待[14]。當線程池中的某個線程執行失敗時新創建的線程會替代執行剩下任務。當線程池中創建的線程調用shutdown函數時會退出線程池[14]。線程池最大尺寸不要超過系統資源限制，算法公式如下：

(1)

式中：Ns為線程的設置數；Ni為CPU核心數；Nj為預期CPU核心利用率；T/C為任務等待的時間與執行時間的比值[15]。

IoT終端與服務器通信的數據交互主要包括數據的解析、訪問緩存數據庫、入庫MYSQL數據庫、發送數據的預處理等操作。其中數據的編解碼、加解密等執行時間短操作交由NIO線程執行，而耗時比較長的業務處理交由自定義線程池執行完成，具體執行流程如圖3所示。

圖3 Netty的NIO線程池與自定義線程池交互流程圖

3 測試結果

采用開源壓力測試工具Jmeter模擬IoT終端進行通信系統性能測試，從服務系統平均響應時間、系統IO吞吐量2個方面進行數據分析。因條件有限，性能測試在網絡帶寬100 MB/S的局域網中執行，服務器CPU四核Intel(R) Core(TM) i5-3210M CPU @2.50 GHz內存8 GB, 操作系統centos-release-7-5.1804.e17.centos.2.x86_64。

模擬IoT終端每2秒發送一個180字節的實時數據，由圖4可知，當并發數小于1 600時，采用Netty框架結合自定義線程池方案并沒有較大的優勢，因為調用本地方法會有一定的系統開銷。當并發數量達到2 400時，采用Netty框架結合自定義線程池方案優勢較為明顯。基于Java NIO的實現方案因系統消耗資源較大導致響應時間過長，同時基于Netty的實現方案因業務操作性能開銷比較大，阻塞了I/O線程，導致響應時間過長。采用Netty框架結合自定義線程池方案系統平均響應時間仍在100 ms以下，且未達到瓶頸。較Java NIO和Netty實現方案平均響應時間縮短了97%和95%。

圖4 平均響應時間比較

在吞吐量方面，由圖5可知，當并發達到1 200時，基于Java NIO的實現方案平均吞吐量達到最高值，隨著并發數請求數增大，服務器出現異常吞吐量下降。當并發數達到2 000和2 400時，采用Netty框架結合自定義線程池方案比基于Netty框架平均吞吐量增加了16.7%和33.2%。實驗證明，當4 000并發連接系統時，系統仍然穩定運行，如圖6所示。這說明采用Netty框架結合自定義線程池方案符合IoT終端通信服務系統處理高并發的設計要求。

圖5 平均響應吞吐量比較

圖6 連接統計圖

4 結 語

本文介紹了IoT移動終端與服務器數據交互系統，基于Netty框架和Java的ThreadPoolExecutor結合的設計方案，重點研究設計通信系統編解碼、加解密等模塊，提出一種自定義線程池處理耗時業務的設計方案。經驗證采用Netty框架結合自定義線程池可提高系統的高并發處理能力。該設計已成功應用于某企業通信系統當中，并且與30 000多臺IoT終端進行數據交互，未出現數據交互不穩定情況，且系統運行效果良好。實踐證明，該設計是一種可參考的通信設計方案。