智慧校園數字實驗室云邊協同服務器開發研究

綦 慧，張 鍇

（北京工業大學 信息學部，北京 100124）

0 引言

現如今，在理工科院校的專業實踐教學過程中，每個學期都會產生多種類型的實驗數據及大量實驗文件。數字化校園中的數據不僅包括實驗的實時數據和文件，而且包括實驗報告、學生信息等靜態數據。因為這些數據在服務器里的存儲時間不同，對其處理方式也不盡相同。此外，海量的原始數據在網絡邊緣產生并匯入通信網絡，不僅占用大量帶寬資源，還對快速、可靠的傳輸與計算帶來了巨大挑戰。由于無線通信帶寬有限，有線網絡帶寬也不可能無限增加，并且由于遠離計算中心，通信網絡的邊緣設備計算能力十分有限，因此傳統的計算網絡架構難以滿足廣大終端日益增長的任務處理需求。

云計算提出一種有效應對數據爆發的方案，即可將終端設備沒有能力處理的計算任務上傳到云計算中心進行處理。但是，將大批量物聯網設備數據發送到云端所需的網絡通信資源非常多，隨著數據量的增加，傳輸成本也會隨之增加。而且云端距離設備端較遠，會產生較大的傳輸時延及較慢的傳輸速率。為解決云端處理所面臨的問題，邊緣計算應運而生。然而，邊緣服務器的資源有限、處理能力有限，遠沒有云的處理計算能力強大。

云服務中心側重于大數據、大計算量以及對實時性要求不高的業務場景，邊緣服務器側重于低時延、快速響應的業務場景。云與邊緣處理并不沖突，二者是緊密協作、協同互補的關系。

1 相關研究

近年來，云計算、大數據及人工智能技術的快速發展推動了高校信息化建設與改革，越來越多高校開展了信息化實驗室建設工程，將理論教學與實驗教學相結合，以加強學生創新意識與創新能力的培養。云計算可整合計算、存儲、網絡、軟件等資源，具備按需分配、獲取迅速、訪問便捷等特點，簡化了實驗教學資源管理工作，提高了實驗教學效率。

文獻［8］針對高校教學中的實驗仿真環節設計了云計算環境；文獻［9］結合云平臺建設、信息化系統建設等，設計一種云平臺實驗教學中心建設方案；文獻［10］借助云計算平臺，探索開發虛擬實驗室控制系統與虛擬實驗室用戶平臺；文獻［11］提出在高校網絡中心現有計算機、網絡等硬件設施基礎上，使用云服務應用軟件構建云計算實驗平臺，以滿足大學計算機實驗教學的需要；文獻［12］基于OpenStack 框架搭建云計算實驗平臺，從教師初始配置、投資效費比、實驗室開放、教師實驗管理和學生準備時間5個維度對云計算實驗平臺效果作綜合分析；文獻［13］針對因計算機實驗室的資源擴展性與使用靈活性、個人電腦軟件環境配置、網絡共享等限制，將個人電腦用于實驗課程會造成諸多不便等問題，基于云設計了高校計算機實驗教學方案。

然而，云平臺的優勢固然明顯，卻很難滿足本文運動控制實驗平臺電機實驗較高的實時性要求，因此本文基于云服務器與邊緣服務器之間的協同互補，針對智慧校園實驗室管理系統的要求，沒有只選用云平臺服務器，而是首先設計本地邊緣服務器與云服務器協同的后端架構，即設備側本地服務器用于存儲實驗實時數據，云端服務器用于存儲本地備份數據及靜態數據，其次對服務器協同下的網絡通信進行研究，采用Netty 高性能異步通信框架實現可靠通信，最后完成了系統開發。

2 系統模型與應用架構設計

針對工科院校專業實驗室內設備種類多樣、數量繁多的特點，設計了智慧實驗室管理平臺的后端服務器體系結構，如圖1 所示。每個實驗室配備一臺本地服務器，在智能設備的邊緣側對數據進行采集與實時處理，云服務器適時介入與本地服務器協同進行工作。設備與服務器之間的網絡通信以及服務器之間采取Netty 高性能異步通信框架進行數據通信傳輸。

Fig.1 Server system model圖1 服務器系統模型

本文采用本地服務器邊緣處理與云服務器協同的后端結構，因此系統整體網絡結構如圖2 所示。

Fig.2 System network structure圖2 系統網絡結構

如圖2 所示，考慮如下幾個應用場景：

（1）當實驗室本地資源有限時，可選擇本地服務器作為后端服務器。云服務器通過一定的通信模式，從本地服務器讀取數據，用作備份。該操作不僅可充分利用資源有限的本地服務器存儲實驗實時數據，而且當用戶需要在Web 端進行實驗回放時，不需要實時性的后端數據支撐，而是采用云端的備份數據。正常工作情況如圖3 所示。

（2）如圖4 所示，當本地服務器不足以支撐實驗室本地資源的使用時，云端服務器介入，暫時代替本地服務器作為后端服務器。

Fig.3 Normal working conditions圖3 正常工作情況

Fig.4 Other cases圖4 其他情況

（3）如圖4 所示，當本地服務器發生意外，如出現數據量過大、存儲不足等情況時，使用云端服務器作為遞補服務器。

綜上所述，在解決了智慧校園實驗室系統服務器架構問題后，考慮到此實驗室系統所需的數據傳輸具有較強的實時性、較大的數據量以及一定的并發量，高性能與高可靠的網絡數據通信將是下一步需要解決的問題，合理的服務器架構與高性能的IO 是相輔相成的。針對一個實驗室有多個實驗臺帶來的并發實際需求，JavaBIO 這種同步阻塞式的IO 則不合適在此系統中應用，因此選擇JavaNIO 這種非阻塞IO 進行讀寫。

3 Netty 高性能異步通信

根據上文的分析，不管是數據從設備端流向本地服務器還是流向云服務器，亦或是從本地服務器流向云服務器，均為多對一關系。當出現多客戶端并發情況時，高性能的數據傳輸及通信則顯得尤為重要。由于Java NIO 的類庫和API 繁多，使用較為麻煩，需要熟練掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等，開發工作量和難度都非常大，且JDK NIO 具有一些Bug，例如臭名昭著的Epoll Bug 會導致Selector 空輪詢，最終導致CPU 使用率達到100%。一直到JDK 1.7 版本，該問題仍舊存在，沒有得到根本性解決。而Netty 是業界NIO 框架中最流行的框架，其健壯性、可擴展性、可定制性都是首屈一指的。

該Web 控制所用系統因實驗臺設備端與服務器之間的數據通信要求實時性，所以設備端與服務器端建立長連接，基于Netty 實現設備通信服務系統，可不用過多關注連接建立、數據編解碼等底層通信的實現，進而能更好地進行業務開發。因此，經綜合考慮后，選取Netty 高性能異步通信框架搭建智慧校園實驗室通信服務器來完成IO 讀寫。

Netty 框架使用主從Reactor 模式，下面進行簡單介紹。如圖5 所示，Netty 抽象出兩組線程池，BossGroup 專門負責接收客戶端連接，WorkerGroup 專門負責網絡讀寫。Boss-Group和WorkerGroup類型都是NioEventLoopGroup，Nio-EventLoopGroup 相當于一個事件循環組，該組中含有多個事件循環，每一個事件循環是NioEventLoop。NioEventLoop表示一個不斷循環的執行處理任務的線程，每個NioEvent-Loop 都有一個selector，用于監聽綁定在其上的socket 網絡通信。NioEventLoopGroup 可以有多個線程，即可含有多個NioEventLoop。

每個Boss NioEventLoop 循環執行步驟分為3 步：①輪詢accept 事件；②處理accept 事件，與client 建立連接，生成NioScocketChannel，并將其注冊到某個worker NIOEvent-Loop 上的selector；③處理任務隊列的任務，即runAllTasks。

每個Worker NIOEventLoop 循環執行步驟也分為3 步：①輪詢read、write 事件；②處理I∕O 事件，即read、write 事件，在對應NioScocketChannel 中進行處理；③處理任務隊列的任務，即runAllTasks。

如上所述，Netty 最大的優點就是采取了主從Reactor線程模型，抽象出兩組線程組，線程組中每一個線程都由selector 一直在輪詢執行。一組負責與客戶端建立連接，即BossGroup，在本實驗室系統中，這一組線程組負責與客戶端即設備端進行服務器連接；另一組即WorkerGroup，在線程組的相應線程中選擇合適的管道處理讀寫事件。在本系統中，不同的實驗臺設備可分別選擇線程組中某一線程的channel 進行實時數據的本地服務器存儲等。

綜上，使用Netty 這種異步非阻塞通信方式，一組線程用于客戶端連接，一組線程用于IO 處理，可有效解決多并發連接問題，從而保證通信的高性能與可靠性。

Fig.5 Netty master-slave Reactor thread model圖5 Netty 主從Reactor 線程模型

4 服務器通信應用實現及客戶端多并發測試

4.1 服務器通信實現

如上所述，Netty 既可以開發客戶端，又可以開發服務器端。即針對服務端或客戶端某一端，先使用鏈式編程寫出服務器端∕客戶端配置代碼，再到處理器Handler 里處理業務邏輯代碼。如圖6 所示，對于服務器端的開發，首先創建BossGroup 與WorkerGroup 兩組線程組，采用鏈式編程對兩組線程組進行設置，如使用NioSocketChannel 作為服務器通道實現網絡通信，以及設置線程隊列連接個數、設置活動連接狀態、創建一個通道初始化匿名對象等，然后通過channel 拿到pipeline 并添加Handler，在此處進行后續的業務處理任務，并根據需求進行對應開發。

Fig.6 Netty server-side development flow圖6 Netty 服務器端開發流程

系統主要有以下IO 讀寫通信需求：①實驗時，服務端對客戶端的二進制實時數據文件進行讀取；②云端對本地服務器數據進行讀取；③客戶端對本地服務器數據進行讀取；④客戶端對云服務器數據進行讀取。下面針對客戶端的多并發情況進行服務器連接壓力測試，通過測試服務器的穩定性，驗證在實驗室實驗臺數量達到上限后，服務器還能否完成客戶端連接以及后續的業務邏輯處理任務，即IO 讀寫等任務。

4.2 客戶端多并發測試

針對本實驗室系統的實際情況與需求，一間實驗室配備一個本地服務器。由于空間受限的原因，一間實驗室的實驗臺個數一般為十幾臺，一臺服務器基本不會連接超過20個實驗臺。因此，對于服務器的數據接收場景，分別進行20 以及大于20個客戶端的多并發連接壓力測試，具體測試如下：

測試挑選的業務需求是客戶端讀取一個二進制文件，然后發送給服務器端，服務器端根據二進制文件的前面兩個字節，將其存放到不同目錄中。服務器端按照Netty ByteBuf 的getByte 方法取前兩個字節，存放到數組中，并與提前設定好的字節進行比對。通過ctx 獲取channel 得到客戶端IP，記錄連接的客戶端并進行標記處理，之后存入不同目錄中。根據需求在Handler 里進行服務端需求開發，進而進行客戶端開發。

首先在開啟服務端之后開啟客戶端，即表示一個實驗臺上線需要服務器端進行業務處理。

（1）當實驗臺連接數為20 時，測試結果如圖7 所示。（2）當實驗臺連接數大于20 時，測試結果如圖8 所示。

Fig.7 Test connection number 1圖7 測試連接數1

Fig.8 Test connection number 2圖8 測試連接數2

（3）假設接下來無限制地增加連接數，因為Java 虛擬機（JVM）分配的內存大于系統可用內存數，所以沒有足夠的空間分配給JVM，可采取調整JVM 內存的方法解決該問題。如圖9 所示，當無限制增加客戶端連接數時，會出現JVM 內存不足的情況。

Fig.9 Unlimitedly increasing the number of connections圖9 無限制增加連接數

但對于本系統而言，30 以內的連接數已足夠使用，不需要再調整JVM 內存。因此，本系統采取Netty 的異步通信框架，可實現客戶端多并發快速連接與大數據量的讀寫操作。另外Netty 把NIO 封裝后，開發變得不再繁瑣。

4.3 系統實現

在后端服務器的有力支撐下，在微信小程序端（移動端）以及Web 端分別開發了系統前端界面。對于前端請求的服務器選擇，如前文所述，在系統正常運行的情況下，對于實時的動態實驗數據選擇本地服務器，靜態數據選擇云端服務器，客戶端與服務端通信選擇Netty 實現。前端實現過程如下：針對微信原生開發框架只有一組Tab 欄的問題，為滿足學生與管理員登錄之后不同的功能需求，學生端采用原生的Tab 欄界面，管理員端界面另外單獨進行開發。

對于學生端，主要欄目有：申請實驗、我的實驗（即預約成功的實驗）、實驗報告（上傳）、我的，如圖10 所示。

對于教師端，主要欄目有：申請、實驗、報告、我的，與學生端的相關功能對應，如圖11 所示。

對于Web 端界面，其中實驗實時操作頁面如圖12 所示。正是由于Netty 高性能異步通信的加入，為一個實驗室內10個左右實驗臺的同時可靠運行提供了保障，有效實現了實時數據的服務器存儲等操作。同時，對多個實驗臺的并發連接進行測試，效果良好。

因此，在后端服務器架構的強大支撐下，數字化實驗室管理系統才能發揮出最大的作用，為師生實驗帶來便利。

Fig.10 Tab page after students log in圖10 學生登錄后Tab 頁面

Fig.11 Tab page after teachers log in圖11 教師登錄后Tab 頁面

Fig.12 Real-time experiment operation page after experiment reservation圖12 預約實驗后實驗實時操作頁面

5 結語

本文針對智慧校園的數字化實驗室，結合云計算與邊緣計算處理的優勢，對實驗室的服務器進行研究，提出一種本地服務器邊緣處理與云服務器云端處理協同的后端服務器架構。在此基礎上，采用高性能的NIO 異步通信框架Netty 開發了系統之間的通信服務器，并基于此對業務需求進行開發。后續還有許多需要繼續探索的地方，尤其是針對本地服務器與云服務器協同的算法進行研究，探索實現兩者協同的最優化。