边缘计算开源项目解读--kubeedge设备孪生

0 背景

        前面的《边缘计算开源项目概述》【1】一文中，我们简单介绍了当前学术界和工业界的一些开源计算项目。今天开始笔者将详细解读其中的kubeedge开源项目，该项目是云边融合的典型项目，它将云端的应用编排和管理扩展到了边缘设备，基于kubernents构建，实现了云边可靠协作、边缘自治、代理和设备管理，可以非常容易地将已有的复杂机器学习、图像识别、事件处理等部署到边缘端。本文将从设备孪生入手，详述什么是设备孪生，设备孪生的价值以及kubeedge中设备孪生是如何实现的，希望对读者学习和研究kubeedge有一定的帮助和启发。

1 什么是设备孪生

        设备孪生并不是边缘计算设备才引入的新概念，在我们当前的云计算+物联网场景中，就已经有设备孪生的概念，比如在当前的车载系统中，我们可以在手机端实时查看车辆的各种状态信息，如地理位置、油耗、行驶里程等，这些都是由车辆实时上报到云端。通过这些参数，我们就可以实时掌握车辆的健康状态，在车辆发生故障或者异常之前就可以提前被告知，就像在云端存在我们一辆一模一样的车一样，只不过这辆车是虚拟的。设备孪生也是基于这样的一个概念，真实世界的事物被映射到虚拟世界中，孪生出这个事物的一个虚拟镜像。

        针对设备孪生，在工业界有自己的一些定义，此处选取了微软和华为的定义，如下图所示。微软定义的设备孪生是存储设备状态信息的json文档，设备的状态信息包括元数据、配置和条件等。这个定义是从孪生设备数据存储格式，存储的内容角度给出的。华为的定义将设备的数据分为了两类，一类是设备的属性数据，静态的；另一类是设备的孪生属性，动态的。设备属性，一般是不会改变的元数据，包括序列号、资产标识、MAC地址等表示设备信息的数据。孪生属性，是设备在特定的环境场景下，状态发生变化的数据。设备的真实状态可以上报给孪生设备进行状态更新，孪生设备的期望状态也可以下发给设备，让设备按照预期的状态改变。

2 设备孪生的价值

        如下图所示，设备孪生可以将设备的特定元数据存储在云端，通过设备应用报告设备的真实状态，同步设备自身的参数或者环境数据，实时在云端对设备的健康状态进行监控。另外设备孪生通过设备的实时化虚拟映射，可以将过去被动的服务转变为主动式服务，在设备出现状况前提前预测，以便在预定停机时间之前更换磨损的部件，避免意外停机，实现设备的预测性维护。

        本文中的开源项目kubeedge将设备孪生的功能从云端下沉到了边缘端，作为边缘侧核心特性。我们知道kubeedge一个重要的应用场景就是物联网，在物联网场景下会有海量的设备接入进来，如果将所有设备的孪生都放到云端，对网络、时延和安全的挑战是非常大的。相反，如果将设备的孪生信息就近存储在边缘端，会带来以下几点好处：

        1）数据不需要全部上传到云端，占用带宽少，对网络的冲击比较少。

        2）可以在本地缓存部分状态数据，断网情况下，终端可以自治。

        3）对设备的智能运维可以放到本地的边缘设备，具备良好的实时性，局部管理的成本也相对较少。

        4）用户周边的环境信息往往包含许多敏感的隐私数据，在边缘侧存储设备的孪生数据，可以降低隐私被泄露的风险。

        5）物联网设备的状态控制放在云端的device controller模块，设备的孪生数据被放在边缘端device twin管理，device twin模块不产生数据，只负责记录和转发来自云端的设备期望状态，以及来自终端的真实状态，在架构上实现了控制面和数据面的分离。

        6）分布式的管理方式和微服务架构，方便了对设备孪生功能的扩展、升级和维护。

3 kubeedge设备孪生的实现

        本小节开始将对kubeedge的设备孪生的实现进行介绍，首先我们要解读的是device twin模块，这个模块是分割在边缘侧的核心模块，代码路径是kubeedge\edge\pkg\devicetwin。 与该模块相关的模块，如eventbus，device controller等将在后续的文章中解读。接下来笔者将从devicetwin的文件架构、配置和状态获取的流程、核心的业务实现三个角度展开。

3.1 设备孪生模块文件架构

        现有的kubeedge说明文档，并没有很清晰地讲解device twin的内部架构，读者进入该文件夹下后，会一片茫然，不知道该从何入手，哪些文件夹和文件之间有依赖关系，依赖关系的上下层联系是怎样的。笔者按照文件夹和文件即架构的思路，将其中的文件和文件夹的层级关系进行了整理，如下图所示，笔者按照图中所示的层级由上而下的阅读代码，可以很容易找到一条清晰的逻辑路径。

        图中右边所示的框图，非常符合我们常见的分层架构。各个模块的功能详解如下：

        主控制流程是这个模块的入口，包括config/dtmoudle两个文件夹和devicetwin.go/process.go两个文件。devicetwin.go是整个模块的执行入口，主要实现了4个线程（membership/twin/device/communicate）的启动，注册和分发设备孪生相关的消息处理；process.go负责对与其他模块（eventbus/edgemgr/devicecontroller/edgehub）通信，对消息进行分类，分发和处理。dtmoudle主要实现了模块的命名，初始化和启动管理，config实现了初始化相关的配置。消息的注册和分发的流程将在3.3节中介绍。

        协议解析层主要对发送的消息报文进行解析或者封装，对内为业务逻辑层提供数据，对外将业务逻辑层的数据封装成其他模块的消息格式，相关的文件夹是dttype。在模块中承载消息内容的基本格式是json，这些数据既有来自云端的设备管理数据，也有设备上报上来的状态数据。去往终端的消息将被进一步封装成mqtt报文的格式，发布到设备上，而订阅的终端状态也是通过mqtt报文承载，在此处会被转成云端可以识别的消息格式，发送到云端。

        业务逻辑层实现了设备、分组成员、云边通信和孪生4类消息的处理，将来自云端或者设备端的数据缓存到边缘侧，实时更新最新的状态，相关的文件夹是dtmanager。上述4类消息的入口函数都是start，处理算法上也类似，首先是注册消息主题的回调函数，然后开启通道接收消息，通道包括两类一类是业务相关的消息，另一类是心跳消息，当有对应模块的消息收到后就会进行解析处理。详细的过程也将在3.3节中介绍。

        持久化层实现了设备的状态、孪生设备、分组成员等数据的边缘化存储，数据库采用sqlite，提供了对整个数据库表项的增删改查操作，当前实现的数据库表项有设备、设备属性和设备孪生三张表，相关的文件夹是dtclient。

        公共接口为上层模块提供公共可调用的接口，包括mqtt相关主题的定义，模块名称定义，上下文环境中需要的锁，报文的构造，消息的发送封装等功能，相关的文件夹是dtcommon和dtcontext。

3.2 设备孪生配置和状态获取

        在3.1节中了解了device twin内部的各个模块后，在本小节将跳出该模块，从模块关系的角度进行解读。如下图所示，有黑色和红色两条虚线，分别代表设备状态的配置过程和设备状态上报的过程。与之前只有云和设备两层的架构不同，在引入边缘层后，数据会在边缘侧做缓存，因此其更新的过程也会相对复杂一些。设备的更新状态会首先在边缘侧缓存一份，然后发布到设备端；上报的设备状态除了可以继续上送到云端以外，还可以就近缓存到边缘侧，卸载到哪一侧则由终端应用决定。

        图中跟这个过程相关的模块有6个，从上至下依次是云端的设备控制（device controller），负责管理分组成员、设备孪生和设备的期望状态；接下来是边缘侧的edgehub（边缘网关），负责与云端进行通信，与device twin相关的功能是lifecycle（生命周期）的管理；再往下就是eventbus（事件总线）模块，负责与终端进行通信，接收来自终端的设备真实状态、分组成员的信息更新、孪生数据的同步、更新等消息给到device twin模块，或者将上述的期望状态封装成mqtt消息分发到设备侧；mqtt broker是外部使用的一个开源项目，负责对mqtt消息进行分发；再往下就是mapper层，该层主要是将异构设备的通信协议转换成mqtt消息格式，或者反向转换，实现数据格式的统一；最后来到设备层，设备通过各自的协议接入到边缘侧，这个模块的代码并没有包含在kubeedge代码中，而是在另外一个分库中，后续笔者也会进行介绍。

        在熟悉了以上各个模块的基本功能后，接下来就是设备期望状态的配置和真实状态上报的流程了。设备期望状态配置到设备时，首先由云端的device controller下发到边缘网关，然后由device twin缓存一份到边缘数据库，接下来由eventbus封装该状态发布到broker，最后由broker通知到订阅该主题的设备，更新其自身状态。设备真实状态上报到云端或者边缘端，首先由mapper将状态封装成mqtt报文，发布给broker，然后由eventbus根据订阅的消息主题，直接上报真实状态到云端，或者将设备的真实状态由device twin存储到边缘数据库，最终再上报到云端的设备控制模块。

3.3 设备孪生核心业务实现

        在3.2节了解了各个模块的关系后，我们再回到设备孪生模块的内部，看看这些模块间的消息在设备孪生模块内部如何处理的。如下图所示，来自event bus/event hub/device controller的外部消息会通过设备孪生内部的消息分发子模块分发到3.1节提到的4个子模块，这4个子模块有消息的接收通道（receiverchan）做进一步的解析，回调具体的处理接口，图中橘色呈现的部分。

        这4个子模块是通过下图所示的模块注册接口进行注册，定义属于自己处理职责的消息，每个子模块都包括接收通道，确认通道，心跳通道和上下文相关的4个通道，最终开启4个不同的线程进行处理。这种注册/分发的架构是kubeedge中一种常用的设计模式，在后续的其他模块中会反复被提到。这种架构，可以实现基本的协议解析和业务逻辑的分离，读者可以在自己的项目开发中使用。

4 小结

        本文系统解读了kubeedge中的设备孪生模块的实现价值和实现过程。后续笔者将以此为切入点，深入解读其他的模块，也将实践参与到该开源项目中，并分享给各位读者，敬请期待。

5 参考文献

【1】边缘计算开源项目概述_linus_ben的博客-CSDN博客_边缘计算开源项目