一种基于MQTT集群广播数据的系统的制作方法

一种基于mqtt集群广播数据的系统
技术领域
1.本发明涉及mqtt技术领域，尤其涉及一种基于mqtt集群广播数据的系统。


背景技术：

2.mqtt(消息队列遥测传输)是iso标准(iso/iec prf 20922)下基于发布/订阅范式的消息协议。它工作在tcp/ip协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个实现了消息代理(mqtt broker)的消息中间件。mqtt broker也称为mqtt消息服务器，它可以是运行了mqtt消息服务器软件的一台服务器或一个服务器集群。mqtt broker负责接收来自客户端的网络连接，并处理客户端的订阅/取消订阅(subscribe/unsubscribe)、消息发布(publish)请求，同时也会将客户端发布的消息转发给其他订阅者。
3.目前市面上常见开源mqtt broker包括有emq、hivemq、vernemq、activemq、mosquitto等，上述多种mqtt服务对比后的特征和问题分析总结如表1所示。
4.表1 mqtt服务对比结果
5.6.[0007][0008]
通过上表可以看出现有的mqtt服务存在如下问题：
[0009]
1、许可协议：几乎所有的平台，都是apache2.0的许可协议，该协议明确要求需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明，也就是说不可以对产品单独申请知识产权和专利。
[0010]
2、国产与商业化：除emq外，其它几个主流的mqtt服务都是国外产品，这与提倡的国产化融合是相违背的。同时，这些mqtt服务需要商业版才能支持高性能集群，并且商业版也不开源，不开源意味着不能做相关优化或扩展。
[0011]
3、开发语言：部分mqtt服务使用erlang语言开发，这与目前主流平台采用java开发也是不匹配的。
[0012]
4、开发框架：这些mqtt服务都是针对性开发的，不具备其它协议、通讯方式的扩展接入能力。
[0013]
5、性能问题：如果达到数千万级的终端并发接入，需要mqtt每秒近千万级的消息处理能力，但现有的mqtt服务，除少量商业版外，均无法达到该性能指标。
[0014]
6、边缘端融入问题：未来在边缘端应用中，mqtt服务组件，需要能进行边端部署。边缘端需要能采集不同协议设备的数据，暂存数据，再通过统一的协议，向云端转发数据。而现有的mqtt服务，只是针对前置采集开发的，要单独剥离出可供边缘端使用的组件，几乎是不可能的。并且许可协议也不允许这么做。
[0015]
在现有的mqtt集群设计中，最大的问题就是性能问题，即现有的mqtt服务的集群网络结构在性能方面均存在水平扩展问题，几乎所有的mqtt服务集群都是采用网络拓扑结构。不同的mqtt broker实现，只是broker间的传输实现方法不同，其结构如图1所示。
[0016]
在这种结构下，要求每个节点都要保存数据订阅的订阅路由表，终端或者客户端发生断线/重连后，路由表就会发生变化。并且路由表的大小随着终端数量的增加和订阅队列数量的增加，成倍数增长。为了在broker上保存路由表，emqx在4.3版本后，甚至对路由表进行了压缩存储。这就带来复杂程序的处理逻辑，且集群节点必须是有状态节点。
[0017]
数据在达到客户端前，可能需要经过两个broker的节点。如图1所示，终端1的数据要到达客户端2，需要经过broker1和broker4。依次类推，broker1/2/3上的任何终端的数据要到达客户端2，都需要经过broker4。对于broker4这个节点来说，需要处理所有节点的消息，那集群的性能瓶颈就会受限。


技术实现要素：

[0018]
本发明的目的在于提供一种基于mqtt集群广播数据的系统，从而解决现有技术中存在的前述问题。
[0019]
为了实现上述目的，本发明采用的技术方案如下：
[0020]
一种基于mqtt集群广播数据的系统，包括，
[0021]
网络通讯层：基于netty，提供ip协议的tcp/udp，支持服务端和客户端两种模式；同时提供串口通讯的rs232/485支持以及无线的zigbee支持；
[0022]
基础组件层：包括引导程序模块、终端管理模块、权限认证模块、数据桥模块、路由规则模块、路由管理模块；
[0023]
所述引导程序模块用于定义公共的启动器bootstrap，支持tcp、upd、serial的客户端连接和服务端绑定及其运行参数配置项；
[0024]
所述终端管理模块用于定义抽象的终端基类，实现客户端的上下线以及认证管理和缓存功能；
[0025]
所述权限认证模块用于定义抽象的终端认证接口，定义黑名单、客户端有效性、用户密码认证、数据订阅的权限认证的标准接口；用于基于关系库，实现公用的终端认证服务；
[0026]
所述数据桥模块定义标准的数据桥接接口，实现到kafka、jdbc和nosql的数据桥接功能；用于基于关系库，实现数据桥的管理功能；
[0027]
所述路由规则模块用于定义标准的数据路由接口，实现到kafka、jdbc和nosql的数据路由功能；用于基于关系库，实现路由规则的管理功能；支持包括字段选择、公式条件过滤、计算字段在内的路由条件；
[0028]
所述路由管理模块用于提供数据缓冲池，加速消息处理；支持插件模式，实时拔插数据路由规则；采用线程池模式；
[0029]
数据处理层：包括数据桥接模块、数据路由模块、协议解析模块、消息处理模块、配置管理模块、运行监测模块、边缘计算模块、终端联动模块；
[0030]
所述数据桥接模块用于基于具体的协议，实例化通用的数据桥；用于根据业务需求，定义专用的数据桥；
[0031]
所述数据路由模块用于基于具体的协议，实例化数据路由规则，根据业务需求，定义专用的数据路由规则；
[0032]
所述协议解析模块用于定义通用的例如心跳检测、流量控制等处理器；用于根据具体的应用协议，定义标准应用层协议解析器；
[0033]
所述消息处理模块用于根据具体的应用协议，预定义标准消息处理器；
[0034]
所述配置管理模块用于基于关系库，实现包括设备管理、数据桥配置、路由规则配置在内的接口和业务功能；
[0035]
所述运行监测模块用于通过prometheus grafana的方式支持集群指标监控，并通过页面实时展示；集群指标包括节点状态、客户端连接，数据订阅、消息处理速度、线程池状态、缓冲区状态；
[0036]
所述边缘计算模块用于通过第三方注册工具，将broker信息注册上去；能够有效的支持单设备或者跨broker、集群，订阅不同终端的状态，通过配置公式进行计算后，将结果作为控制条件发送到终端；
[0037]
所述终端联动模块用于设备联动；设备间需要通过数据订阅，当被订阅设备状态发生变化时，将变化值发送到订阅终端，由终端自行处理相应动作；
[0038]
数据持久层：包括消息队列模块、ods数仓、客户端订阅模块；
[0039]
所述消息队列模块用于数据传输以及实时传输数据的存储；通过对消息队列基础配置进行设置能够将数据持久化到文件或者数据库以及ods数仓中；
[0040]
所述ods数仓用于持久化消息队列模块中的数据，通过对消息队列模块中数据的存储为后续的仓库层提供准备，为dwd层提供原始数据，减少对业务系统的影响；
[0041]
所述客户端订阅模块用于支持客户端订阅需要的消息队列，通过客户端代码或配置自助实现订阅功能。
[0042]
优选的，系统中数据流转过程为，终端数据通过mqtt集群被采集起来，经过mqtt集群内部的协议解析模块和消息处理模块处理后依次经过数据路由模块以及数据桥接模块输出到mqtt broker中，或进入到已经订阅的客户端，或进入kafka容器和ods数仓中等待数据的进一步处理；
[0043]
在mqtt集群内部，数据能够在边缘计算模块中执行边缘计算，计算过后的结果数据返回到mqtt集群中。
[0044]
优选的，mqtt集群在采集终端数据的时候，每个broker都独立运行，不会互相通信；各个broker之间通过第三方服务进行注册，注册过后能够实现数据的相互订阅；mqtt集群采集的终端数据通过服务队列传输到客户端。
[0045]
本发明的有益效果是：1、通过一个通讯的开发框架，可以适应诸多的协议接入需求。同时该开发框架，还要能适用于边缘端的开发，支持诸如：modbus、dtl645、gdw376、
iec104、bacnet等行业通讯协议，以及其它自定义协议的通讯协议。2、对mqtt集群改进，在mqtt集群中间采用了无状态集群模式，大大提高了维护性能和线性扩展；该集群模式提供了满足数千万级的设备接入和每秒近千万级消息的处理能力，各终端之间能够实现数据的相互订阅。
附图说明
[0046]
图1是现有mqtt服务集群的网络拓扑结构示意图；
[0047]
图2是本发明实施例中系统的结构示意图；
[0048]
图3是本发明实施例中线程池模式的结构示意图；
[0049]
图4是本发明实施例中系统中的数据流转示意图；
[0050]
图5是本发明实施例中无状态集群模式的网络拓扑结构示意图。
具体实施方式
[0051]
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。
[0052]
本实施例中，提供了一种基于mqtt集群广播数据的系统，系统(通讯开发框架)基于java netty进行搭建，netty是现在普遍采用的网络通讯开发程序框架，它提供了异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。如图2所示，该框架包括，
[0053]
1、网络通讯层：基于netty，提供ip协议的tcp/udp，支持服务端和客户端两种模式；同时提供串口通讯的rs232/485支持以及无线的zigbee支持；
[0054]
2、基础组件层：包括引导程序模块、终端管理模块、权限认证模块、数据桥模块、路由规则模块、路由管理模块；
[0055]
(1)所述引导程序模块用于定义公共的启动器bootstrap，支持tcp、upd、serial的客户端连接和服务端绑定及其运行参数配置项；
[0056]
(2)所述终端管理模块用于定义抽象的终端基类，实现客户端的上下线以及认证管理和缓存功能；
[0057]
(3)权限认证模块用于定义抽象的终端认证接口，定义黑名单、客户端有效性、用户密码认证、数据订阅的权限认证的标准接口；用于基于关系库，实现公用的终端认证服务；
[0058]
(4)所述数据桥模块定义标准的数据桥接接口，实现到kafka、jdbc和nosql的数据桥接功能；用于基于关系库，实现数据桥的管理功能；
[0059]
(5)路由规则模块用于定义标准的数据路由接口，实现到kafka、jdbc和nosql的数据路由功能；用于基于关系库，实现路由规则的管理功能；支持包括字段选择、公式条件过滤、计算字段在内的路由条件；
[0060]
(6)路由管理模块用于提供数据缓冲池，加速消息处理；支持插件模式，实时拔插数据路由规则；采用线程池模式，如图3所示；
[0061]
3、数据处理层：包括数据桥接模块、数据路由模块、协议解析模块、消息处理模块、
配置管理模块、运行监测模块、边缘计算模块、终端联动模块；
[0062]
(1)数据桥接模块用于基于具体的协议，实例化通用的数据桥；用于根据业务需求，定义专用的数据桥；
[0063]
(2)数据路由模块用于基于具体的协议，实例化数据路由规则，根据业务需求，定义专用的数据路由规则；
[0064]
(3)协议解析模块用于定义通用的例如心跳检测、流量控制等处理器；用于根据具体的应用协议，定义标准应用层协议解析器(mqtt/modbus等)；
[0065]
(4)消息处理模块用于根据具体的应用协议，预定义标准消息处理器(mqtt/modbus等)；
[0066]
(5)配置管理模块用于基于关系库，实现包括设备管理、数据桥配置、路由规则配置在内的接口和业务功能；
[0067]
(6)运行监测模块用于通过prometheus grafana的方式支持集群指标监控，并通过页面实时展示；集群指标包括节点状态、客户端连接，数据订阅、消息处理速度、线程池状态、缓冲区状态；
[0068]
(7)边缘计算模块用于通过第三方注册工具，将broker信息注册上去；能够有效的支持单设备或者跨broker、集群，订阅不同终端的状态，通过配置公式进行计算后，将结果作为控制条件发送到终端；
[0069]
(8)终端联动模块用于设备联动；设备间需要通过数据订阅，当被订阅设备状态发生变化时，将变化值发送到订阅终端，由终端自行处理相应动作。
[0070]
4、数据持久层：包括消息队列模块、ods数仓、客户端订阅模块。
[0071]
(1)消息队列模块用于数据传输以及实时传输数据的存储(即数据传输通道，实时传输数据的地方)；通过对消息队列基础配置进行设置能够将数据持久化到文件或者数据库以及ods数仓中；
[0072]
(2)ods数仓用于持久化消息队列模块中的数据(即用于做持久化消息队列中数据的容器)，通过对消息队列模块中数据的存储为后续的仓库层提供准备，为dwd(data warehouse details)层提供原始数据，减少对业务系统的影响；
[0073]
(3)客户端订阅模块用于支持客户端订阅需要的消息队列，通过客户端代码或配置自助实现订阅功能。
[0074]
本实施例中，系统中各个模块之间的数据流转关系如图4所示。
[0075]
终端数据通过mqtt集群被采集起来，经过mqtt集群内部的协议解析模块和消息处理模块处理后依次经过数据路由模块以及数据桥接模块输出到mqtt broker中，或进入到已经订阅的客户端，或进入kafka容器和ods数仓中等待数据的进一步处理；
[0076]
在mqtt集群内部，数据能够在边缘计算模块中执行边缘计算，计算过后的结果数据返回到mqtt集群中。
[0077]
本实施例中，借鉴了kafka的集群模式，将mqtt broker设计为无状态集群模式，其结构如图5所示。
[0078]
mqtt集群在采集终端数据的时候，每个broker都独立运行，不会互相通信；各个broker之间通过第三方服务进行注册，注册过后能够实现数据的相互订阅；mqtt集群采集的终端数据通过服务队列传输到客户端。
[0079]
该结构有如下优点：
[0080]
(1)该集群模式结构简单维护性好：对于每一个节点来说，都是一个独立的broker无状态节点，互相都不知道对方的存在。程序的逻辑简单，稳定性更好。
[0081]
(2)该集群模式能够实现线性的水平扩展：集群节点通过第三方服务(例如：redis、nacos、zookeeper等)进行注册，因此可以做到任意的投退节点，而无需任何额外的配置。如果小规模集群或者单节点模式下，甚至注册服务都不需要，客户端直连broker即可。
[0082]
因为每个broker之间无任何的通讯连接和数据传输，因此集群性能可做到线性的水平扩展。
[0083]
由于图1中的集群节点之间没有任何的消息传输，为了客户端能收到所有订阅终端的消息，这就要求客户端连接到所有的节点。
[0084]
如图5所示，为实现动态的集群扩展，可依靠第三方的注册服务，每个broker启动后，自动注册到服务上。客户端定时从注册服务获取broker信息，自动连接/断开broker。在小规模集群或者单节点模式下，无需注册服务，客户端可直连broker。
[0085]
图1中，在集群中，当终端2需要订阅终端1的数据时(设备联动)，是无法获取到从broker2获取到的。在实际业务中，如果broker是在边缘端，如果单个broker，则不存在这种情况。
[0086]
图5中，如果是在云端或者跨边缘端设备联动时，启动边缘计算功能，同时连接到集群的多个broker，甚至跨集群连接。从而实现跨broker、跨集群的设备联动。
[0087]
通过采用本发明公开的上述技术方案，得到了如下有益的效果：
[0088]
本发明提供了一种基于mqtt集群广播数据的系统，通过一个通讯的开发框架，可以适应诸多的协议接入需求。同时该开发框架，还要能适用于边缘端的开发，支持诸如：modbus、dtl645、gdw376、iec104、bacnet等行业通讯协议，以及其它自定义协议的通讯协议。对mqtt集群改进，在mqtt集群中间采用了无状态集群模式，大大提高了维护性能和线性扩展；该集群模式提供了满足数千万级的设备接入和每秒近千万级消息的处理能力，各终端之间能够实现数据的相互订阅。
[0089]
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。