可扩展物联网教学开发系统的设计与实现

祝 鸣, 沈建华, 汪家财

（华东师范大学 计算机科学与技术学院, 上海 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 总 结

在智慧教育的领域中, 物联网教学开发系统为嵌入式实践教学填补了一部分空白. 从系统架构来看, 物联网教学开发系统对传统的系统架构进行了优化, 在云服务端之上抽象出了一个平台层, 能更好地进行教学管理和案例开发任务. 从技术角度来看, 提出了一个优化的负载均衡算法, 经过验证能够使得平台的服务更加稳定并且响应时间更短. 从应用价值来看, 该系统在服务端和设备端都为开发者提供了便捷的接口; 在投入华东师范大学嵌入式课堂教学使用期间, 运行稳定, 学生们应用该系统完成了很多创新性的物联网案例, 切实提高了他们对嵌入式课程的兴趣, 使他们对物联网的通信过程有了更直观和深入的认识.