「连载」边缘计算（四）01-19：边缘部分原理解析（原理篇）

(接上篇)

边缘部分组件

在形式上，EdgeCore是一个单独的可执行文件，其中不同的功能以模块的形式进行管理，具体架构如图5-3所示。

图5-3 EdgeCore架构

由图5-3可知，EdgeCore包含的功能模块比较多，包括EdgeHub、MetaManager、DeviceTwin、EventBus、Edged、Edgemesh、CSI和CNI。接下来逐个功能模块进行解析。

1. EdgeHub：KubeEdge边缘部分组件与云部分组件交互的门户，负责接收云下发到边缘的资源操作数据，并传送给边缘组件的其他功能模块。
2. MetaManager：负责从EdgeHub 接收pod、ConfigMap、Secret、Service、和Endpoint等资源的增、删、改、查信息。首先将这些信息写入sqlite，然后将这些信息传送给Edged，同时接收Edged上报的NodeStatus、podStatus等事件, 并将这些信息写入sqlite，最后将这些信息传送给EdgeHub。
3. DeviceTwin：负责从EdgeHub 接收DeviceInstance、DeviceTwin和Desired等资源的增、删、改、查信息。首先将这些信息写入sqlite中，然后将这些信息传送给EventBus，同时接收EventBus上报的DeviceStatus、DeviceTwin和Reported等事件,并将这些信息写入sqlite中，最后将这些信息传送给EdgeHub。
4. EventBus：KubeEdge边缘部分与端部分交互的门户，通过订阅MQTT消息的方式将采集到的终端设备的数据上报给DeviceTwin；同时通过发布MQTT消息的方式将从DeviceTwin接收的相关指令下发到终端设备。
5. Edged：负责从MetaManager中接收pod、ConfigMap、Secret、Service、和Endpoint等资源的增、删、改、查信息，并根据事件信息进行相应操作，负责边缘节点上应用负载的整个生命周期，同时将边缘节点上的NodeStatus、podStatus等状态数据上报给MetaManager。
6. Edgemesh：KubeEdge边缘部分网络解决方案的实现，负责在同一节点上的pod间的通信和在不同节点上的pod间的通信。
7. CSI：负责从云下发到边缘的PV、 PVC和StorageClass等相关资源的增、删、改、查。
8. CNI：负责从云上下发到边缘的网络相关资源的增、删、改、查。

5.4 端部分组件

在KubeEdge中，Mppers具体架构如图5-4所示。

图5-4 KubeEdge端部分组件架构

由图5-4可知，KubeEdge端部分从与KubeEdge边部分EdgeCore对接的协议划分，可以分为通过MQTT协议进行对接的终端设备和通过HTTP进行对接的终端设备。

1）通过MQTT协议进行对接的终端设备：该方式是目前KubeEdge推荐的方式。通过该方式对接的终端设备，需要针对支持不同协议的设备开发相应的Mapper。Mapper负责将支持不同协议的设备的数据转换成MQTT协议支持的格式，并负责将MQTT协议格式的数据转换成指定的协议格式。Mapper与EdgeCore的EventBus进行交互时，需要使用MQTT Broker作为中间通道。在该方式下，目前只提供了支持bluetooth和modbus的Mapper。

2）通过HTTP进行对接的终端设备：该方式用来对接直接支持HTTP的终端设备，也可以针对支持不同协议的设备开发相应的Mapper。Mapper负责将支持不同协议的设备的数据转换成HTTP支持的格式，并负责将HTTP格式的数据转换成指定的协议格式。目前，该方式只通过EdgeCore的ServiceBus开放一个对接的入口，还没有相关对接实现和落地案例。

 「未完待续……」

点击下方标题可阅读技术文章

「连载」边缘计算（一）01-16：边缘计算系统逻辑架构（原理篇）
「连载」边缘计算（二）01-17：边缘计算系统逻辑架构（原理篇）
「连载」边缘计算（三）01-18：边缘部分原理解析（原理篇）