CN112532425A - 一种面向边缘计算的消息路由配置方法 - Google Patents

Abstract

一种面向边缘计算的消息路由配置方法，包括：从路由维度将边缘服务分为路由起点，路由中间节点，路由终节点和独立服务四大类；用户通过可视化连线或编写配置文件的方式开发路由应用，定义应用名称和每个应用对应的服务间数据流转的完整数据链路；后端系统获取到路由应用配置文件后调用路由转换算法，自动生成一组topic和服务维度的发布订阅规则；边缘服务从路由配置文件中读取需要订阅的topic，和发布消息的策略，运行阶段根据消息结构体中的路由应用名称决定发布到哪个topic上。本发明通过配置路由应用的方式降低了开发难度，将路由应用配置转换为服务维度的发布订阅规则，通过合并topic提升系统吞吐量，降低存储开销。

Description

一种面向边缘计算的消息路由配置方法

技术领域

本发明提供一种面向边缘计算的消息路由配置方法，灵活配置传感器数据在边缘服务中的流转。

背景技术

云计算的出现为大数据提供了高效的管理和计算平台，但是目前的网络带宽增长速度远远赶不上数据的增长速度，过长的传输链路会带来较高的延迟以及安全隐患。为了弥补云计算的以上不足，边缘计算应运而生。在边缘计算模型当中，计算资源更加接近数据源，而网络边缘设备已经具有足够的计算能力来实现源数据的本地处理，并将结果发送至云计算中心。这样，不仅仅可以降低网络传输过程当中的带宽压力，加速数据分析处理，同时还能降低终端敏感数据信息隐私泄露的风险。

边缘服务提供设备接入，数据存储，数据处理，数据上云等功能。随着边缘服务越来越多，需要提供一种灵活的消息路由机制，可以动态配置传感器数据在边缘系统中的流转。

现有的消息路由通常由三个基本要素组成：消息来源，消息目标和过滤条件。消息来源指数据流出的服务；消息目标指消息流入的服务；过滤条件用来筛选消息来源流出的数据，可以从多个维度进行过滤，如设备维度，产品维度，消息属性维度。一个消息来源可以根据不同的过滤条件选择流向不同的消息目标。

随着边缘服务和接入设备越来越多，服务之间的数据流转越来越复杂，过滤条件的配置和维护也变得越来越复杂。不同维度的过滤条件可能造成重复或冲突，复杂的过滤条件判断也会降低系统消息流转的吞吐量。

发明内容

本发明要克服现有技术的上述缺点，提供一种简单灵活的消息路由配置方法。

为实现以上目的，本发明所采取的技术方案是：一种面向边缘计算的消息路由配置方法，包括以下步骤：

(1)按路由维度将边缘服务分为路由起点，路由中间节点，路由终节点和独立服务四大类；

(2)用户通过可视化连线或编写配置文件的方式开发路由应用。路由应用由应用名称和数据流转链路两部分组成。应用名称系统内唯一，每个系统可以定义一个名称为“default”的路由应用，表示系统内服务间数据流转的默认路由；数据流转链路标识数据在服务间的流转方向，从路由起点类服务开始指定，流经零个或多个路由中间节点类服务，最终流向路由终节点类服务；

(3)定制系统后端获取到路由应用配置文件后调用路由转换算法，自动生成一组topic，将路由应用翻译成服务维度的发布订阅规则。算法遵从最少topic原则，提升系统吞吐量并降低存储开销；

(4)参与消息路由的服务从路由配置文件中读取当前服务需要订阅的topic，和发布消息的策略，运行阶段根据消息结构体中的路由应用名称决定发布到哪个topic上；

(5)用户为边缘系统添加子设备时，可以将子设备和其中一个路由应用绑定，该设备产生的数据将按照路由应用的数据链路进行流转。如果不指定，则设备产生的数据将按照默认路由的数据链路进行流转。

与现有技术相比，本发明的有益效果是：本发明提出了一种基于路由应用的简单灵活的消息路由配置方法，省去了复杂过滤条件的配置和维护。另外发明提出了一种路由转换算法，将路由应用配置转换为服务维度的发布订阅规则，通过合并topic提升系统吞吐量，降低存储开销。

附图说明

图1是本发明方法通过可视化连线配置路由应用示例图。

图2是本发明方法路由转换算法图。

具体实施方式

本发明提供一种面向边缘计算的消息路由配置方法。具体实施方式如下：

(1)按路由维度将边缘服务分为路由起点，路由中间节点，路由终节点和独立服务四大类；详细分类介绍如下：

1.1)路由起点。消息路由的起始节点，一般为驱动层的设备接入类服务，如MQTT服务。消息来源主要为子设备的传感器数据，服务接收到子设备的数据，将数据转化为在边缘系统中数据流转的标准格式，通过消息路由发布出去供其他服务使用；

1.2)路由中间节点。一般为数据处理类服务，如数据过滤服务。服务依据消息路由订阅感兴趣的数据，处理完之后需要把新的消息发布出去供其他服务使用；

1.3)路由终节点。消息路由的终止节点，如数据存储服务。服务依据消息路由订阅感兴趣的数据，消费完成后的消息不再进行发布；

1.4)独立服务。不参与消息路由的服务，典型服务为restful类服务；

(2)用户通过可视化连线或编写配置文件的方式开发路由应用；路由应用由应用名称和数据流转链路两部分组成，详情如下：

2.1)应用名称系统内部唯一，并且每个系统可以定义一个名称为“default”的路由应用，表示系统内服务间数据流转的默认路由；

2.2)数据流转链路标识数据在服务间的流转方向，必须从路由起点开始指定，可以流经零个或多个路由中间节点，最终流向路由终节点结束。另外需要注意的是，一个路由应用所表示的服务间数据流转仍是多对多的关系，即一个服务的路由出口可以指向多个其他服务的路由入口，一个服务的路由入口可以由多个其他服务的路由出口指向。但和原始消息路由不同的是，路由应用内并非根据过滤条件决定数据流向，如果一个服务指向多个其他服务，表示该服务产生的数据将被这些服务全部消费。同理，如果多个服务指向一个服务，表示这些服务产生的数据都将被这个服务消费；

2.3)用户可以通过可视化或编写配置文件的方式开发路由应用。可视化的方式比较简单，定义应用名称后，通过可视化连线配置服务间数据流转即可，如图1所示。下面主要介绍路由应用配置文件开发语法，可视化的方式最终也会转换为同样的配置文件提交系统处理。

配置文件语法为JSON格式，示例如下所示：

配置文件中的Key标识路由应用名称，为“default”即为默认路由，表示服务间的默认数据流转；否则为应用路由，表示服务间特定的数据流转，优先级高于默认路由。Value字段中，“moduleName”标识当前服务的名称，“next”标识数据流向的下一跳服务，内容为相同语义的JSON数组。其中，路由中间节点服务需继续用“next”关键字指定其下一跳服务，路由终节点的服务不能继续指定，“next”字段为空数组；

(3)定制系统后端获取到路由应用配置文件后调用路由转换算法，自动生成一组topic，将路由应用翻译成服务维度的发布订阅规则。算法遵从最少topic原则，提升系统吞吐量并降低存储开销；算法原理如图2所示，详情如下：

3.1)遍历路由应用配置文件，对于任意一个路由应用，从一个服务流向一个或多个服务生成一个topic，流出的服务为topic的发布方，流向的服务为topic的订阅方，发布方的过滤条件为路由应用的名称。由此生成如下所示的服务维度的发布订阅规则以及topic维度的订阅者组：

服务维度的发布订阅规则是JSON配置文件，Key为服务名称，Value为每个服务的发布订阅关系。其中pub字段表示服务的发布规则，根据路由应用名称选择发布到哪个topic上；sub字段表示服务订阅的topic，可能有多个；

topic维度的订阅者组是JSON配置文件，Key为topic名称，Value为订阅该topic的服务，可能有多个，称为订阅者组。

3.2)遍历所有的topic订阅者组，如果不同的topic被相同的订阅者组订阅，则将这些topic合并，生成新的topic，用新的topic替换3.1)中生成的发布订阅关系中旧的topic，生成最终的消息路由配置；

(4)参与消息路由的服务从路由配置文件中读取当前服务需要订阅的topic，和发布消息的策略，运行时根据消息结构体中的路由应用名称决定发布到哪个topic上；

(5)用户为边缘系统添加子设备时，可以将子设备和其中一个路由应用绑定，该设备产生的数据将按照路由应用的数据链路进行流转。如果不指定，则设备产生的数据将按照默认路由的数据链路进行流转。

本发明从路由维度将边缘服务分为路由起点，路由中间节点，路由终节点和独立服务四大类。用户通过可视化连线或编写配置文件的方式开发路由应用，定义应用名称和每个应用对应的服务间数据流转的完整数据链路。后端系统获取到路由应用配置文件后调用路由转换算法，自动生成一组topic和服务维度的发布订阅规则。本发明摒弃了传统消息路由设置复杂过滤条件的方式，通过配置路由应用的方式降低了开发难度。同时提出了一种路由转换算法，将路由应用配置转换为服务维度的发布订阅规则，通过合并topic提升系统吞吐量，降低存储开销。

本说明书实施例所述的内容仅仅是对发明构思的实现形式的列举，本发明的保护范围不应当被视为仅限于实施例所陈述的具体形式，本发明的保护范围也及于本领域技术人员根据本发明构思所能够想到的等同技术手段。

Claims (1)

1.一种面向边缘计算的消息路由配置方法，包括以下步骤：

(1)按路由维度将边缘服务分为路由起点，路由中间节点，路由终节点和独立服务四大类；详细分类介绍如下：

1.1)路由起点；消息路由的起始节点，一般为驱动层的设备接入类服务，如MQTT服务；消息来源主要为子设备的传感器数据，服务接收到子设备的数据，将数据转化为在边缘系统中数据流转的标准格式，通过消息路由发布出去供其他服务使用；

1.2)路由中间节点；一般为数据处理类服务，如数据过滤服务；服务依据消息路由订阅感兴趣的数据，处理完之后需要把新的消息发布出去供其他服务使用；

1.3)路由终节点；消息路由的终止节点，如数据存储服务；服务依据消息路由订阅感兴趣的数据，消费完成后的消息不再进行发布；

1.4)独立服务；不参与消息路由的服务，典型服务为restful类服务；

(2)用户通过可视化连线或编写配置文件的方式开发路由应用；路由应用由应用名称和数据流转链路两部分组成，详情如下：

2.1)应用名称系统内部唯一，并且每个系统可以定义一个名称为“default”的路由应用，表示系统内服务间数据流转的默认路由；

2.2)数据流转链路标识数据在服务间的流转方向，必须从路由起点开始指定，可以流经零个或多个路由中间节点，最终流向路由终节点结束；另外需要注意的是，一个路由应用所表示的服务间数据流转仍是多对多的关系，即一个服务的路由出口可以指向多个其他服务的路由入口，一个服务的路由入口可以由多个其他服务的路由出口指向；但和原始消息路由不同的是，路由应用内并非根据过滤条件决定数据流向，如果一个服务指向多个其他服务，表示该服务产生的数据将被这些服务全部消费；同理，如果多个服务指向一个服务，表示这些服务产生的数据都将被这个服务消费；

2.3)用户通过可视化或编写配置文件的方式开发路由应用；可视化的方式定义应用名称后，通过可视化连线配置服务间数据流转；配置文件语法为JSON格式，配置文件中的Key标识路由应用名称，为“default”即为默认路由，表示服务间的默认数据流转；否则为应用路由，表示服务间特定的数据流转，优先级高于默认路由；Value字段中，“moduleName”标识当前服务的名称，“next”标识数据流向的下一跳服务，内容为相同语义的JSON数组；其中，路由中间节点服务需继续用“next”关键字指定其下一跳服务，路由终节点的服务不能继续指定，“next”字段为空数组；

(3)定制系统后端获取到路由应用配置文件后调用路由转换算法，自动生成一组topic，将路由应用翻译成服务维度的发布订阅规则；算法遵从最少topic原则，提升系统吞吐量并降低存储开销；算法原理详情如下：

3.1)遍历路由应用配置文件，对于任意一个路由应用，从一个服务流向一个或多个服务生成一个topic，流出的服务为topic的发布方，流向的服务为topic的订阅方，发布方的过滤条件为路由应用的名称；由此生成服务维度的发布订阅规则以及topic维度的订阅者组：

服务维度的发布订阅规则是JSON配置文件，Key为服务名称，Value为每个服务的发布订阅关系；其中pub字段表示服务的发布规则，根据路由应用名称选择发布到哪个topic上；sub字段表示服务订阅的topic，可能有多个；

topic维度的订阅者组是JSON配置文件，Key为topic名称，Value为订阅该topic的服务，可能有多个，称为订阅者组；

3.2)遍历所有的topic订阅者组，如果不同的topic被相同的订阅者组订阅，则将这些topic合并，生成新的topic，用新的topic替换3.1)中生成的发布订阅关系中旧的topic，生成最终的消息路由配置；

(4)参与消息路由的服务从路由配置文件中读取当前服务需要订阅的topic，和发布消息的策略，运行时根据消息结构体中的路由应用名称决定发布到哪个topic上；

(5)用户为边缘系统添加子设备时，将子设备和其中一个路由应用绑定，该设备产生的数据将按照路由应用的数据链路进行流转；如果不指定，则设备产生的数据将按照默认路由的数据链路进行流转。

Images