祝 鳴, 沈建華, 汪家財(cái)

（華東師范大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院, 上海 200062）

0 引 言

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

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

在嵌入式系統(tǒng)課程實(shí)踐教學(xué)中, 我們發(fā)現(xiàn)構(gòu)建一個可擴(kuò)展的物聯(lián)網(wǎng)開發(fā)管理體系, 能夠極大地滿足目前高校對于物聯(lián)網(wǎng)實(shí)踐的多樣化和學(xué)生工程應(yīng)用培養(yǎng)的需求[4]. 本文的主要工作有以下兩個方面.

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

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

1 物聯(lián)網(wǎng)系統(tǒng)整體架構(gòu)

在嵌入式實(shí)踐教學(xué)的背景下, 我們需要先分析物聯(lián)網(wǎng)開發(fā)教學(xué)平臺的需求, 才能更恰當(dāng)?shù)靥岢鲈撓到y(tǒng)的整體架構(gòu)設(shè)計(jì).

1.1 系統(tǒng)整體需求分析

目前, 國內(nèi)高校的嵌入式實(shí)踐教學(xué)存在著很多局限性, 下面將從學(xué)生和教師這兩個主體來說明.面向教師這一主體, 教師需要耗費(fèi)大量精力進(jìn)行設(shè)備管理、作業(yè)管理和實(shí)驗(yàn)評估工作. 面向?qū)W生這一主體, 現(xiàn)有的嵌入式實(shí)踐教學(xué)一般都是根據(jù)教材的章節(jié)內(nèi)容來設(shè)置對應(yīng)的實(shí)驗(yàn)內(nèi)容, 呈現(xiàn)出分散碎片化的特點(diǎn), 前后關(guān)聯(lián)性較小, 不利于學(xué)生對知識的融會貫通. 另外, 教學(xué)實(shí)驗(yàn)平臺往往僅支持實(shí)現(xiàn)嵌入式開發(fā)的幾種功能, 可擴(kuò)展性比較差, 限制了學(xué)生們的創(chuàng)新能力和個性化發(fā)展. 這些局限性向我們提出了實(shí)現(xiàn)物聯(lián)網(wǎng)開發(fā)教學(xué)管理系統(tǒng)的訴求. 系統(tǒng)的整體需求如下.

(1)硬件端. 我們需要感知器件能夠通過網(wǎng)絡(luò)接入阿里云物聯(lián)網(wǎng)平臺, 并且能夠與該云平臺進(jìn)行基于通信協(xié)議的數(shù)據(jù)交互. 面向?qū)W生這一用戶角色, 他們在將硬件設(shè)備聯(lián)網(wǎng)之后, 將采集到的數(shù)據(jù)上傳至ilop, ilop充當(dāng)?shù)谌街虚g件, 再對該上報數(shù)據(jù)進(jìn)行后續(xù)處理.

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

1.2 系統(tǒng)整體架構(gòu)設(shè)計(jì)優(yōu)化

物聯(lián)網(wǎng)系統(tǒng)的傳統(tǒng)3層架構(gòu)包括感知層、網(wǎng)絡(luò)層和應(yīng)用層. 結(jié)合物聯(lián)網(wǎng)教學(xué)開發(fā)平臺的整體需求,本文提出了更為優(yōu)化的云管端整體架構(gòu), 詳見圖1.

圖 1 物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)整體架構(gòu)Fig. 1 Architecture of the Internet of things teaching development system

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

(2)網(wǎng)絡(luò)層. 網(wǎng)絡(luò)層主要指物聯(lián)網(wǎng)網(wǎng)關(guān), 感知層的數(shù)據(jù)通過網(wǎng)關(guān)來保證穩(wěn)定并可靠地傳輸?shù)皆粕?并且依賴于規(guī)定好的網(wǎng)絡(luò)管理協(xié)議, 應(yīng)用層通過網(wǎng)關(guān)能夠間接地控制感知層的狀態(tài)以及展示相關(guān)信息[7].

(3)平臺層. 本文對物聯(lián)網(wǎng)系統(tǒng)傳統(tǒng)的3層架構(gòu)做了優(yōu)化, 抽象出一個平臺層, 它基于HTTP2.0網(wǎng)絡(luò)協(xié)議與阿里云平臺和移動客戶端進(jìn)行通信. 該平臺層基于微服務(wù)架構(gòu)實(shí)現(xiàn), 作為獨(dú)立的服務(wù)器對外提供了統(tǒng)一的標(biāo)準(zhǔn)化接口, 可以二次開發(fā)個性化的物聯(lián)網(wǎng)應(yīng)用.

(4)應(yīng)用層. 物聯(lián)網(wǎng)教學(xué)開發(fā)平臺除了對外提供接口服務(wù), 還具有教學(xué)管理功能, 配合移動客戶端MXLab使用, 能夠?yàn)閷W(xué)生、老師、管理員這3個用戶角色提供賬戶管理、設(shè)備管理、模型管理等完整穩(wěn)定的功能.

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

2 云架構(gòu)相關(guān)設(shè)計(jì)與實(shí)現(xiàn)

為了加速開發(fā)流程, 提高上線迭代速度, 云開發(fā)是必不可少的. 阿里云物聯(lián)網(wǎng)平臺為開發(fā)者提供了云端開發(fā)功能, 包括云端資源服務(wù)、產(chǎn)品管理服務(wù)、物的模型服務(wù)和用戶服務(wù)等支持. 下面分別介紹如何在阿里云服務(wù)的基礎(chǔ)上建立自己的云服務(wù)器, 以及自建云端的業(yè)務(wù)實(shí)現(xiàn)和相關(guān)算法優(yōu)化.

2.1 云架構(gòu)設(shè)計(jì)

目前物聯(lián)網(wǎng)系統(tǒng)的技術(shù)手段很多, 針對繁雜多樣的場景, 各自定義自己的數(shù)據(jù)標(biāo)準(zhǔn), 維護(hù)著各自的數(shù)據(jù), 這些因素限制著物聯(lián)網(wǎng)系統(tǒng)的可擴(kuò)展性. 為了保證系統(tǒng)安全穩(wěn)定的同時, 展現(xiàn)出良好的適應(yīng)性和可擴(kuò)展性, 本文在阿里云物聯(lián)網(wǎng)平臺的基礎(chǔ)上抽象出一個平臺層. 微服務(wù)架構(gòu)的自動化部署、便捷開發(fā)的特性以及面向業(yè)務(wù)拆分應(yīng)用的特點(diǎn), 很適合用于實(shí)現(xiàn)該平臺. 物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)云端架構(gòu)設(shè)計(jì)如圖2所示.

圖 2 云架構(gòu)設(shè)計(jì)Fig. 2 Design of the cloud architecture

2.2 物聯(lián)網(wǎng)教學(xué)開發(fā)平臺實(shí)現(xiàn)與算法優(yōu)化

物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)在阿里云物聯(lián)網(wǎng)平臺之上自建了云服務(wù)平臺(后面簡稱為“教學(xué)開發(fā)平臺”),用于和MXLab移動客戶端通信, 并實(shí)現(xiàn)教學(xué)管理和物聯(lián)網(wǎng)案例開發(fā)兩大業(yè)務(wù)需求. 教學(xué)開發(fā)平臺基于微服務(wù)架構(gòu)實(shí)現(xiàn), 面臨著如何在復(fù)雜的網(wǎng)絡(luò)環(huán)境下實(shí)現(xiàn)負(fù)載均衡的問題, 本文就解決該問題的負(fù)載均衡算法進(jìn)行了深入探討, 提出了一種負(fù)載均衡優(yōu)化算法.

2.2.1 業(yè)務(wù)架構(gòu)

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

圖 3 教學(xué)開發(fā)平臺架構(gòu)Fig. 3 Architecture of the teaching development platform

API網(wǎng)關(guān)提供統(tǒng)一服務(wù)入口, 作為獨(dú)立的多個服務(wù)和UI之間的代理, 讓微服務(wù)對前臺透明. 除此之外, 在服務(wù)網(wǎng)關(guān)中能夠便捷地實(shí)現(xiàn)橫切功能, 例如路由轉(zhuǎn)發(fā)、流量控制, 并且修改其中的過濾邏輯不需要對所有的微服務(wù)進(jìn)行升級, 能夠很好地優(yōu)化系統(tǒng)性能.

前端即訪問層由Web端和移動客戶端組成, 通過Restful風(fēng)格的URL請求訪問后端服務(wù), 本文使用Spring Cloud的zuul組件實(shí)現(xiàn)路由網(wǎng)關(guān).

后端由服務(wù)層和存儲層構(gòu)成. 服務(wù)層的每個子服務(wù)在各自獨(dú)立的進(jìn)程中運(yùn)行, 采用輕量級的Restful通信機(jī)制進(jìn)行服務(wù)之間的溝通, 并且每個服務(wù)能夠被獨(dú)立部署. 服務(wù)治理基于Spring Cloud的Eureka組件實(shí)現(xiàn), 其中, 服務(wù)注冊和發(fā)現(xiàn)由Eureka Server提供, 它將服務(wù)端和客戶端完全解耦, 解決了服務(wù)直接調(diào)用時由于網(wǎng)絡(luò)位置變化帶來的復(fù)雜的配置修改問題; Service Provider服務(wù)提供方將自身服務(wù)注冊到Eureka, 從而向Server提供服務(wù); Service Consumer服務(wù)發(fā)現(xiàn)方從Eureka Server獲取服務(wù)使用. 配置中心基于Spring Cloud Config實(shí)現(xiàn), 提取應(yīng)用程序最初放在本地的配置, 并將其放在中央服務(wù)器上, 以獲得更好的管理、發(fā)布能力. 存儲層基于Spring Data JPA實(shí)現(xiàn)對數(shù)據(jù)庫的訪問,用面向?qū)ο蟮姆绞讲僮麝P(guān)系型數(shù)據(jù)庫的數(shù)據(jù), 簡化數(shù)據(jù)訪問層代碼的編碼. 另外, 整個平臺基于阿里云提供的安全服務(wù)實(shí)現(xiàn)安全防護(hù).

2.2.2 教學(xué)開發(fā)平臺后端實(shí)現(xiàn)

物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)應(yīng)用層業(yè)務(wù)需求主要包括教學(xué)管理和物聯(lián)網(wǎng)案例開發(fā)兩大部分. 詳細(xì)可見1.1章節(jié)部分. 由于篇幅限制, 下面將對教學(xué)管理業(yè)務(wù)中的學(xué)習(xí)管理模塊、設(shè)備管理模塊以及物聯(lián)網(wǎng)案例開發(fā)業(yè)務(wù)中的模型管理模塊、屬性管理模塊的實(shí)現(xiàn)進(jìn)行詳細(xì)說明.

(1)學(xué)習(xí)管理模塊

學(xué)生用戶在注冊并登錄后, 綁定教師以及班級, 可以對本班級布置的作業(yè)進(jìn)行提交并查看作業(yè)分?jǐn)?shù), 作業(yè)可以在規(guī)定時間內(nèi)多次提交, 提交成功會有相關(guān)提示. 教師用戶可以為所帶班級的學(xué)生發(fā)布作業(yè)信息, 審閱學(xué)生提交作業(yè)并批改分?jǐn)?shù); 管理員用戶可以查看作業(yè)提交情況, 但沒有審閱并批改的權(quán)限.

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

圖 4 課外學(xué)習(xí)情況界面Fig. 4 Extracurricular learning situation interface

(2)設(shè)備管理模塊

教師和管理員可以查看權(quán)限內(nèi)的設(shè)備實(shí)時狀態(tài)、最近上線時間、設(shè)備與學(xué)生的綁定關(guān)系, 以及學(xué)生對設(shè)備的具體操作, 如圖6所示. 系統(tǒng)可以實(shí)時監(jiān)控到學(xué)生是否在線, 設(shè)備事件接收類DeviceEventMqReceiver獲得阿里云推送的設(shè)備事件消息后, IoTMessageCodeParse類實(shí)現(xiàn)對推送消息的解析, 例如設(shè)備在線狀態(tài)消息對應(yīng)實(shí)體類ThingStatusPost, 解析出該實(shí)體類的屬性status, 進(jìn)而更新學(xué)生的設(shè)備在線狀態(tài).

(3)模型管理模塊

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

圖 5 課外學(xué)習(xí)情況模塊類圖Fig. 5 Class diagram of extracurricular learning situation module

圖 6 設(shè)備管理界面Fig. 6 Equipment management interface

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

(4)屬性管理模塊

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

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

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

2.2.3 負(fù)載均衡算法優(yōu)化

在微服務(wù)架構(gòu)中存在一個服務(wù)被部署在多臺服務(wù)器上的情況, 當(dāng)多個服務(wù)使用者同時調(diào)用該服務(wù)時, 這些并發(fā)的請求能用一種合理的策略轉(zhuǎn)發(fā)到各臺服務(wù)器上, 我們稱這種策略為負(fù)載均衡策略[9].

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

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

(1)靜態(tài)負(fù)載均衡算法

靜態(tài)負(fù)載均衡算法包括隨機(jī)算法、輪詢算法和加權(quán)輪詢算法.

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

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

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

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

(2)動態(tài)負(fù)載均衡算法

動態(tài)負(fù)載均衡算法中性能較優(yōu)的有最小連接數(shù)算法和最快算法.

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

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

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

(3)基于動靜態(tài)結(jié)合的負(fù)載均衡算法優(yōu)化

靜態(tài)負(fù)載均衡算法的分配策略是事先定好的, 盡管其中代表性的算法“加權(quán)輪詢算法”在實(shí)現(xiàn)分配好的權(quán)重基礎(chǔ)上做了一定的算法優(yōu)化, 但仍然面臨著無法根據(jù)服務(wù)器的實(shí)時負(fù)載調(diào)整權(quán)重的問題.即使能夠保證服務(wù)器每個節(jié)點(diǎn)配置完全相同, 不同的任務(wù)請求也會帶來服務(wù)器負(fù)載的不同. 動態(tài)負(fù)載均衡算法中的最小連接數(shù)算法基于當(dāng)前連接數(shù)這個評價指標(biāo)來衡量服務(wù)節(jié)點(diǎn)當(dāng)前的負(fù)載是不夠全面的, 因?yàn)檫B接數(shù)量的多少并不能完全代表負(fù)載的程度. 最快算法基于響應(yīng)時間來衡量服務(wù)節(jié)點(diǎn)當(dāng)前的負(fù)載是最直接的, 相比較當(dāng)前連接數(shù)更為客觀有效, 但會為服務(wù)器帶來一部分的計(jì)算壓力, 尤其是當(dāng)并發(fā)量突然增大而導(dǎo)致服務(wù)器壓力驟升時.

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

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

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

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

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

3 硬件層設(shè)計(jì)與實(shí)現(xiàn)

物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)的硬件層核心是云端和設(shè)備端的雙向通信技術(shù). 在1.2節(jié)系統(tǒng)整體架構(gòu)設(shè)計(jì)優(yōu)化中介紹過, 硬件設(shè)備基于MQTT協(xié)議和無線局域網(wǎng)接入阿里云物聯(lián)網(wǎng)平臺.

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

下面分別介紹物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng)的硬件層設(shè)計(jì)以及固件端SDK實(shí)現(xiàn).

3.1 硬件設(shè)計(jì)

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

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

圖 11 硬件層設(shè)計(jì)圖Fig. 11 Design of the hardware layer

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

3.2 固件端SDK實(shí)現(xiàn)

為了方便學(xué)生基于教學(xué)開發(fā)平臺快速開發(fā)自己的物聯(lián)網(wǎng)個性化案例, 簡化設(shè)備端的開發(fā)流程, 本文提供了基于MSP432開發(fā)平臺和EMW3080 Wi?Fi模塊的固件端SDK, 在以上模組的基礎(chǔ)上, 依托MXOS (MXCHIP Operating System)進(jìn)行二次開發(fā), 實(shí)現(xiàn)了便捷的配網(wǎng), 數(shù)據(jù)上報以及數(shù)據(jù)解析接口.

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

3.2.1 配網(wǎng)接口

在終端設(shè)備使用MXLab進(jìn)行配網(wǎng)前, 需要硬件設(shè)備已經(jīng)進(jìn)入允許配網(wǎng)狀態(tài).

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

第一步, 通過ilop_set_domain()接口設(shè)置ilop服務(wù)器站點(diǎn).

第二步, 通過emh_ilop_get_key()接口判斷是否已經(jīng)設(shè)置過ilop四元組, 若沒有設(shè)置過, 則通過ilop_set_key()接口進(jìn)行設(shè)置, 否則, 判斷與系統(tǒng)預(yù)留四元組是否匹配, 若匹配, 繼續(xù)進(jìn)行第三步, 否則進(jìn)行重設(shè).

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

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

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

3.2.2 數(shù)據(jù)上報與下發(fā)數(shù)據(jù)解析接口

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

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

當(dāng)有數(shù)據(jù)上報時, 需要將數(shù)據(jù)以JSON格式拼接為AT指令, 并以字符串的形式在超時時間內(nèi)通過UART串口逐字節(jié)發(fā)送出去. 當(dāng)有下發(fā)數(shù)據(jù)時, 會觸發(fā)UART中斷將數(shù)據(jù)接收至緩沖區(qū)內(nèi), 通過結(jié)束標(biāo)志判斷是否接收到一條完整響應(yīng)信息, 并對當(dāng)前響應(yīng)信息做進(jìn)一步處理.

4 實(shí) 驗(yàn)

實(shí)驗(yàn)分為算法測試和系統(tǒng)測試兩部分: 在4.1節(jié)對LA BTF負(fù)載均衡優(yōu)化算法進(jìn)行測試和評估;在4.2節(jié)通過物聯(lián)網(wǎng)案例展示系統(tǒng)在開發(fā)上的可擴(kuò)展性.

4.1 算法測試

測試環(huán)境為3臺Ubantu18.04服務(wù)器, 處理器4核, 運(yùn)行內(nèi)存8 GB, 測試工具采用Apache JMeter Version 5.2.1, 對教學(xué)開發(fā)平臺進(jìn)行負(fù)載均衡優(yōu)化算法測試.

圖 13 配網(wǎng)流程圖Fig. 13 Matching network flowchart

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

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

實(shí)驗(yàn)結(jié)果顯示, 在8 000并發(fā)量以內(nèi)4種算法的運(yùn)行結(jié)果良好, 出錯率為0; SWRR算法在160、1 600低并發(fā)量時相對于RR算法沒有優(yōu)勢, 因?yàn)榧訖?quán)計(jì)算過程帶來了一些時間開銷, 平均響應(yīng)時間為7 ms, 高于RR算法5.67 ms, 并且吞吐量大致相同; 但可以看到, 在8 000較高并發(fā)量時, SWRR算法平均響應(yīng)時間低于RR算法, 帶來了更好的負(fù)載均衡效果. 動態(tài)負(fù)載均衡算法中的BR算法在3組測試中, 平均響應(yīng)時間都低于RR算法和SWRR算法, 吞吐量也高于它們, 因?yàn)樵诜?wù)器性能大致相同的情況下, 連接數(shù)是能很好地體現(xiàn)服務(wù)器的負(fù)載情況的, 并且沒有復(fù)雜計(jì)算帶來的時間開銷. 本文提出的LA BTF算法相比于其他3種代表性算法, 提高了平均響應(yīng)速度和吞吐量, 驗(yàn)證了動靜態(tài)負(fù)載均衡結(jié)合可以在復(fù)雜網(wǎng)絡(luò)環(huán)境中獲得更好的負(fù)載均衡效果這一猜想.

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

表 1 3組對比實(shí)驗(yàn)結(jié)果Tab. 1 Three groups of comparative experimental results

第二部分, 進(jìn)行了1組實(shí)驗(yàn). 新建3個線程組, 線程數(shù)設(shè)定為1 000, 3個線程組內(nèi)分別設(shè)置不同負(fù)載量的HTTP請求, 線程負(fù)載量分別設(shè)定為1、 5、 10, 對平均響應(yīng)時間和吞吐量進(jìn)行測試. 并發(fā)量為16 000, 實(shí)驗(yàn)結(jié)果見表2.

表 2 1組對比實(shí)驗(yàn)結(jié)果Tab. 2 Set of comparative experimental results

實(shí)驗(yàn)結(jié)果顯示, LA BTF算法在高并發(fā)情況下, 出錯率最低, 另外, 由于錯誤率的出現(xiàn), 平均響應(yīng)時間普遍較高.

第三部分, 進(jìn)行了2組實(shí)驗(yàn). 實(shí)驗(yàn)測試目的是驗(yàn)證出現(xiàn)故障節(jié)點(diǎn)時負(fù)載均衡算法的運(yùn)行效果. 第一組實(shí)驗(yàn), 新建3個線程組, 每個線程組的線程數(shù)都設(shè)定為10, 3個組內(nèi)各自設(shè)置不同負(fù)載量的HTTP請求, 線程負(fù)載量分別設(shè)定為1、 5、 10, 對平均響應(yīng)時間和吞吐量進(jìn)行測試. 第二組實(shí)驗(yàn)的線程數(shù)設(shè)定為1 000, 其他設(shè)置不變. 2組實(shí)驗(yàn)并發(fā)量分別為160、16 000, 實(shí)驗(yàn)結(jié)果見表3.

表 3 2組對比實(shí)驗(yàn)結(jié)果Tab. 3 Two groups of comparative experimental results

LA BTF算法的錯誤率相比無故障節(jié)點(diǎn)時相差不大, 算法性能較為穩(wěn)定, 并且相比BR算法, 響應(yīng)速度得到了一定的優(yōu)化, 能在多個服務(wù)器節(jié)點(diǎn)中出現(xiàn)服務(wù)故障節(jié)點(diǎn)時, 及時地將負(fù)載均勻分配到其他節(jié)點(diǎn).

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

4.2 個性化物聯(lián)網(wǎng)案例展示

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

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

學(xué)生基于物聯(lián)網(wǎng)教學(xué)開發(fā)系統(tǒng), 實(shí)現(xiàn)了一個手機(jī)應(yīng)用, 用戶能夠通過該應(yīng)用實(shí)時監(jiān)測到大氣壓、溫度、濕度, 并了解當(dāng)前的體感溫度和合適的穿衣搭配. 設(shè)備端由MSP432 LaunchPad、IoT擴(kuò)展板和GY?BME280?3.3小板組成, 通過將BME280接入IoT擴(kuò)展板, 可以通過I2C接口讀取到大氣壓、溫度和濕度, 并將讀取到的信息組裝成JSON字符串, 向阿里云物聯(lián)網(wǎng)平臺發(fā)送攜帶有JSON字符串的AT指令, 實(shí)現(xiàn)讀取數(shù)據(jù)的上報.

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

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

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

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

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

5 總 結(jié)

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