应用于学生卡系统支持物联网多协议的分布式处理方法

技术领域

本发明涉及物联网技术和分布式数据处理技术，具体涉及一种应用于学生卡系统支持物联网多协议的分布式处理方法。

背景技术

在物联网领域，基于GPS和基站定位的学生卡系统在智慧校园建设中起到越来越重要的作用，这一系统主要由学生卡设备端、小程序端和云端等三端组成。其中C端用户从小程序端和后台用户从PC端向设备发送控制命令(如设置白名单、亲情号、SOS号码、课堂模式、勿扰模式、定位模式、休眠模式和守护模式)是该系统的最核心的功能。

传统的处理方式中，用户PC端或是小程序端下发命令到云端使用的是HTTP协议，云端到学生卡设备使用的是基于TCP协议的netty框架，这种处理方式存在如下缺陷：一、代码耦合性高、可读性差、难以维护；二、只支持单一协议，系统横向伸缩性和扩展性差；三、采用单点部署，命令的执行存在单点故障问题。

发明内容

本发明所要解决的技术问题是：提出一种应用于学生卡系统支持物联网多协议的分布式处理方法，解决学生卡系统中用户向终端下发指令时，设备多指令实现时代码耦合性高、可读性差，只支持单一协议，系统横向扩展和伸缩性差，命令的执行存在单点故障的问题。

本发明解决上述技术问题采用的技术方案是：

应用于学生卡系统支持物联网多协议的分布式处理方法，包括：

S1、用户设置学生卡设备命令；

S2、学生卡设备管理平台收到用户的请求后，根据不同的命令类型标识，触发不同的命令处理器进行相应的数据校验和组装；

S3、根据设备不同的协议类型标识触发不同的协议处理器将命令下发给对应设备。

进一步的，所述学生卡设备管理平台中的主机、netty服务器和MQTT中间件服务器均采用多节点分布式部署。

进一步的，步骤S3中还包括：在触发不同的协议处理器下发命令过程中，每种协议的RPC调用支持分布式的负载均衡处理。

进一步的，该方法还包括步骤：

S4、命令下发完成后，异步等待学生卡设备的响应，若设备在一定时间内未响应，则再次下发命令进行重试操作。

进一步的，步骤S1中，所述用户为家长端用户或者后台用户，家长端用户可通过小程序设置设备命令，后台用户可通过PC端设置设备命令。

进一步的，步骤S3中，所述不同的协议包括TCP长连接协议和MQTT协议。

进一步的，该方法还包括步骤：

S0、学生卡设备管理平台java web服务在启动时，Spring框架的上下文机制将抽象类与对应命令类型的子类缓存到Map集合中，并将协议接口与对应协议类型的实现类缓存到Map集合中。

进一步的，步骤S2中，触发不同的命令处理器进行相应的数据校验和组装，具体包括：

命令处理器调用父类的模板方法，依次执行以下动作：

检查所有指令类型公共数据的完整性；

不同命令类型data数据的必填性和完整性校验；

对data数据中不做任何的处理，直接执行发送命令的动作；

把最新的命令存到设备实时表；

把最新的命令存到历史表；

更新设备的状态相关信息。

进一步的，步骤S3中，根据设备不同的协议类型标识触发不同的协议处理器将命令下发给对应设备，具体包括：

根据不同的协议类型标识获取到对应的协议处理实现类，执行解析来自PC端或是小程序端的数据，按照终端给出的SDK文档对数据格式进行封装，并执行调用SDK接口向对应设备发送命令。

本发明的有益效果是：

本发明提供的处理方法不仅能按照预先设置的约定规则自动匹配不同的命令类型，对模板方法中不同命令相同数据加统一校验规则，利用多态的特性还能很好的支持多种物联网协议(TCP协议和MQTT协议)，多协议的调用采用分布式部署避免了单点故障，从而提高系统的吞吐能力，实现系统的高可用。

附图说明

图1为实施例中的设备命令下发总体流程图。

具体实施方式

本发明旨在提出一种应用于学生卡系统支持物联网多协议的分布式处理方法，解决学生卡系统中用户向终端下发指令时，设备多指令实现时代码耦合性高、可读性差，只支持单一协议，系统横向扩展和伸缩性差，命令的执行存在单点故障的问题。本发明方案通过把抽象类与对应命令类型的子类缓存到Map集合中，并将协议接口与对应协议类型的实现类缓存到Map集合中。在进行命令下发时能按照预先设置的约定规则自动匹配不同的命令类型，对模板方法中不同命令相同数据加统一校验规则，且根据设备不同的协议类型标识触发不同的协议处理器将命令下发给对应设备。此外，学生卡设备管理平台中的主机、netty服务器和MQTT中间件服务器均采用多节点分布式部署，每种协议的调用支持分布式的负载均衡。由此本发明实现了基于模板方法+多态属性+分布式的处理方法。

实施例：

本实施例中，设备命令下发总体流程如图1所示，其主要包括如下过程：

a.家长端用户通过小程序或后台用户通过PC端设置设备命令；

b.学生卡设备管理平台接收到用户的请求后，根据不同的命令类型标识，触发不同的命令处理器handler,每个处理器handler根据自己的交互特性，进行相应的数据校验和组装；

c.为了提高处理终端设备的吞吐性，netty服务器和MQTT中间件服务器均采用多节点分布式部署。利用dubbo调用可以做到负载均衡。

d.每个设备在创建时都会标识厂商类型，不用的厂商选择不同的交互协议(TCP长连接协议和MQTT协议)，根据不同的协议类型标识，触发不同的协议处理器handler，每个处理器handler根据自己的协议特性进行命令的下发。

e.命令下发完成后，异步等待终端的响应(大概响应时间是2s左右)，如果终端未响应状态，待设备上报心跳数据，再次下发命令进行重试操作。

f.用户配置的命令结果和命令的下发动作均在PC端页面或是小程序端可查看，至此，流程结束。

下面分别从对多设备不同命令的解耦、每种命令类型支持多协议、每种协议的RPC调用支持分布式三个层面具体阐述本实施例的具体实施方案：

(1)多设备不同命令的解耦：

①后台java web服务在启动时，Spring框架的上下文机制把抽象类与对应命令类型的子类缓存到Map集合中，便于后续程序根据不同的指令类型执行不同的处理器；

②后台教师用户或是小程序家长用户给已绑定的设备设置命令；

③后台服务器接收到请求后，获取对应命令类型的处理器对象，该处理器对象会调用父类的模板方法，依次会执行：

检查所有指令类型公共数据的完整性；

不同命令类型data数据的必填性和完整性校验；

对data数据中不做任何的处理，直接执行发送命令的动作；

把最新的命令存到设备实时表；

把最新的命令存到历史表；

更新设备的状态相关信息(工作模式)。

(2)每种命令类型支持多协议：

①后台服务在启动时，Spring框架的上下文机制把协议接口与对应协议类型(TCP协议和MQTT协议)的实现类缓存到Map集合中，便于后续程序根据不同的协议类型执行不同处理；

②每个设备在创建时都会标识厂商类型，不用的厂商选择不同的交互协议(TCP长连接协议和MQTT协议)，根据不同的协议类型标识获取到对应的协议处理实现类，执行解析来自PC端或是小程序端的数据，按照终端给出的SDK文档对数据格式进行封装，并执行调用SDK接口发送命令，以亲情号为例介绍转换的数据格式：

③发送完成后，等待终端的异步响应，在1分钟内未给出响应，代表命令发送失败，后台再进行一次重新发送指令的重试操作。

(3)每种协议的RPC调用支持分布式(以netty服务器为例)：

①java服务在启动时,dubbo配置文件中的version取值为当前服务器的ip：port；

②本实施例中，服务器部署架构是2台主机，2台netty服务器，2台EMQ服务器(MQTT协议中间件)，设备在第一次开机时会通过http协议主动连接到主机上，主机会根据2台netty服务器的连接情况，根据选择算法选择连接数少的服务进行连接，连接成功后会告诉终端连接服务器的地址，待后续终端进行数据上报时选择该服务器。同时把每台设备连接的服务器信息记录到本地数据库；

③当用户配置命令下发到终端学生卡设备时，nginx会随机选择一台主机接收到用户的http请求，根据设备的IMEI从数据库表中获取设备连接的是哪台服务器，dubbo会匹配到相应的verison，调用相应的netty服务器进行指令的下发。

综上所述，本实施例实现的基于模板方法+多态属性+分布式的方式能大大的解耦物联网设备支持多命令类型代码的高度耦合性、实现很简单的多协议支持、同时能充分利用服务器资源做到负载均衡，避免系统单点故障、提高系统的吞吐能力，实现系统的高可用。

最后应当说明的是，上述实施例仅是优选实施方式，并不用以限制本发明。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可以做出若干修改，等同替换、改进等，均应包含在本发明的保护范围之内。