（接上篇）

端部分组件

在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开放一个对接的入口，还没有相关对接实现和落地案例。

云 边协同

云边协同机制是边缘计算系统边部分解决方案KubeEdge的关键。有了该机制，KubeEdge便可以适应边缘恶劣的网络环境，即在边缘节点与云失去联系时，边缘节点也可以独立工作，不影响边缘已有负载的正常运行。KubeEdge中的云边协同架构如图5-5所示。

图5-5 KubeEdge中的云边协同架构

由图5-5可知，云边协同涉及KubeEdge的云、边、端三部分，但主要工作由KubeEdge的EdgeCore组件来完成。云边协同是由EdgeCore中的MetaManager、DeviceTwin和Edgemsh三个功能模块共同完成的。各模块的具体功能和达到的效果如下。

1）MetaManager：负责将从云接收到的pod、ConfigMap、Secret、Service、和Endpoint等资源的增、删、改、查信息写入sqlite。当边缘节点和云之间的网络断开时，Edged在需要相关资源数据时，可以通过MetaManager从sqlite中读取，从而保障边缘节点上原有应用负载的正常运行。

2）DeviceTwin：负责将从云接收到的DeviceInstance、DeviceTwin和Desired等资源的增、删、改、查信息写入sqlite，在边缘节点和云之间的网络断开时，EventBus可以通过DeviceTwin从sqlite中读取，从而保障终端设备的正常运行。

3）Edgemsh：将从云下发到边缘的Service资源数据转换为DNS记录存在边缘节点，在边缘节点和云之间的网络断开时，运行在边缘节点的负载也可以通过访问域名实现同一节点上的pod间的通信和在不同节点上的pod间的通信，从而保障边缘节点上原有应用负载的正常运行。

「未完待续……」 点击下方标题可阅读技术文章