边缘计算开源项目解读——kubeedge mappers实现

0 背景

        本文重点解读kubeedge项目中的mapper模块。该模块位于kubeedge的edgecore的南向边缘侧,主要对接入kubeedge的终端设备,进行协议的适配和转换,使其可以和边缘设备通信,转换后的协议是我们前面描述的mqtt协议,当然也支持http协议。当前该模块支持BLE、MOBUS等多种物联网协议的转换,这部分代码单独有一个git路径【1】,有自己独立的架构和功能特性。笔者将从代码架构,模块的上下文,订阅和发布消息的角度对其进行解读。

1 mapper代码架构

        mapper的代码架构从其模块功能上我们也能推断出肯定包含南向和北向两种通信方式,南向的主要是和终端设备通信,而北向则主要将消息传递给边缘设备。那这两者之间得有个桥梁,将其连接起来,本质上就是要进行协议的转换。基于这样的思路,我们再去看mapper中的代码目录就变得很清晰了。如下图所示是整个mapper模块文件夹和协议转换架构之间映射关系。

f04dbdacbd3748469711325bd2c2b75c.png

        图中左侧的代码目录分为三部分。其一是当前已经支持的协议,我们看到有七种协议,这些协议是物联网场景被广泛使用的通信协议,实现与终端设备的连接,此处映射到协议层。第二部分有di,models和service三个文件夹,其中models实现了跟协议层的交互,di主要实现了mapper的容器功能,service作为mapper模块的主控流程,此处我们将其划归到驱动层。最后的第三部分主要实现协议的转换和北向通信,主要有mqttadapter,httpadapter,clients三个核心功能。其中clients实现了与broker的通信,另外两个主要实现协议数据的转换。各层功能的交互过程将在3和4小节讲述。

2 mapper模块的上下文

        mapper模块的上下文指的是该模块在kubeedge中的所处的位置,这个模块实现了终端设备和边缘设备之间的互联,上边通过broker与EventBus通信,下边与终端设备通过各种物联网协议(BLE/MOBUS等)连接。这个模块在终端和边缘之间搭建了一座桥梁,可以让终端设备很方便地插入到边缘设备上。

b3b2d166779745e2a2d6a238b4f035ee.png

        上图中以mqtt协议为例,讨论一下这个模块的在云边端这种架构下的作用。我们已经知道在云边端场景下,设备的状态修改可以由云端发起,该期望状态首先到达边缘设备的devicetwin,存储在边缘侧的database,然后通过EventBus发布修改设备状态到broker。那这个状态如何更新到终端呢?此处就需要用到我们本文的mapper模块,该模块从broker订阅了更新设备状态的主题,broker将期望的终端状态发送到mapper,mapper再根据连接的终端设备,将期望状态转换成终端连接的协议,最后发送给终端。同样的当设备的状态发生变化时,也可以通过相反的过程上送到边缘侧和云侧。在了解了这个模块的外部交互后,我们看看模块内部的实现流程是怎样的,下面将从订阅和发布两个方向上进行梳理。

3 mapper订阅消息流程

        mapper订阅消息,订阅的主题来自于broker。整个mapper服务的入口是bootstrap,其中控制了整个的订阅流程,首先是创建一个mapper容器,然后定义了一个mapper服务实例。在实例的内部,依次实现了协议主题订阅,协议转换,协议挂载和协议的内部适配,通过这套流程就可以实现一个完整的主题订阅和实现过程。最终解析出的数据会通过BLE等协议发送给终端设备。

fa6bce1b38aa4bc2989299bbde81d68a.png

        mapper服务实例内部各子模块的功能描述和实现如下:

  • 协议主题订阅:对应clients文件夹,实现了mqtt客户端功能,完成mapper和broker的连接,主题的订阅。
  • 协议转换:对应mqttadapter文件夹,实现了mqtt协议与其他协议数据的格式转换,动态添加和删除设备。
  • 协议挂载:对应controller文件夹,实现了主题接口的订阅,调用驱动接口配置数据到设备。
  • 协议内部适配:对应ble等文件夹,实现了mqtt信息获取,设备数据初始化,ble初始化等基础功能,然后初始化订阅主题消息最后解析订阅的主题,将数据配置成ble的数据格式。

4 mapper发布消息流程

        mapper发布消息,发布的主题会发送给broker。实现的流程与上述的订阅消息类似。不同的地方是mapper服务实例内部的模块从设备端起始,最终到broker截止。如下图所示,发布的数据来自设备,包括孪生数据,用户数据和设备状态数据,其中的孪生数据会更新到边缘设备的devicetwin模块。在协议挂载挂载的是发布主题接口,实际的执行接口实现驱动控制和获取设备数据。在协议转换模块,定时上报来自设备的三类数据。最后的协议发布模块,创建发布主题,将数据发送到broker。

ead9b560b1044002bb4f6a47a34a41b7.png

5 小结

        本文从代码流程和架构的角度解读了kubeedge的mapper模块,这个模块是开发者在应用开发中需要二次开发的地方,特别是当项目中使用当前不支持的物联网协议时,就需要根据提供的架构在mapper中实现对自研协议的支持。希望本文能够对开发者有所启发,下一步笔者将转向MetaManager模块的解读,敬请期待。

参考文献:

【1】https://github.com/kubeedge/mappers-go

猜你喜欢

转载自blog.csdn.net/linus_ben/article/details/129302354