「连载」边缘计算（一）01-16：边缘计算系统逻辑架构（原理篇）

之前的基础篇（第1~2章）

首先，介绍边缘计算概念、边缘计算系统具体组成部分，对边缘计算最佳实践中的相关概念进行解析；然后给出边缘计算系统所需的自动化部署脚本，读者可以根据脚本轻松地将边缘计算最佳实践整体框架部署起来，并在其上进行管理和部署应用；最后以管理终端设备应用的部署方式入手，对比分析该应用在云数据中心部署和以云、边、端协同的方式部署的利弊，从而引出使用边缘计算的必要性。

（接上篇）

边缘计算系统逻辑架构

由图3-1可知，逻辑架构侧重边缘计算系统云、边、端各部分之间的交互和协同关系，包括云、边协同，边、端协同和云、边、端协同3个部分。

1)云边协同：通过云部分Kubernetes的控制节点和边部分KubeEdge所运行的节点共同实现的。

2)边端协同：通过边部分KubeEdge和端部分EdgeX Foundry共同实现的。

3)云边端协同：通过云解决方案Kubernetes控制节点、边缘解决方案KubeEdge和端解决方案EdgeX Foundry共同实现的。

图3-1边缘计算系统逻辑架构

云边协同

云边协同的具体实现如图3-2所示。

1）Kubernetes控制节点沿用云计算原有的数据模型，保持原有的控制、数据流程不变，即KubeEdge所运行的节点在Kubernetes上呈现出来的是Kubernetes的一个普通节点，Kubernetes可以像管理普通节点一样管理KubeEdge所运行的节点。

2）KubeEdge之所以能够运行在资源受限、网络质量不可控的边缘节点上，是因为KubeEdge在Kubernetes控制节点的基础上通过云部分的CloudCore和边缘部分的EdgeCore实现了对Kubernetes云计算编排容器化应用能力的下沉。云部分的CloudCore负责监听Kubernetes控制节点的指令和事件下发到边缘部分的EdgeCore，同时将边缘部分EdgeCore上报的状态信息和事件信息提交给Kubernetes的控制节点；边缘部分的EdgeCore负责接收云部分CloudCore的指令和事件信息，并执行相关指令和维护边缘负载的生命周期，同时将边缘的状态信息和事件上报给云部分的CloudCore。除此之外，EdgeCore是在Kubernetes的Kubelet组件的基础上进行裁剪、定制而成的，将Kubelet在边缘上用不到的富功能进行了裁剪，针对边缘上资源受限、网络质量不佳的现状在Kubelet的基础上增加了离线计算的功能，使EdgeCore能够很好地适应边缘的环境。

图3-2 边缘计算系统云、边协同逻辑架构

边端协同

边端协同的具体实现如图3-3所示。

1）KubeEdge作为运行在边缘节点管理程序，负责运行在边缘节点应用负载的资源、运行状态和故障自愈等。在本书的边缘计算系统中，KubeEdge为EdgeX Foundry服务提供所需的计算资源，同时负责管理EdgeX Foundry服务的整个生命周期。

2）EdgeX Foundry 是由KubeEdge管理的一套IoT SaaS平台，该平台将以微服务的形式管理多种物联网终端设备。同时，EdgeX Foundry能够通过所管理的微服务采集、过滤、存储和挖掘分析多种物联网终端设备的数据，也可以通过所管理的微服务向多种物联网终端设备下发指令来对终端设备进行控制和监控设备的运行状态。

图3-3 边缘计算系统边端协同逻辑架构

由图3-4可知，KubeEdge自己的端解决方案由MQTT代理和对接支持各种协议设备的服务组成。

1）MQTT代理作为各种物联网终端设备和KubeEdge节点之间的一个通信管道，负责接收终端设备发送的数据，并将接收到的数据发送到已经订阅了MQTT代理的KubeEdge节点上；

2）对接支持各种协议设备的服务 负责与支持相应协议的设备进行交互，能够采集设备的数据并发送给MQTT代理，并能够从MQTT代理接收相关指令下发到设备，但目前只支持Bluetooth和Modbus两种协议。

通过上述分析可知，KubeEdge的端解决方案还比较初级。

1）KubeEdge的端解决方案支持的负载类型还比较单一，目前只能通过MQTT代理支持一些物联网终端设备，对视频处理和使用AI模型进行推理的应用负载的类型还不支持。

2）对接支持各种协议设备的服务目前还比较少，只支持使用Bluetooth和Modbus两种协议的设备。

基于上述原因，本书的边缘计算系统的端解决方案没有使用KubeEdge自己的端解决方案，而是使用EdgeX Foundry这款功能相对比较完整的IoT SaaS 平台作为端解决方案。

图3-4 KubeEdge端解决方案逻辑架构

「未完待续……」