可擴展物聯網教學開發系統的設計與實現

祝 鳴, 沈建華, 汪家財

（華東師范大學 計算機科學與技術學院, 上海 200062）

0 引 言

物聯網范式正在為世界鋪平道路, 在物聯網世界的美好愿景中, 那些和生活息息相關的對象將會與我們相互連接, 它們與環境交互以收集信息和自動化某些任務[1]. 物聯網中每個應用領域的興起都有各自的驅動力, 如智慧城市的興起得益于交通流量管理和公用事業的需求、互聯建筑的增長是由降低能源成本的迫切需求催化的, 等等[2]; 而在物聯網應用主流領域之外, 其他領域里物聯網應用也占有很大的比例.

以新工科為背景, 高校正在不斷地積極推進嵌入式系統課程實踐教學改革. 目前, 學生缺乏學習自主性、實踐教學體制不夠靈活、實踐內容與行業需求不相適應是專業課程教學實踐中普遍存在的問題[3]. 首先在實踐教學體制方面, 常常重形式而輕教學主體, 嵌入式實踐課量少并且通常晚于理論課,不能起到相輔相成的效果. 在實踐內容方面, 重復性高, 可擴展性差, 沒有考慮到學生的個性化發展要求, 也就使他們喪失了學習的積極性和主觀創新的興趣, 并且和產業脫節嚴重, 不能起到引導他們從工程基礎能力向工程應用能力轉化的作用. 在實踐教學的評價機制上, 學生優秀與否的評判通常被簡化成對其實驗報告的評判, 事實上這樣是很難判斷他們掌握知識的情況和綜合運用能力的.

在嵌入式系統課程實踐教學中, 我們發現構建一個可擴展的物聯網開發管理體系, 能夠極大地滿足目前高校對于物聯網實踐的多樣化和學生工程應用培養的需求[4]. 本文的主要工作有以下兩個方面.

(1)基于微服務架構的可擴展的物聯網開發教學服務端設計. 相比于中心化的ESB (Enterprise Service Bus)架構, 微服務架構能夠很好地解決耦合性強和可擴展性差的問題[5]. 該物聯網開發教學系統的服務端構建在阿里云物聯網平臺(ilop)之上, 基于微服務架構實現了具有故障檢測、鏈路跟蹤、日志分析、權限控制、服務治理、負載均衡和服務降級特性的服務端. 服務端的業務主要是針對學生這個服務主體的教學管理和可擴展物聯網案例開發. 另外, 針對服務端的負載均衡存在的性能提升空間, 提出了一個動靜態結合的優化算法.

(2)基于MQTT (Message Queuing Telemetry Transport)協議和無線局域網通信方案的物聯網固件端SDK設計. 物聯網的近場通信方案有很多種, 與藍牙、ZigBee等通信技術相比, Wi?Fi方案更便捷, 連接速度更快, 并且天然支持TCP/IP, 能直接接入網絡[6]. 該物聯網開發教學系統的固件端設計并實現了外圍感應器件與云平臺進行數據通信的通用數據解析模塊和網絡連接模塊. 針對MSP432 P401R為學生提供了一個物聯網案例開發的固件端模板.

1 物聯網系統整體架構

在嵌入式實踐教學的背景下, 我們需要先分析物聯網開發教學平臺的需求, 才能更恰當地提出該系統的整體架構設計.

1.1 系統整體需求分析

目前, 國內高校的嵌入式實踐教學存在著很多局限性, 下面將從學生和教師這兩個主體來說明.面向教師這一主體, 教師需要耗費大量精力進行設備管理、作業管理和實驗評估工作. 面向學生這一主體, 現有的嵌入式實踐教學一般都是根據教材的章節內容來設置對應的實驗內容, 呈現出分散碎片化的特點, 前后關聯性較小, 不利于學生對知識的融會貫通. 另外, 教學實驗平臺往往僅支持實現嵌入式開發的幾種功能, 可擴展性比較差, 限制了學生們的創新能力和個性化發展. 這些局限性向我們提出了實現物聯網開發教學管理系統的訴求. 系統的整體需求如下.

(1)硬件端. 我們需要感知器件能夠通過網絡接入阿里云物聯網平臺, 并且能夠與該云平臺進行基于通信協議的數據交互. 面向學生這一用戶角色, 他們在將硬件設備聯網之后, 將采集到的數據上傳至ilop, ilop充當第三方中間件, 再對該上報數據進行后續處理.

(2)軟件端. 應用層由物聯網教學開發平臺Web端和MXLab移動客戶端組成. 業務需求主要分為兩大模塊, 即教學管理和物聯網案例開發. MXLab移動客戶端需要實現學生個人信息管理、 教師綁定、班級綁定、設備管理、案例界面展示等功能. 物聯網教學開發平臺是建立在阿里云物聯網平臺上的服務器端, 需要實現學生、教師、管理員這3個不同角色的功能. 針對學生角色, 需要實現個人賬戶管理、 作業管理、案例模型管理、協議屬性查看等功能; 針對教師角色, 需要實現個人賬戶管理、班級管理、學生管理、設備狀態查看、學習情況采集等功能; 針對管理員角色, 需要實現個人賬戶管理、教師管理、 班級管理、學生管理、設備管理、協議屬性管理、作業管理等功能.

1.2 系統整體架構設計優化

物聯網系統的傳統3層架構包括感知層、網絡層和應用層. 結合物聯網教學開發平臺的整體需求,本文提出了更為優化的云管端整體架構, 詳見圖1.

圖 1 物聯網教學開發系統整體架構Fig. 1 Architecture of the Internet of things teaching development system

(1)感知層. 感知層采集數據, 學生可以針對自己物聯網案例的需求選用合適的傳感器件, 通過工具板與EMW3080 Wi?Fi模塊將設備端連接至網絡. 該物聯網系統可以靈活地適配各種常用的嵌入式微控制器工具板, 如Arduino開發工具板、MSP432 P401R等. 在實驗案例展示部分, 將以MSP432 P401R為例. 感知層設備基于MQTT協議通過無線局域網(如Wi?Fi、 手機熱點)與ilop進行通信.

(2)網絡層. 網絡層主要指物聯網網關, 感知層的數據通過網關來保證穩定并可靠地傳輸到云上,并且依賴于規定好的網絡管理協議, 應用層通過網關能夠間接地控制感知層的狀態以及展示相關信息[7].

(3)平臺層. 本文對物聯網系統傳統的3層架構做了優化, 抽象出一個平臺層, 它基于HTTP2.0網絡協議與阿里云平臺和移動客戶端進行通信. 該平臺層基于微服務架構實現, 作為獨立的服務器對外提供了統一的標準化接口, 可以二次開發個性化的物聯網應用.

(4)應用層. 物聯網教學開發平臺除了對外提供接口服務, 還具有教學管理功能, 配合移動客戶端MXLab使用, 能夠為學生、老師、管理員這3個用戶角色提供賬戶管理、設備管理、模型管理等完整穩定的功能.

該系統完整的數據流通有兩個方向, 即數據的上報和下發通路. 當數據上報時, 傳感器件通過UART串口、I2C接口等將數據以JSON格式傳輸給EMW3080模塊, 然后EMW3080基于MQTT協議將數據上發至云平臺, 云平臺將數據轉發至移動客戶端MXLab, 移動客戶端會根據學生自己定制的H5界面功能來對數據做相應的個性化展示. 當數據下發時, 移動客戶端在定制H5界面做出某些操作來遠程控制設備端, App端會以JSON格式將設備狀態改變信息下發至云平臺, 云平臺將數據傳輸至設備端, 進而設備端做出相應的改變.

2 云架構相關設計與實現

為了加速開發流程, 提高上線迭代速度, 云開發是必不可少的. 阿里云物聯網平臺為開發者提供了云端開發功能, 包括云端資源服務、產品管理服務、物的模型服務和用戶服務等支持. 下面分別介紹如何在阿里云服務的基礎上建立自己的云服務器, 以及自建云端的業務實現和相關算法優化.

2.1 云架構設計

目前物聯網系統的技術手段很多, 針對繁雜多樣的場景, 各自定義自己的數據標準, 維護著各自的數據, 這些因素限制著物聯網系統的可擴展性. 為了保證系統安全穩定的同時, 展現出良好的適應性和可擴展性, 本文在阿里云物聯網平臺的基礎上抽象出一個平臺層. 微服務架構的自動化部署、便捷開發的特性以及面向業務拆分應用的特點, 很適合用于實現該平臺. 物聯網教學開發系統云端架構設計如圖2所示.

圖 2 云架構設計Fig. 2 Design of the cloud architecture

2.2 物聯網教學開發平臺實現與算法優化

物聯網教學開發系統在阿里云物聯網平臺之上自建了云服務平臺(后面簡稱為“教學開發平臺”),用于和MXLab移動客戶端通信, 并實現教學管理和物聯網案例開發兩大業務需求. 教學開發平臺基于微服務架構實現, 面臨著如何在復雜的網絡環境下實現負載均衡的問題, 本文就解決該問題的負載均衡算法進行了深入探討, 提出了一種負載均衡優化算法.

2.2.1 業務架構

教學開發平臺的前端基于HTML+CSS+JS (JavaScript)體系實現, 并且使用了JS開源框架React.React從2013年由Facebook開源以來, 已經發展為view層實現的主流框架之一, 它高效靈活, 能夠使代碼更容易得到復用. 另外, 前端樣式基于Bootstrap開源框架實現響應式布局. 后端基于Spring Boot和Spring Cloud實現微服務架構, 微服務架構將整個系統拆分成多個獨立的服務, Spring Cloud作為一種服務治理的框架, 對整個系統進行全局的監控協調, 而每個獨立的服務由Spring Boot構成[8].數據庫使用MySQL關系型數據庫, 并采用NoSQL型數據庫Redis輔助進行內容緩存, 以及應對大量數據場景下的高訪問負載, 提高數據庫讀寫性能. 教學開發平臺的整體架構如圖3所示.

圖 3 教學開發平臺架構Fig. 3 Architecture of the teaching development platform

API網關提供統一服務入口, 作為獨立的多個服務和UI之間的代理, 讓微服務對前臺透明. 除此之外, 在服務網關中能夠便捷地實現橫切功能, 例如路由轉發、流量控制, 并且修改其中的過濾邏輯不需要對所有的微服務進行升級, 能夠很好地優化系統性能.

前端即訪問層由Web端和移動客戶端組成, 通過Restful風格的URL請求訪問后端服務, 本文使用Spring Cloud的zuul組件實現路由網關.

后端由服務層和存儲層構成. 服務層的每個子服務在各自獨立的進程中運行, 采用輕量級的Restful通信機制進行服務之間的溝通, 并且每個服務能夠被獨立部署. 服務治理基于Spring Cloud的Eureka組件實現, 其中, 服務注冊和發現由Eureka Server提供, 它將服務端和客戶端完全解耦, 解決了服務直接調用時由于網絡位置變化帶來的復雜的配置修改問題; Service Provider服務提供方將自身服務注冊到Eureka, 從而向Server提供服務; Service Consumer服務發現方從Eureka Server獲取服務使用. 配置中心基于Spring Cloud Config實現, 提取應用程序最初放在本地的配置, 并將其放在中央服務器上, 以獲得更好的管理、發布能力. 存儲層基于Spring Data JPA實現對數據庫的訪問,用面向對象的方式操作關系型數據庫的數據, 簡化數據訪問層代碼的編碼. 另外, 整個平臺基于阿里云提供的安全服務實現安全防護.

2.2.2 教學開發平臺后端實現

物聯網教學開發系統應用層業務需求主要包括教學管理和物聯網案例開發兩大部分. 詳細可見1.1章節部分. 由于篇幅限制, 下面將對教學管理業務中的學習管理模塊、設備管理模塊以及物聯網案例開發業務中的模型管理模塊、屬性管理模塊的實現進行詳細說明.

(1)學習管理模塊

學生用戶在注冊并登錄后, 綁定教師以及班級, 可以對本班級布置的作業進行提交并查看作業分數, 作業可以在規定時間內多次提交, 提交成功會有相關提示. 教師用戶可以為所帶班級的學生發布作業信息, 審閱學生提交作業并批改分數; 管理員用戶可以查看作業提交情況, 但沒有審閱并批改的權限.

教師和管理員可以通過多個途徑查看學生的課外學習情況, 包括拓展項目完成情況和設備操作記錄, 如圖4所示. 課外學習情況監控的具體實現如圖5所示: 設計1個抽象類BasicConverter;DeviceEventConverter繼承抽象類BasicConverter, 它關聯設備事件類DeviceEvent, 設備事件包含租戶ID (identityID)、設備認證ID (iotID)、屬性ID (propertyID)、設備事件類型 (type)和事件發生時間 (date). 當設備使用者(租戶)在設備端做出操作動作時, 比如打開開關, 阿里云在接收到設備事件的同時, 會將設備事件推送到教學開發平臺云端, 后端設計了一個設備事件接收類DeviceEventMq Receiver, 當獲取阿里云推送的設備事件時, 會增添相應的DeviceEvent記錄.

圖 4 課外學習情況界面Fig. 4 Extracurricular learning situation interface

(2)設備管理模塊

教師和管理員可以查看權限內的設備實時狀態、最近上線時間、設備與學生的綁定關系, 以及學生對設備的具體操作, 如圖6所示. 系統可以實時監控到學生是否在線, 設備事件接收類DeviceEventMqReceiver獲得阿里云推送的設備事件消息后, IoTMessageCodeParse類實現對推送消息的解析, 例如設備在線狀態消息對應實體類ThingStatusPost, 解析出該實體類的屬性status, 進而更新學生的設備在線狀態.

(3)模型管理模塊

物聯網案例開發是該系統的核心功能之一, 已注冊的開發人員在進行物聯網案例的應用層開發時, 根據系統提供的H5 SDK接口設計并編寫H5文件, 主要接口包括document.addEventListener()監聽面板環境初始化和mx.watchDeviceStatus()監控設備上報狀態. 在模型管理模塊中, 開發者上傳自己設計好的前端文件(包含index.html的壓縮包), 上傳成功后, 移動客戶端MXLab會展示相應的前端界面, 如圖7、圖8所示. 教學開發平臺后端中設計了一個FileUtil類實現文件上傳, 并為App端提供了相應接口/deviceApplication/{studentId}/{model}/, App端提供開發者ID即可獲取到對應的模型文件并將其展示出來. 該模塊大大地簡化了物聯網案例前后端的開發流程, 使得軟件端和硬件端的對接工作清晰透明.

圖 5 課外學習情況模塊類圖Fig. 5 Class diagram of extracurricular learning situation module

圖 6 設備管理界面Fig. 6 Equipment management interface

圖 7 H5文件提交界面Fig. 7 Submission interface for H5 files

(4)屬性管理模塊

物聯網教學管理系統為開發者制定了通信協議, 開發者需要以規定的協議格式{“protocal”:{“property_1”:value_1,“property_2”:value2,......}}上傳JSON類型的消息數據, 可用的屬性列表可以在屬性管理模塊中查看, 如圖9所示. 除了現有可用屬性, 開發人員可以根據物聯網案例的需要在規定協議內自由定制屬性, 軟件端與硬件端使用統一的定制屬性進行通信, 靈活高效. 管理員具有查看、添加、修改或刪除屬性的權限, 如圖10所示.

圖 8 MXLab測試界面Fig. 8 Test interface of MXLab

圖 9 屬性列表界面Fig. 9 Property list interface

2.2.3 負載均衡算法優化

在微服務架構中存在一個服務被部署在多臺服務器上的情況, 當多個服務使用者同時調用該服務時, 這些并發的請求能用一種合理的策略轉發到各臺服務器上, 我們稱這種策略為負載均衡策略[9].

負載均衡是應對高并發場景、進行服務端擴容和緩解網絡壓力的重要手段之一, 可以在軟件端或者硬件端進行, 本文主要關注軟件端. 軟件端負載均衡可以分為服務端負載均衡和客戶端負載均衡[10].由于本文采用Spring Cloud框架實現微服務架構, 客戶端節點能夠便捷地從Eureka服務注冊中心獲取服務端清單, 所以我們采用客戶端負載均衡策略, 配合服務注冊中心, 做出智能高效的特定于應用程序的負載平衡決策. 下面對幾種負載均衡算法進行對比, 分析比較各種算法的優缺點, 并對現有的負載均衡算法提出優化.

圖 10 屬性管理界面Fig. 10 Property management interface

(1)靜態負載均衡算法

靜態負載均衡算法包括隨機算法、輪詢算法和加權輪詢算法.

隨機算法. 隨機算法采用隨機選擇的策略, 具體實現方式是使用隨機對象每次生成一個小于等于服務實例總數的隨機數, 并使用該數索引獲得一個服務實例. 隨機算法有時候也能獲得好的結果, 比如服務器的配置和性能比較均衡時. 它的缺陷是沒有考慮服務器實際的連接數和系統當前負載[11].

輪詢(Round?Robin, RR)算法. 輪詢算法采用循環嘗試的策略, 具體實現方式是設置一個計數器,限制嘗試次數為10次, 每次對計數器加一并且對服務器清單中的服務器數量取模, 選中獲取到的下標對應的服務器[12]. 當服務器的性能相差不大, 并且不同任務的請求帶來的負載大致相同時, 這種算法的效果不算太差. 但是可以預想的是存在木桶效應, 即如果某臺服務器的處理速度、連接速度或者內存性能比較差, 轉發到這個比較慢的服務提供者的請求就會不斷累積, 那么效果會打折扣.

加權輪詢(Weighted Round?Robin, WRR)算法. 加權輪詢算法在輪詢的基礎上稍作改進, 為每臺服務器分配一個權重. 具體實現方式是根據每臺服務器的配置高低分配不同的權重, 在此基礎上以某種方式輪詢, 平滑加權輪詢(Smooth Weighted Round?Robin, SWRR)算法具體實現方式如算法1偽代碼. 它的優點是可以使性能好的服務器得到更高的利用, 集群性能得到最大化, 并且與普通加權輪詢算法手動設置權重基數不同的是, 平滑加權輪詢算法借由有效權重(Efficient Weight)對不同服務器的權重進行調控, 使得服務器的選擇更加平滑, 避免了某臺服務器壓力突然升高[13]. 它的缺陷是根據服務器的配置進行權重分配畢竟無法人為精確估算, 難以應對復雜的實際生產環境. 比如, 當配置高的服務器已經負載了很多請求時, 其處理能力可能下降, 但仍舊更傾向于向它分配請求, 不能動態地根據當前負載情況進行調控.

算法1 平滑加權輪詢(SWRR)算法輸入: 服務器集合S = {S0, S1, S2, · ··, Sn}, 節點默認權重W = {W0, W1, W2, · ··, Wn}, 節點當前權重WC = {WC,0,WC,1, WC,2, · ··, WC,n}, 節點有效權重WE = {WE,0, WE,1, WE,2, · ··, WE,n}輸出: 選中的服務器節點1: 初始化WE = W = {W0, W1, W2, · ··, Wn}, WC = {0, 0, 0, · ··, 0}2: 輪詢所有服務器節點, 計算當前狀態下所有節點的WE之和, 保存為WT 3: 更新所有節點的WC值, WC,i = WC,i–1 + WE,i–1, 其中, i為節點下標; 選出WC值最大的一個節點作為選中節點4: 更新選中節點的WC值, WC = WC – WT 5: 在釋放后端時, 如果發現和后端的通信過程中發生了錯誤, WE減1. 此后有新的請求過來時, 并成功選取本節點,則WE加1 6: 重復進行2到5過程

(2)動態負載均衡算法

動態負載均衡算法中性能較優的有最小連接數算法和最快算法.

最小連接數(Best Available Rule, BR)算法. 該算法首先通過熔斷時間戳判斷服務器是否處于熔斷狀態, 排除失效的服務器, 在此基礎上, 選擇并發數最小的服務器. 該算法的優點是基于服務器當前狀態動態地將請求分流到相對較為空閑的服務器, 合理高效. 但當集群中的每臺服務器的運算能力不均衡時, 會對該算法的效果有一定影響[14].

最快(Fastest Rule, FR)算法. 最快算法也稱為響應權重算法, 該算法的思想是根據服務器的平均響應時間為它們分配一個權重, 服務器的響應時間越短, 相應的權重越大, 被選中的概率也越大. 具體實現如算法2偽代碼, 計算得到的最終權重值WF,i決定了在[0, MTW]區間內所占比重大小, 所占比重越大, 那么隨機數R落到相應范圍的概率越大, 進而該節點更容易被選中. 該算法在服務器跨不同的網絡環境時表現優異, 動態實時. 缺點是復雜度比較高, 響應時間以及權重的計算占用一定的服務器資源.

算法2 最快(FR)算法···, ···,···,輸入: 服務器集合S = {S0, S1, S2, Sn}, 節點權重列表WF = {WF,0, WF,1, WF,2, WF,n}, 節點平均響應時間tRTA = {tRTA,0, tRTA,1, tRTA,2, tRTA,n}輸出: 選中的服務器節點1: 啟動定時任務, 每隔30 s更新一次所有服務器節點的權重值WF, 即進行2到4步驟n∑i=0 tRTA,i 2: 計算所有實例的平均響應時間的總和tTRT, tTRT =3: 計算每個實例的權重WF, WF,i = WF,i–1 + tTRT – tRTA,i, 其中, WF,0 = tTRT – tRTA,0 4: 記WF,n–1為MTW, 依次遍歷節點權重列表, 對于當前節點i, 在[0, MTW]范圍內取一個隨機數R. 比較R與WF,i的大小, 若R ≤ WF,i, 則選中當前節點i; 否則i++, 繼續比較

(3)基于動靜態結合的負載均衡算法優化

靜態負載均衡算法的分配策略是事先定好的, 盡管其中代表性的算法“加權輪詢算法”在實現分配好的權重基礎上做了一定的算法優化, 但仍然面臨著無法根據服務器的實時負載調整權重的問題.即使能夠保證服務器每個節點配置完全相同, 不同的任務請求也會帶來服務器負載的不同. 動態負載均衡算法中的最小連接數算法基于當前連接數這個評價指標來衡量服務節點當前的負載是不夠全面的, 因為連接數量的多少并不能完全代表負載的程度. 最快算法基于響應時間來衡量服務節點當前的負載是最直接的, 相比較當前連接數更為客觀有效, 但會為服務器帶來一部分的計算壓力, 尤其是當并發量突然增大而導致服務器壓力驟升時.

綜合以上的分析以及教學開發平臺的背景, 考慮如何平衡實時負載的獲取和算法的高效性, 對現有的負載均衡算法進行優化, 本文提出了基于閾值過濾的負載均衡優化算法(Load Balancing Optimization Algorithm Based on Threshold Filtering, LA BTF). 該算法基于最小連接數指標設定閾值, 有選擇地進行權重響應時間算法. 算法的具體實現如算法3偽代碼.

算法3 基于閾值過濾的負載均衡優化算法(LA BTF)···, ···,···,輸 入: 服 務 器 集 合S={S0, S1, S2, Sn}, 計 數 器count=0, index=0, 節 點 權 重 列 表WF={WF,0, WF,1, WF,2,WF,n}, 節點平均響應時間tRTA={tRTA,0, tRTA,1, tRTA,2, tRTA,n}輸出: 選中的服務器實例1: 使用輪詢算法獲得一個服務器實例Si, 當index++＜=10時, 進行下一步驟; 否則跳轉至步驟3

2: 若當前服務實例Si的斷路器未被觸發并且實例的并發請求數小于等于設定閾值, 則count++, 判斷count值是否大于等于3, 若是, 結束循環跳轉至步驟4; 否則, 跳轉至步驟1繼續執行3: 使用最小連接算法選中一個服務器實例4: 啟動定時任務, 每隔30 s更新一次所有服務器節點∑的n權重值WF, 即進行5到7步驟j=0 5: 計算所有實例的平均響應時間的總和tTRT, tTRT=tRTA,j 6: 計算每個實例的權重, WF,j=WF,j–1+tTRT – tRTA,j, 其中, WF,0=tTRT – tRTA,0 7: 記WF,n–1為MTW, 依次遍歷節點權重列表, 對于當前節點j, 在[0, MTW]范圍內取一個隨機數R. 比較R與WF,j的大小, 若R ≤ WF, j, 則選中當前節點j; 否則j++, 繼續比較

使用輪詢算法獲得服務器實例, 并且根據過濾指標判斷當前服務器是否可得, 此時服務器進行的選中是偽選中, 相當于僅僅將成功選中的記錄暫存起來. 另外, 采用增一的簡單輪詢運算幾乎不會帶來時間開銷. 經過多次驗證嘗試, 設定服務器實例驗證次數為10次, 一旦服務器實例成功選中數達到3次, 就會跳出循環, 不再進行服務器實例驗證, 可以保證實時反映當前的網絡環境負載程度.

上述算法的時間和空間復雜度都為O(n). 如果對服務器實例小于等于10次的驗證內3次都通過,我們可以認為當前的網絡環境不太繁忙, 進而采用性能比較好的權重響應時間算法. 否則, 仍舊基于連接數進行負載均衡來簡化算法, 也就是說, 過濾掉那些由于持續的連接故障而標記為熔斷的后端服務器以及高并發的后端服務器. 這種靜態負載均衡和動態負載均衡結合的算法, 既考慮到了系統當前的負載, 又能夠在每個節點負載大致相同時, 不占用太多的服務器資源, 保證系統資源利用的最大化.

3 硬件層設計與實現

物聯網教學開發系統的硬件層核心是云端和設備端的雙向通信技術. 在1.2節系統整體架構設計優化中介紹過, 硬件設備基于MQTT協議和無線局域網接入阿里云物聯網平臺.

MQTT協議是IBM針對物聯網發布的一種基于發布/訂閱范式的“輕量級”消息協議[15]. 作為一種即時通信協議, MQTT不僅低開銷, 而且低帶寬占用, 適用于網絡狀態糟糕的情況以及硬件性能低下的遠程設備. 因此, 它在物聯網(IoT)、小型設備應用、移動應用等方面有較廣泛的應用. 設備與阿里云平臺建立長連接后, 通過MQTT通信接口能夠便捷地進行信息發送和接收. Wi?Fi通信技術遵循國際標準IEEE802.11, 最快速率可達300 MB/s, 最大傳輸距離可達到300 m , 是目前最常用的短距離無線通信技術, 基本能滿足所有短距離無線數據傳輸的需求. Wi?Fi設備內部配置有TCP/IP協議棧,從而消除中間設備的接口轉換步驟, 直接發送和接收Internet數據包.

下面分別介紹物聯網教學開發系統的硬件層設計以及固件端SDK實現.

3.1 硬件設計

基于上述通信方案和網絡協議, 采用TI推出的MSP?EXP432P401R LaunchPad開發套件(下面簡稱為MSP432)進行固件端SDK的開發. 它包含在ARM32位Cortex?M4F 微控制器(MCU)上進行開發所需的全部資源, 其中包括用于編程、調試和能量測量的板載調試探針, 并且具有低功耗特性. 器件的所有引腳以扇形散列排列, 可以便捷地進行連接. 利用40引腳插座和多種BoosterPack?插接模塊, 可以額外增加低功耗藍牙(Bluetooth Low Energy, BLE)和Wi?Fi?無線連接等功能[16]. 除了MSP432, 物聯網教學開發系統也支持其他開發平臺, 如Arduino開發平臺, 只需完成設備端與云平臺的通信線路, 同樣能實現物聯網個性化案例的上傳和展示.

阿里云物聯網平臺支持的通信模組非常多樣, 如iComm的C?8133U模組、Belon的BL7231U模組、MXCHIP的EMW3080模組等, 這些模組都提供Wi?Fi無線連接通信. 本文使用攜載有EMW3080 Wi?Fi的IoT?MSP432擴展板, 基于EMW3080實現的固件端SDK為采集數據的上報、下發數據的解析以及適配網絡提供了統一接口. 硬件層設計如圖11所示.

圖 11 硬件層設計圖Fig. 11 Design of the hardware layer

EMW3080 Wi?Fi模塊支持阿里飛燕ilop云平臺國際站和中國站, 國美云平臺以及杭研云平臺等其他各種智能云端接入協議, 能夠保證端到云連接的快速、穩定和安全. 云端和設備端的通信包括設備端采集數據的上報和云端下發數據的解析. 硬件層的傳感節點層采集數據通過嵌入式平臺層上報至阿里云服務, 后面進行的云平臺與應用層之間的交互在前面的章節中已經討論過, 此處不再贅述.嵌入式平臺層接收到云端下發的JSON格式的數據需要進行解析, 并經過一定的處理邏輯后在設備端展示出來.

3.2 固件端SDK實現

為了方便學生基于教學開發平臺快速開發自己的物聯網個性化案例, 簡化設備端的開發流程, 本文提供了基于MSP432開發平臺和EMW3080 Wi?Fi模塊的固件端SDK, 在以上模組的基礎上, 依托MXOS (MXCHIP Operating System)進行二次開發, 實現了便捷的配網, 數據上報以及數據解析接口.

在整個物聯網案例的設備端固件開發中, 以往初學者需要熟練掌握微控制器(MCU)與外部器件進行數據交互的過程、 時鐘配置, 以及UART串口、SPI和I2C接口的通信原理等; 而使用本文中的硬件端接口, 可以減輕這些底層工作的復雜度和學習成本, 使得開發者可以專注于實現業務邏輯. 為開發者提供的接口如圖12所示.

3.2.1 配網接口

在終端設備使用MXLab進行配網前, 需要硬件設備已經進入允許配網狀態.

emw_runloop(void)接口監聽云連接狀態, 云連接狀態包含4個狀態: ilop_eState_M1_initialize表示模塊初始化狀態; ilop_eState_M2_provision表示等待Wi?Fi配置和云連接狀態; ilop_eState_M3_normal表示正處于云連接狀態; ilop_eState_M4_disconnected表示云連接已斷開. 當監聽到處于模塊初始化狀態, 就進行一系列的操作進入允許配網狀態.

第一步, 通過ilop_set_domain()接口設置ilop服務器站點.

第二步, 通過emh_ilop_get_key()接口判斷是否已經設置過ilop四元組, 若沒有設置過, 則通過ilop_set_key()接口進行設置, 否則, 判斷與系統預留四元組是否匹配, 若匹配, 繼續進行第三步, 否則進行重設.

第三步, 通過ilop_service_start()接口啟動ilop服務.

第四步, 判斷是否已經啟動awss配網模式: 若是, 無須操作; 若沒有, 則通過wlan_get_para()獲取當前配置AP的SSID和密碼. 若獲取失敗, 表示需要進行Wi?Fi配置, 通過ilop_awss_start()接口啟動awss路由配網模式, 并設置狀態為M2; 若獲取成功, 通過接口wlan_get_sta_status()判斷是否已經成功連接云, 若是, 則設置狀態為M3, 否則設置狀態為M4. 配網流程如圖13所示.

圖 12 固件端主要接口Fig. 12 Main interface on the firmware side

3.2.2 數據上報與下發數據解析接口

AT固件是運行于EMW3080 Wi?Fi模塊上的軟件指令系統. 通過發送或者解析AT指令, 能夠快速地為嵌入式設備增加無線通信功能. AT指令格式為AT+〈CMD〉[op][para?1, para?2, para?3,···] ,其中, “AT”是命令消息前綴, 是每條AT指令的固有部分; “CMD”是指令字符串, 指向具體的指令;[op]是指令操作符, 指定指令的具體動作; [para?n]表示設置的參數值或指定查詢的參數; 是回車結束符. AT指令的響應格式為 [ ][+CMD:][para?1, para?2, para?3,···]〈 〉〈STATUS〉〈 〉, 其中, [+CMD:]表示相應的命令字符串, [para?n]表示查詢時返回的參數, 〈STATUS〉表示指令執行成功與否.

AT指令中包含JSON格式的數據信息. parser_send()接口實現了將JSON格式的信息組裝成AT指令字符串上報, parser_recv()接口實現了響應字符串的緩存以及解析, 進而開發者可以根據需求獲取狀態參數或者屬性當前值. 數據上報和下發數據解析流程如圖14所示.

當有數據上報時, 需要將數據以JSON格式拼接為AT指令, 并以字符串的形式在超時時間內通過UART串口逐字節發送出去. 當有下發數據時, 會觸發UART中斷將數據接收至緩沖區內, 通過結束標志判斷是否接收到一條完整響應信息, 并對當前響應信息做進一步處理.

4 實 驗

實驗分為算法測試和系統測試兩部分: 在4.1節對LA BTF負載均衡優化算法進行測試和評估;在4.2節通過物聯網案例展示系統在開發上的可擴展性.

4.1 算法測試

測試環境為3臺Ubantu18.04服務器, 處理器4核, 運行內存8 GB, 測試工具采用Apache JMeter Version 5.2.1, 對教學開發平臺進行負載均衡優化算法測試.

圖 13 配網流程圖Fig. 13 Matching network flowchart

分別對輪詢(RR)算法、平滑加權輪詢(SWRR)算法、最小連接數(BR)算法, 以及本文提出的基于閾值過濾的負載均衡優化算法(LA BTF)進行對比測試, 實驗分為3部分.

第一部分, 進行了3組實驗. 第一組實驗中, 新建3個線程組, 線程數設定為10, 為了模擬教學開發平臺實際使用時不同種類的訪問請求會帶來的不同負載量的情況, 3個線程組內分別設置不同負載量的HTTP請求, 線程負載量分別設定為1、 5、 10, 對平均響應時間和吞吐量進行測試. 第二組、第三組實驗的線程數分別設定為100、 500, 其他設置不變. 3組實驗的并發量分別為160、 1 600、 8 000,實驗結果見表1.

實驗結果顯示, 在8 000并發量以內4種算法的運行結果良好, 出錯率為0; SWRR算法在160、1 600低并發量時相對于RR算法沒有優勢, 因為加權計算過程帶來了一些時間開銷, 平均響應時間為7 ms, 高于RR算法5.67 ms, 并且吞吐量大致相同; 但可以看到, 在8 000較高并發量時, SWRR算法平均響應時間低于RR算法, 帶來了更好的負載均衡效果. 動態負載均衡算法中的BR算法在3組測試中, 平均響應時間都低于RR算法和SWRR算法, 吞吐量也高于它們, 因為在服務器性能大致相同的情況下, 連接數是能很好地體現服務器的負載情況的, 并且沒有復雜計算帶來的時間開銷. 本文提出的LA BTF算法相比于其他3種代表性算法, 提高了平均響應速度和吞吐量, 驗證了動靜態負載均衡結合可以在復雜網絡環境中獲得更好的負載均衡效果這一猜想.

圖 14 數據上報(a)與下發數據解析(b)流程圖Fig. 14 Flowcharts for data reporting (a) and delivery data analysis (b)

表 1 3組對比實驗結果Tab. 1 Three groups of comparative experimental results

第二部分, 進行了1組實驗. 新建3個線程組, 線程數設定為1 000, 3個線程組內分別設置不同負載量的HTTP請求, 線程負載量分別設定為1、 5、 10, 對平均響應時間和吞吐量進行測試. 并發量為16 000, 實驗結果見表2.

表 2 1組對比實驗結果Tab. 2 Set of comparative experimental results

實驗結果顯示, LA BTF算法在高并發情況下, 出錯率最低, 另外, 由于錯誤率的出現, 平均響應時間普遍較高.

第三部分, 進行了2組實驗. 實驗測試目的是驗證出現故障節點時負載均衡算法的運行效果. 第一組實驗, 新建3個線程組, 每個線程組的線程數都設定為10, 3個組內各自設置不同負載量的HTTP請求, 線程負載量分別設定為1、 5、 10, 對平均響應時間和吞吐量進行測試. 第二組實驗的線程數設定為1 000, 其他設置不變. 2組實驗并發量分別為160、16 000, 實驗結果見表3.

表 3 2組對比實驗結果Tab. 3 Two groups of comparative experimental results

LA BTF算法的錯誤率相比無故障節點時相差不大, 算法性能較為穩定, 并且相比BR算法, 響應速度得到了一定的優化, 能在多個服務器節點中出現服務故障節點時, 及時地將負載均勻分配到其他節點.

根據二八原則, 80%的請求集中在20%的時間來計算峰值壓力, 公式為(總PV(Page View)數×80%)/(每天秒數×20%) = 峰值時間每秒請求數(req/sec, QPS). 當每秒的并發量達到10 000時,PV值約為21 600萬次, 也即網站日訪問量大概能承載21 600萬次.

4.2 個性化物聯網案例展示

在2.2.2節簡要介紹了物聯網教學開發系統的教學管理功能: 能夠通過監控學生對設備板的操作行為實時清晰地反映學生的課外學習情況. 這一節主要介紹該系統在嵌入式教學上的成果, 即方便學生快捷地進行個性化物聯網案例的開發. 基于物聯網教學開發系統, 學生主要實現設備端和App端, 利用固件端SDK可以快速完成自己的固件端邏輯, 利用Web端提供的模型上傳可以快速完成前端頁面展示.

4.2.1 IoT體感溫度檢測與穿衣推薦

學生基于物聯網教學開發系統, 實現了一個手機應用, 用戶能夠通過該應用實時監測到大氣壓、溫度、濕度, 并了解當前的體感溫度和合適的穿衣搭配. 設備端由MSP432 LaunchPad、IoT擴展板和GY?BME280?3.3小板組成, 通過將BME280接入IoT擴展板, 可以通過I2C接口讀取到大氣壓、溫度和濕度, 并將讀取到的信息組裝成JSON字符串, 向阿里云物聯網平臺發送攜帶有JSON字符串的AT指令, 實現讀取數據的上報.

App端可以通過教學開發平臺提供的接口與阿里云進行數據交互, 讀取到阿里接收到的大氣壓、溫度和濕度, 顯示在自行設計的H5手機界面上, 計算出體感溫度并給出穿衣推薦. 成果展示如圖15所示.

圖 15 IoT體感溫度檢測與穿衣推薦Fig. 15 IoT somatosensory temperature detection and clothing recommendation

4.2.2 IoT粉塵檢測與空氣凈化自動控制器

學生基于物聯網教學開發系統, 實現了一個手機應用, 用戶可以查看當前環境下的粉塵濃度值,并且達到閾值時自動打開空氣凈化器. 設備端由MSP432 LaunchPad、IoT擴展板和YW?51GJ粉塵傳感器組成, 通過將YW?51GJ接入IoT擴展板, 可以通過UART串口讀取到環境灰塵濃度值, 使用系統提供的固件端接口將讀取到的數據上傳至云端. App端同樣在教學開發平臺的模型管理模塊上傳自己設計的H5界面, 成果展示如圖16所示.

圖 16 IoT粉塵檢測與空氣凈化自動控制器Fig. 16 IoT dust detection and air purification automatic controller

5 總 結

在智慧教育的領域中, 物聯網教學開發系統為嵌入式實踐教學填補了一部分空白. 從系統架構來看, 物聯網教學開發系統對傳統的系統架構進行了優化, 在云服務端之上抽象出了一個平臺層, 能更好地進行教學管理和案例開發任務. 從技術角度來看, 提出了一個優化的負載均衡算法, 經過驗證能夠使得平臺的服務更加穩定并且響應時間更短. 從應用價值來看, 該系統在服務端和設備端都為開發者提供了便捷的接口; 在投入華東師范大學嵌入式課堂教學使用期間, 運行穩定, 學生們應用該系統完成了很多創新性的物聯網案例, 切實提高了他們對嵌入式課程的興趣, 使他們對物聯網的通信過程有了更直觀和深入的認識.