一种基于发布订阅的边边通讯消息路由方法与流程

1.本发明涉及物联网技术领域，尤其涉及一种基于发布订阅的边边通讯消息路由方法。


背景技术：

2.物联网相对于互联网，强调物的连接，物的连接离不开运行于物之上的应用，当大量的物连接到网络上后，应对爆炸式的业务需求及需求变化，要求物上运行多应用，应用之间动态、灵活进行通讯要求成为难点；传统的应用通讯方式都是硬编码，应用之间的调用关系都是直接调用，数据流向都是写死的，而往往边缘采集的数据需要发给不同的应用使用，实现不同的业务需求，这样当新应用加入且需要使用旧应用采集到的数据时，无法通过配置的方式实现，而需要修改旧应用的源代码将数据发送给新应用，显然这种方式是不可取的，应用之间的独立性未得到保障。
3.另外，传统的跨边缘节点通讯由于各种原因(如安全的考量，外网ip费用的考量)导致消息无法直达，需要通过中间节点进行路由转发。如当一个工厂的所有设备需要将数据发送到外网云端时，出于安全考虑工厂不会给每个设备都开通外网访问权限，而是通过单个网关设备进行转发。
4.现有技术istio提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能。采用istio技术建立的服务网格模式通讯，边缘应用之间无法直接通讯，只能通过各自的sidecar(将本将属于应用程序的功能拆分成单独的进程，这个进程可以被理解为sidecar，sidecar之间可进行通讯)进行通讯，每个应用一个sidecar代理，其步骤为：首选将边缘应用附加到sidecar中，然后边缘应用与sidecar通讯，之后sidecar之间进行通讯，sidecar之间通过服务注册与发现方式来发现彼此。
5.使用istio技术建立服务网格模式通讯存在以下问题：1)istio技术中每个边缘应用都需附带一个sidecar代理，由于现有边缘设备的cpu内存资源有限(如电网设备)，每个边缘应用都需附带一个sidecar代理则会占用很多额外资源，并使得sidecar代理的管理更加复杂。2)传统的网状通讯模式，通讯复杂，且一旦出现问题排查困难。3)现有的应用通讯采用直接通讯，当应用之间无法直接通讯时，则需要自行开发代理服务，自行考虑怎样做消息路由，加大了应用开发难度和复杂性。4)未考虑边缘数据的动态流式处理，没有考虑流式处理框架或者流式处理是写死的，无法动态调整处理流程。


技术实现要素：

6.本发明要解决的技术问题是，提供一种能够动态调整应用的输入输出关系，实现应用之间的完全解耦，应用之间的流数据处理流程可动态配置，可数据削峰填谷避免数据丢失，高效跨边缘节点通讯的边边通讯消息路由方法。
7.为解决上述技术问题，本发明提供一种基于发布订阅的边边通讯消息路由方法，包括以下步骤：
8.s1，启动边缘节点hub路由组件；
9.s2，构建边缘节点间树形消息路由表；
10.s3，配置边缘应用间的消息路由关系；
11.s4，若边缘应用发送流数据则进行边缘应用间流数据通讯，若边缘应用发送请求响应数据则进行边缘应用间请求响应通讯。
12.步骤s1中所述启动边缘节点hub路由组件的步骤包括：
13.s11，当前hub路由组件运行参数加载；
14.s12，当前hub路由组件连接上层节点mqtt broker及本地mqtt broker，并监听topic；
15.s13，当前hub路由组件上报本节点的路由关系至上层边缘节点。
16.步骤s2中所述构建边缘节点间树形消息路由表的步骤包括：
17.s21，由顶至下逐层启动边缘节点hub路由组件；
18.s22，由底至上逐层上报消息路由表，有更新时通知上层边缘节点；
19.s23，将每个边缘节点的消息路由表持久化到文件中；
20.s24，形成树形消息路由表结构。
21.步骤s3中所述配置边缘应用间的消息路由关系的步骤包括：
22.s31，指定边缘应用间的输入和输出的对应关系；
23.s32，将输入输出关系发送至相关的边缘应用。
24.步骤s4中所述进行边缘应用间流数据通讯的步骤包括：
25.s411，发送方边缘应用产生流数据；
26.s412，发送方边缘应用依据步骤s3配置的输入输出关系组装消息topic；
27.s413，发送方边缘应用组装消息并发送至本地mqtt broker；
28.s414，hub路由组件收到流数据，并依据步骤s2产生的路由表以及路由规则进行消息路由；
29.s415，接收方边缘应用接收到流数据；
30.步骤s4中所述进行边缘应用间请求响应通讯的步骤包括：
31.s421，请求方边缘应用a发起请求；
32.s422，边缘应用a按照topic编码规范组装消息请求topic以及响应topic；
33.s423，边缘应用a组装消息并发送至本地mqtt broker；
34.s424，hub路由组件收到此请求，并依据步骤s2产生的路由表以及路由规则进行消息路由；
35.s425，接收方边缘应用b收到此请求；
36.s426，边缘应用b组装响应消息并发送至本地mqtt broker，该响应消息的topic为步骤s422中边缘应用a指定的响应topic；
37.s427，hub路由组件收到步骤s426中的响应消息，并依据步骤s2产生的路由表以及路由规则进行消息路由；
38.s428，边缘应用a收到响应消息。
39.步骤s11中所述当前hub路由组件运行参数加载的步骤包括：
40.s111，定义消息路由方法，所述方法用于实现消息路由的规则，收到消息后由所述
方法来处理，对消息进行路由；
41.s112，定义消息路由变更处理方法，所述消息路由变更处理方法为：接收下级边缘节点上报的路由信息，更新本边缘节点路由表，并将变更的消息路由表信息上报至其上级边缘节点；
42.s113，读取并加载hub路由组件的配置文件，获取组件配置信息，所述组件配置信息包括连接本地mqtt broker的账号密码、边缘节点编号、边缘节点的证书信息、上层http服务地址，并通过访问获取连接上层mqtt broker的账号密码；
43.步骤s12中所述当前hub路由组件连接上层节点mqtt broker及本地mqtt broker并监听topic的步骤包括：
44.s121，本地mqtt数据监听：连接本地mqtt broker，监听需要转发的流数据以及请求响应消息，所述监听以线程运行，按消息类型分多线程处理，以加快消息的并行处理速度；
45.s122，请求上级节点mqtt broker的连接信息，所述上层节点mqtt broker的连接信息包括mqtt broker地址账号密码以及使用设备的证书，将请求参数签名后发起http请求至父节点获取mqtt broker连接信息，并使用获取的连接信息连接上层mqtt broker；
46.s123，远程mqtt数据监听：连接上层mqtt broker，监听需要转发的流数据以及请求响应消息，所述监听以线程运行，按消息类型分多线程处理，以加快消息的并行处理速度；
47.s124，启动http服务监听，供下级hub查询本边缘节点的mqtt broke连接信息。
48.步骤s24所述树形消息路由表结构包括：
49.每个边缘节点中运行一个第三方的mqtt broker消息队列中间件，用于实现消息路由功能hub路由组件，以及若干个边缘应用；
50.所述hub路由组件同时连接两个mqtt broker，所述两个mqtt broker中，其一是本边缘节点内的mqtt broker,另一个是上层边缘节点的mqtt broker；
51.只有hub路由组件能够与外部边缘节点通讯；同一边缘节点内部的边缘应用通过内部mqtt broker进行通讯，无需经过hub路由组件进行路由；不同边缘节点应用之间的通讯，通过hub路由组件进行路由。
52.所述边缘应用包括输入、处理逻辑、输出以及请求响应api接口4部分，任一边缘应用的输出能够作为另一个边缘应用的输入，通过配置边缘应用之间的输入输出关系的来决定数据的输入输出关系，形成一个完整的数据处理流程。
53.步骤s414、步骤s424、步骤s427中所述路由规则如下：
54.s91，hub路由组件收到待路由的消息后，从消息中获取中的真实目标topic字段，并从中解析出目标节点及目标应用；
55.s92，判断目标节点是否是当前节点，若是则将消息发送至目标应用在当前节点mqtt broker的监听topic；
56.s93，若目标节点非当前节点，则从自己的路由表中查找目标节点是否是自己的子节点，若是则发送至直属子节点hub路由组件在当前节点mqtt broker的监听topic，跳转至步骤s91，若否则执行下一步；
57.s94，若目标节点不是当前节点的子节点，则判断目标节点是否是其上层节点，若
是则将消息发送至目标应用在其上层节点mqtt broker的监听topic；
58.s95，若目标节点不是当前节点的上层节点，则将消息发送至上层节点mqtt broker的hub路由组件的监听topic，跳转至步骤s91。
59.步骤s412中所述消息topic，以及步骤s422中所述消息请求topic以及响应topic的组装步骤包括：
60.按照以下格式组装topic：发送节点编号/发送应用编号/消息大类/接收节点编号/接收应用编号/接收应用guid/动态多层路径，其中，
61.所述发送节点编号为发出消息的边缘节点唯一编号，
62.所述发送应用编号为发出消息的组件唯一编号，
63.所述消息大类包括请求、响应、量测数据或事件数据3大类，
64.所述接收节点编号为接收消息的边缘节点唯一编号，
65.所述接收应用编号为接收消息的组件唯一编号，
66.所述接收应用guid为响应类消息返回到指定组件的唯一性标识，
67.所述动态多层路径为指定消息的类型，边缘应用通过此字段来识别消息的类型，并使用对应的数据解析方式解析消息体数据；
68.步骤s413、步骤s423、步骤s426中所述消息的结构包括：消息接收者、响应id、发送时间戳、数据唯id、加密认证方式、响应消息发送目的地、用户自定义头属性、数据消息体。
69.本发明公开的一种基于发布订阅的边边通讯消息路由方法的有益效果在于：
70.本方法引入基于消息队列中间件，实现基于发布订阅方式的请求响应通讯以及流数据方式通讯，不但可以解决峰值数据的处理问题，同时可利用消息队列的分组订阅模式实现并发处理，加快数据的处理速度；应用之间的调用不在是直接调用，而是采用可配置的数据路由方式，无需修改源代码就可以实现将数据发送给新增的应用使用，实现应用之间通信的真正解耦。
71.现有边缘设备的cpu内存资源有限，如电网设备，每个边缘应用都需附带一个sidecar代理的话额外资源占用会很大，且sidecar代理的管理就更加复杂，采用本方法一个边缘设备仅需一个hub路由组件，额外资源占用小且易管理；传统的网状通讯模式，通讯复杂，且一旦出现问题排查困难，本方法采用的是树状通讯模式，通讯结构清晰，出现问题后也容易排查；现有的应用通讯方法直接通讯，当应用之间无法直接通讯时，则需要自行开发代理服务，自行考虑怎样做消息路由，而本方法支持基于消息路由的间接通信，应用无需考虑消息怎样路由；现有方案未考虑边缘数据的动态流式处理，一般没有考虑流式处理框架或者流式处理是写死的，无法动态调整处理流程，而本方法约定了通讯的消息格式，可动态调整应用的输入输出关系，按业务需求调整流数据的处理过程。
72.不同于传统应用之间写死的通讯方式，本方法支持应用之间基于发布订阅的通讯方式，实现请求响应式通讯以及流数据方式通讯，应用开发时只需关注应用本身的输入、处理逻辑、输出和能提供的api接口，无需关注数据输入从哪里来，结果要输出到哪里去，输入输出关系可动态灵活配置；本发明同时提供高效的消息路由方法，即使边缘节点之间应用无法直接通讯，也可以通过中转节点间接通信，解决多层网络节点结构中应用之间通讯的问题，这种方式在有安全分区的局域网之间的通讯显得尤为重要，它无需局域网内每个边缘节点都能访问外网，只需开通一台能访问外网的边缘节点，其他节点与外网之间的通讯
通过此边缘节点中转；自动注册及查找路由关系，构建路由关系网时，只需指定边缘节点的上级节点是谁，边缘节点入网后会自动注册路由关系至相关节点。本发明提供了一种应用之间松耦合、灵活的通讯架构，让应用之间的数据流动及处理更加灵活，让边缘应用灵活的增加、删除和更新后相互不影响，用以满足业务处理的边缘化，同一份数据可以动态的给多个应用使用，而无需修改源代码。
附图说明
73.图1是本发明实施方式的流程图。
74.图2是hub消息路由上报过程示例图。
75.图3是树形消息路由表结构示例图。
76.图4是边缘应用结构及通讯示例图。
77.图5是边缘应用间的通讯机制示例图。
78.图6是边缘应用的topic监听示例图。
79.图7是边缘应用基于发布订阅的请求响应机制示意图。
80.图8是hub消息路由规则示意图。
具体实施方式
81.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
82.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
83.还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
84.如图1所示，基于发布订阅的边边通讯消息路由方法，包括以下步骤：
85.步骤s101，启动边缘节点hub路由组件，包括以下步骤：
86.s1011，当前hub路由组件运行参数加载：
87.首先，定义消息路由方法，所述方法用于实现消息路由的规则，收到消息后由所述方法来处理，对消息进行路由；
88.其次，定义消息路由变更处理方法，所述消息路由变更处理方法为：接收下级边缘节点上报的路由信息，更新本边缘节点路由表，并将变更的消息路由表信息上报至其上级边缘节点；
89.然后，读取并加载hub路由组件的配置文件，获取组件配置信息，所述组件配置信息包括连接本地mqtt broker的账号密码、边缘节点编号、边缘节点的证书信息、上层http服务地址，并通过访问获取连接上层mqtt broker的账号密码。
90.s1012，当前hub路由组件连接上层节点mqtt broker及本地mqtt broker，并监听topic：
91.本地mqtt数据监听：连接本地mqtt broker，监听需要转发的流数据以及请求响应消息，所述监听以线程运行，按消息类型分多线程处理，以加快消息的并行处理速度；
92.请求上级节点mqtt broker的连接信息，所述上层节点mqtt broker的连接信息包括mqtt broker地址账号密码以及使用设备的证书，将请求参数签名后发起http请求至父节点获取mqtt broker连接信息，并使用获取的连接信息连接上层mqtt broker；
93.远程mqtt数据监听：连接上层mqtt broker，监听需要转发的流数据以及请求响应消息，所述监听以线程运行，按消息类型分多线程处理，以加快消息的并行处理速度；
94.启动http服务监听，供下级hub查询本边缘节点的mqtt broke连接信息。
95.s1013，当前hub路由组件上报本节点的路由关系至上层边缘节点。
96.步骤s102，构建边缘节点间树形消息路由表，包括以下步骤：
97.s1021，由顶至下逐层启动边缘节点hub路由组件；
98.s1022，由底至上逐层上报消息路由表，有更新时通知上层边缘节点；
99.s1023，将每个边缘节点的消息路由表持久化到文件中；
100.s1024，形成树形消息路由表结构。
101.如图2所示，hub消息路由上报过程如下：首先顶层边缘节点hub路由组件a启动，然后次顶层边缘节点hub路由组件b启动；b启动时会上报自己的路由信息给上层节点a，a中的路由表则为{a:{b}}；b的下一层c启动后，上报自己的路由信息至自己的上层节点b，b中的路由表则为{b:{c}}；若b的路由表有变动，则会自动上报其路由表至其上层节点a，a中的路由表则为{a:{b:{c}}}。为保证hub路由组件重启后，路由表不会丢失，需要将路由表信息持久化到文件中。
102.最终形成的树形消息路由表结构如图3所示，图3中每个边缘节点中运行一个第三方的mqtt broker消息队列中间件，用于实现消息路由功能hub路由组件，以及若干个边缘应用；所述hub路由组件同时连接两个mqtt broker，所述两个mqtt broker中，其一是本边缘节点内的mqtt broker,另一个是上层边缘节点的mqtt broker；只有hub路由组件能够与外部边缘节点通讯；同一边缘节点内部的边缘应用通过内部mqtt broker进行通讯，无需经过hub路由组件进行路由；不同边缘节点应用之间的通讯，通过hub路由组件进行路由。
103.步骤s103，配置边缘应用间的消息路由关系，包括以下步骤：
104.s1031，指定边缘应用间的输入和输出的对应关系；
105.s1032，将输入输出关系发送至相关的边缘应用。
106.其中，边缘应用包括输入、处理逻辑、输出以及请求响应api接口4部分，任一边缘应用的输出能够作为另一个边缘应用的输入，通过配置边缘应用之间的输入输出关系的来决定数据的输入输出关系，形成一个完整的数据处理流程。如图4边缘应用结构及通讯实例图所示，边缘应用结构如下：
[0107][0108]
其中，
[0109]
routers:流数据接收方清单，可配置不同流数据发送给不同的应用，一个数组元素即是一条发送规则。
[0110]
frommoduleid:指定了是哪个应用id发布消息，如果是模组自身发出，值为*。
[0111]
frommessagename:从应用发出消息的类型，默认发送所有的消息类型时值为*(发送app的输出)。
[0112]
tomoduleid:接受消息的应用id,格式为{边缘节点id}.{应用id}。
[0113]
tomessagename:指定接受的消息类型，即此消息类型在消息接收方的类型名(接收app的输入)。
[0114]
边缘应用在发送流数据、请求或响应数据时，需将消息的实际接收人写入mqttenvelope的target字段，并判断接收人是否是同一边缘节点内的应用，若是则直接发送至该应用的topic，若不是则将消息发送给hub转发模块的topic，由hub转发模块去将消息路由到指定应用。
[0115]
边缘应用设计为可动态调整此输入输出关系，调整时只需修改配置，而无需修改源代码。
[0116]
应用在发送消息之前，首先从routers中查找消息的接收对象清单，然后发送，当未找到接收对象时则不发送。
[0117]
图4中routers示例有两条规则(连线):
[0118]
第一条规则是设备01中的采集app(device01.collectionapp)采集到温度(temperature)数据后,将消息类型名修改为wendu,然后发送至设备01的告警app(device01.alarmapp)；
[0119]
第二条规则是当前设备的当前app(*)采集到电压(voltage)数据后,将消息类型名修改为dianya,然后发送至设备01的告警app(device01.alarmapp)。
[0120]
步骤s104，若边缘应用发送流数据则进行边缘应用间流数据通讯，若边缘应用发送请求响应数据则进行边缘应用间请求响应通讯。
[0121]
其中，边缘应用间流数据通讯的步骤包括：
[0122]
s10411，发送方边缘应用产生流数据；
[0123]
s10412，发送方边缘应用依据步骤s103配置的输入输出关系组装消息topic；
[0124]
s10413，发送方边缘应用组装消息并发送至本地mqtt broker；
[0125]
s10414，hub路由组件收到流数据，并依据步骤s102产生的路由表以及路由规则进行消息路由；
[0126]
s10415，接收方边缘应用接收到流数据。
[0127]
边缘应用间请求响应通讯的步骤包括：
[0128]
s10421，请求方边缘应用a发起请求；
[0129]
s10422，边缘应用a按照topic编码规范组装消息请求topic以及响应topic；
[0130]
s10423，边缘应用a组装消息并发送至本地mqtt broker；
[0131]
s10424，hub路由组件收到此请求，并依据步骤s102产生的路由表以及路由规则进行消息路由；
[0132]
s10425，接收方边缘应用b收到此请求；
[0133]
s10426，边缘应用b组装响应消息并发送至本地mqtt broker，该响应消息的topic为步骤s10422中边缘应用a指定的响应topic；
[0134]
s10427，hub路由组件收到步骤s10426中的响应消息，并依据步骤s102产生的路由表以及路由规则进行消息路由；
[0135]
s10428，边缘应用a收到响应消息。
[0136]
其中，如图5边缘应用间的通讯机制实例图所示，边缘应用之间的通讯通过发布订阅的方式实现：每个已部署边缘应用有一个唯一编码(edgenodecode/appcode),边缘节点编码/应用编码；每个应用监听2个消息通道，对应4个通配topic，按数据类型分为：
[0137]
接收量测数据/事件数据的topic，
[0138]
接收请求数据的topic，
[0139]
接收一发多收请求数据topic(应用于远程数据召测，接收方编号用*替代)，
[0140]
接收响应数据的topic(auto-delete,组件停止时自动删除)，
[0141]
拆分成2个通道的目的是防止大量的流数据堵塞请求/响应数据，发布者发布消息时通过topic指定要发送给哪个应用的哪个队列。
[0142]
边缘应用之间通讯的topic编码规范如下：
[0143]
在topic中指定消息发送方、消息接收方、消息大类以及消息类型，之后的消息路由就是通过解析topic中的消息接收方来查找路由路径，topic格式如下：
[0144]
{发送节点编号}/{发送应用编号}/{消息大类}/{接收节点编号}/{接收应用编号}/{接收应用guid}/{动态多层路径}
[0145]
其中，发送节点编号为发出消息的边缘节点唯一编号；
[0146]
发送应用编号为发出消息的组件唯一编号；
[0147]
消息大类包括3大类：req(请求)、res(响应)、data(量测数据或事件数据)；
[0148]
接收节点编号为接收消息的边缘节点唯一编号(可不指定接收节点，用*代替，表
示通配)；
[0149]
接收应用编号为接收消息的组件唯一编号(当消息类型为data时，可不指定接收组件，用*代替，表示通配)；
[0150]
接收应用guid为响应消息才有的部分，响应topic加上guid的目的是保证组件集群部署时的唯一性，让响应数据返回到指定组件；
[0151]
动态多层路径即指定消息的类型，应用通过此字段来识别消息的类型，并使用对应的数据解析方式解析消息体数据，当消息类型为req时，动态路径主要表示请求响应的路径，可多层，例如：node1/app1/req/node2/app2/container/deploy，当消息类型为res时，需指定组件实例的唯一编号(解决组件多实例部署时的响应消息接收方)，例如：
[0152]
node2/app2/res/node1/app1/app1_guid/container/deploy，当消息类型为data时，动态路径主要表示数据的类型，例如：node1/app1/data/node2/app2/alarminfo。
[0153]
另外，如图6所示，边缘应用通过监听4个通配的topic来接收发送给自己的数据，并执行对应的处理方法：
[0154]
量测数据/事件数据topic： / /data/{边缘节点编码}/{组件编码}/#，
[0155]
请求topic： / /req/{边缘节点编码}/{组件编码}/#，
[0156]
一发多收请求topic： / /req/*/{组件编码}/#(接收节点编码为*，表示通配)，
[0157]
响应topic： / /res/{边缘节点编码}/{组件编码}/{组件guid}/#。
[0158]
边缘应用之间通讯的mqtt消息结构采用mqttenvelope表示：
[0159][0160]
其中，如果auth有值，则需要先依据其值对messagebody做解密/认证处理，messagebody未签名加密时为json字节流，在请求消息中指定replyto topic，边缘应用再将响应数据发送至指定的replyto topic，同时响应消息中的correlationid与请求消息中的uniqueid进行匹配，实现基于发布订阅的请求响应的效果，请求和响应一一匹配而不会错乱。
[0161]
不同消息类型选填/必填项如下：
[0162]
量测数据/事件数据
[0163][0164]
请求数据
[0165][0166]
响应数据
broker的hub路由组件的监听topic，用上层节点hub路由组件的id parentnode/hub替换目标节点及目标应用snode/sapp，最终发送topic为tnode/tapp/data/parentnode/hub/hello/world，再由其上层hub路由组件跳转至第一步来查找消息路由路径。
[0176]
本发明实施例可以根据实际需要进行顺序调整、合并和删减。
[0177]
实施例对本方案进行了详细的介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。