一种可以跨主机部署的融合型消息总线的制作方法

本发明属于电力数据交换技术，具体涉及一种可以跨主机部署的融合型消息总线。

背景技术：

2018年国家电网公司提出泛在电力物联网的概念，并开始着手打造sg-eiot(electricinternetofthings),通过统一的物联网平台来接入各业务板块的智能物联设备，实现电力系统各环节万物互联。

泛在电力物联网包括感知层、网络层、平台层、应用层结构。其中感知层设备目前主要包括电力采集类电表、集中器，以及电力二次设备涉及的各类终端。进而对终端设备有更多的功能与数据安全相关的需求，新型电力智能终端要求接入物联网平台，需要支持诸如mqtt等物联网协议；而在终端中需要运行多个容器，各容器运行不同的app，彼此不影响。

综合以上情况，需要考虑提供一种可以兼容多种协议的并且可以跨主机分布的数据交换机制。

因此，亟需提供一种可以跨主机部署的融合型消息总线。

技术实现要素：

本发明的目的是提供一种可以跨主机部署的融合型消息总线，适用于电力智能终端内app、物联管理平台以及支持该消息总线的端设备间进行高效数据交换。

为了实现上述目的，本发明采取的技术方案如下：

一种可以跨主机部署的融合型消息总线，消息中心和消息客户端是星型架构，每个消息客户端使用一种适合本身部署环境的消息协议；

同主机内选择使用ipc或upd消息协议，以保障机内交互的高效性；

跨主机时选择使用mqtt或tcp消息协议，以保障跨机交互的可靠性。

作为进一步的优化，所述消息中心包括：

一个mqttbroker，以供使用mqtt协议的消息客户端经消息中心订阅或发布消息；

一个tcpserver，用于tcp协议消息的转发。

作为进一步的优化，ipc和udp监控消息中心对应队列；从队列中收到消息后,读取消息头中目标客户端名称,若目标客户端为消息中心本身，消息中心根据内容执行操作后，从源客户端对应的通道发送响应数据；否则选用目标客户端对应的消息协议发送到目标客户端。

作为进一步的优化，消息中心的初始化过程包括以下步骤：

步骤1）打开tcpserver监听与mqttbroker；

步骤2）初始化各协议通道；

步骤3）对各协议通道队列进行监听。

作为进一步的优化，使用tcp协议的消息客户端向消息中心注册的过程包括以下步骤：步骤1）与消息中心tcpserver建立socket；

步骤2）向消息中心tcpserver发起socket与消息客户端绑定请求；

步骤3）消息中心tcpserver判断消息客户端有效性后确认绑定；

步骤4）向通过tcpserver转发服务向消息中心发送注册请求；

步骤5）消息中心通过tcpserver转发服务向客户端确认注册请求。

作为进一步的优化，两个使用ipc协议的app之间数据交互的过程包括以下步骤：

步骤1）初始化阶段均创建了与本消息客户端名称有关联的消息队列；

步骤2）app1根据目标消息的消息客户端名称app2查找到对应队列；

步骤3）app1向查找到的app2对应ipc队列写入发送数据；

步骤4）app2读取本消息客户端对应ipc队列时，读取到app1发出的数据；

步骤5）app2通过解析消息内容，确认源为app1，app2向app1对应的ipc队列发送确认消息；

步骤6）app1读取本消息客户端对应ipc队列时，读取到app2发出的确认信息。

作为进一步的优化，一个使用tcp协议的app1与使用mqtt协议的app2之间的数据交换过程包括以下步骤：

步骤1）app1向tcpserver发送消息内容；

步骤2）tcpserver查询是否有app2绑定socket以确认app2是否支持tcp协议；

步骤3）tcpserver发现app2不支持tcp协议消息，将消息内容转发到消息中心客户端；

步骤4）消息中心通过分析消息目标名称，获取消息类型为mqtt；

步骤5）消息中心通过查找注册的mqtt消息客户端，确认目标客户端为app2；

步骤6）消息中心向mqttbroker发布app2主题消息内容；

步骤7）app2收到mqttbroker推送的app2主题消息内容；。

步骤8）app2处理消息内容后确认源队列为app1;

步骤9）通过对app1队列名称判断去人app1不支持mqtt；

步骤10）app2向mqttbroker发布消息中心主题消息内容；

步骤11）消息中心收到mqttbroker推送主题消息；

步骤12）消息中心通过对消息内容分析，确认目标队列为app1；

步骤13）消息中心确认目标队列app1使用协议为tcp；

步骤14）消息中心向tcpserver转发消息内容；

步骤15）tcpserver将消息内容转发到app1对应socket；

步骤16）app1收到消息响应。

作为进一步的优化，ipc协议客户端名称第一个字符为字母;udp协议客户端名称第一个字符为’$’。

作为进一步的优化，tcp协议客户端第一个字符为’/’；mqtt协议客户端名称第一关字符为’@’。

作为进一步的优化，消息中心名称固定为”smimc”。

与现有技术相比，本发明所取得的有益效果如下：

1）本发明设计的消息总线可以跨主机分布,可以简化与末端设备的交换流程。

2）本发明设计的消息总线可以根据app部署环境选择协议类型，兼顾效率与可靠性。

附图说明

附图1是本发明的架构图；

附图2是本发明消息中心架构；

附图3是本发明消息中心初始化过程示例图；

附图4是客户端（tcp）消息队列注册过程示例图；

附图5是同种协议（mqtt）消息发送示例图；

附图6是同种协议（ipc）消息发送示例图；

附图7是异种协议(tcp->mqtt)消息发送示例图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本申请及其应用或使用的任何限制。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

在本申请的描述中，需要理解的是，方位词如“前、后、上、下、左、右”、“横向、竖向、垂直、水平”和“顶、底”等所指示的方位或位置关系通常是基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，在未作相反说明的情况下，这些方位词并不指示和暗示所指的装置或元件必须具有特定的方位或者以特定的方位构造和操作，因此不能理解为对本申请保护范围的限制；方位词“内、外”是指相对于各部件本身的轮廓的内外。

为了便于描述，在这里可以使用空间相对术语，如“在……之上”、“在……上方”、“在……上表面”、“上面的”等，用来描述如在图中所示的一个器件或特征与其他器件或特征的空间位置关系。应当理解的是，空间相对术语旨在包含除了器件在图中所描述的方位之外的在使用或操作中的不同方位。例如，如果附图中的器件被倒置，则描述为“在其他器件或构造上方”或“在其他器件或构造之上”的器件之后将被定位为“在其他器件或构造下方”或“在其他器件或构造之下”。因而，示例性术语“在……上方”可以包括“在……上方”和“在……下方”两种方位。该器件也可以其他不同方式定位(旋转90度或处于其他方位)，并且对这里所使用的空间相对描述作出相应解释。

此外，需要说明的是，使用“第一”、“第二”等词语来限定零部件，仅仅是为了便于对相应零部件进行区别，如没有另行声明，上述词语并没有特殊含义，因此不能理解为对本申请保护范围的限制。

如图1所示，消息中心和消息客户端是星型架构，每个消息客户端可以选择使用一种适合本身部署环境的消息协议，同主机内可以选择使用诸如ipc等高效的消息协议，跨主机时选择mqtt或tcp可以保障交互的可靠性。

其中，app启动时将选用的本app消息队列注册到消息中心,队列名称前缀与协议通过特定规范绑定；

app发送消息时，根据目标app消息队列名判断直接发送到消息中心转发或直接发送；

消息中心收到消息时，根据目标队列名称来选择目标队列支持的协议进行转发；

app关闭时将本app消息队列从消息中心卸载。

如图2所示，消息中心中包括一个mqttbroker，可供使用mqtt协议的消息客户端已经消息中心订阅、发布消息；同样提供了一个tcpserver用于tcp协议消息的转发；而ipc和udp只需要监控消息中心对应队列即可。从队列中收到消息后,读取消息头中目标客户端名称,若目标客户端为消息中心本身，消息中心根据内容执行操作后，从源客户端对应的通道发送响应数据；

否则选用目标客户端对应的消息协议发送到目标客户端。

如图3所示，给出了消息中心初始化过程：

步骤1）打开tcpserver（tcp转发服务）监听与mqttbroker；

步骤2）初始化各协议通道；

步骤3）对各协议通道队列进行监听；

如图4所示，给出了使用tcp协议的消息客户端向消息中心注册的过程：

步骤1）与消息中心tcpserver建立socket；

步骤2）向消息中心tcpserver发起socket与消息客户端绑定请求；

步骤3）消息中心tcpserver判断消息客户端有效性（客户端名称应符合规范）后确认绑定；

步骤4）向通过tcpserver转发服务向消息中心发送注册请求；

步骤5）消息中心通过tcpserver转发服务向客户端确认注册请求；

通过以上步骤可知消息中心的tcpserver的主要功能是tcp消息的转发；

如图5所示，给出了两个使用mqtt协议的app之间数据交互的过程：

步骤1）初始化阶段均向mqttbroker订阅了本消息客户端主题的内容；

步骤2）app1向mqttbroker发布app2主题的消息；

步骤3）app2收到mqttbroker推送消息；

步骤4）app2通过解析消息内容，确认源为app1，app2向mqttbroker发布app1主题的确认消息；

步骤5）app1收到mqttbroker推送的消息。

以上步骤是两个mqtt客户端之间一次完整的同步消息收发过程。

如图6所示，给出了两个使用ipc协议的app之间数据交互的过程：

步骤1）初始化阶段均创建了与本消息客户端名称有关联的消息队列；

步骤2）app1根据目标消息消息客户端名称（app2）查找到对应队列；

步骤3）app1向查找到的app2对应ipc队列写入发送数据；

步骤4）app2读取本消息客户端对应ipc队列时，读取到app1发出的数据；

步骤5）app2通过解析消息内容，确认源为app1，app2向app1对应的ipc队列发送确认消息；

步骤6）app1读取本消息客户端对应ipc队列时，读取到app2发出的确认信息；。

以上步骤是两个ipc消息客户端之间一次完整的同步消息收发过程。

如图7所示，给出了一个使用tcp协议的app1与使用mqtt协议的app2之间的数据交换过程：

步骤1）app1向tcpserver发送消息内容；

步骤2）tcpserver查询是否有app2绑定socket以确认app2是否支持tcp协议；

步骤3）tcpserver发现app2不支持tcp协议消息，将消息内容转发到消息中心客户端；

步骤4）消息中心通过分析消息目标名称，获取消息类型为mqtt；

步骤5）消息中心通过查找注册的mqtt消息客户端，确认目标客户端为app2；

步骤6）消息中心向mqttbroker发布app2主题消息内容；

步骤7）app2收到mqttbroker推送的app2主题消息内容；。

步骤8）app2处理消息内容后确认源队列为app1；

步骤9）通过对app1队列名称判断去人app1不支持mqtt；

步骤10）app2向mqttbroker发布消息中心主题消息内容；

步骤11）消息中心收到mqttbroker推送主题消息；

步骤12）消息中心通过对消息内容分析，确认目标队列为app1；

步骤13）消息中心确认目标队列app1使用协议为tcp；

步骤14）消息中心向tcpserver转发消息内容；

步骤15）tcpserver将消息内容转发到app1对应socket；

步骤16）app1收到消息响应。

以上步骤是一个使用tcp协议消息客户端和使用mqtt消息客户端之间一次完整的同步消息收发过程。

为便于实现，消息队列的命名需遵循一定规则，例如：

ipc协议客户端名称第一个字符为字母；

udp协议客户端名称第一个字符为’$’；

tcp协议客户端第一个字符为’/’；

mqtt协议客户端名称第一关字符为’@’；

5）消息中心名称固定为”smimc”。

本发明可跨主机部署融合型消息总线特点，如下：

1.消息总线可以跨主机部署。

2.消息总线有一个消息中心，并支持多个客户端。

3.消息总线支持多种异构消息协议（包括不限于ipc/tcp/udp/mqtt）进行协议无关的数据交互。

4.支持客户端根据部署环境选择对应的消息协议，创建特定消息队列并

注册到消息中心。

5.本发明的技术核心端是消息中心对客户端注册的消息队列的管理。

以上所述实例表达了本发明的优选实施例，描述内容较为详细和具体，但并不仅仅局限于本发明；特别指出的是，对于本领域的研究人员或技术人员来讲，在不脱离本发明的结构之内，系统内部的局部改进和子系统之间的改动、变换等，均属于本发明的保护范围之内。