下面我们一起来学习KubeEdge的架构设计。首先我们来了解一下KubeEdge的背景，KubeEdge是华为开源的，在2019年捐赠给了CNCF基金会，目前源代码在github上面托管， 是作为云原生基金会孵化的首个边缘计算的产品，目前正处于孵化当中。下面我们来看一下KubeEdge的logo，
我们看一下它的logo像一种什么生物? logo非常的像章鱼，之所以类比就是章鱼在围捕狩猎的时候，比如说用它的触角去抓一些小鱼小虾，然后它们触角之间会高度的配合，它们会不会因为在抓鱼的时候自己把自己给缠绕起来？是不会的，是因为章鱼 40% 的神经元分布在它的头部，然后60%的神经元分在它的这些触角上面，所以说它是一个多个小脑，一个大脑构成了一个分布式计算的系统，而我们这个边缘计算和它真的非常的像，我们边缘计算也是一种分布式的计算，这种分布式的好处就是我们大部分这些重复的低级的操作，我们这个触角也就是我们的边缘侧来完成，而云端就处理一些核心的这些数据，从而减轻了云端的这些功耗。
下面我们就来看一下KubeEdge的架构设计图，看看是不是这种思想去设计的，这是KubeEdge的架构设计图，
了解KubeEdge的架构设计，对我们后续不管是使用KubeEdge，还是看它的实现源码都会非常的有帮助，KubeEdge的模块还是比较多的，我们可以从这个架构图可以看出，我这里将架构图拆分为三个部分来说， 第一个就是我们云边的通信方式， 第二个就是云端的架构设计， 第三部分就是边缘端的架构设计。
下面我们就来看一下云边的通信方式，从架构设计图可以看出在云端对应的 Cloud Hub 模块，以及边缘端的 Edge Hub 模块，它们之间是双向通信的，【websocket协议】然后其中Cloud Hub和 Edge Hub，它们就分别承担着云端和边缘端的网络代理的工作。现在就是说云端和边缘端的流量的出入都会经由此处，然后它们之间的通信方式就是微websocket协议，
其中云端就是websocket的服务端，运营端就是websocket的客户端，为什么要采用这种方式，难道HTTP不香吗？原因是因为HTTP只能由客户端向服务端发起请求，就类似于我们这种Restful API的风格的发送一些GET POST 或者是PUT DELETE 这种请求。而在云边协同的这种场景下，很多时候需要云端主动的向边缘端发起请求，而websocket刚好就能解决这个问题。
那么接下来的问题就是云边通信，通信的内容是什么？我这里将通信的数据分成了两个类别，就是配置数据和我们业务数据。
那么配置数据包括哪些？在云边协同的场景下，我们需要由云端向边缘端下发应用，因为应用都是以pod的方式运行的，所以说我们可以理解为云端向边缘端发送创建pod的指令，而这种创建pod的指令的数据就是要通过这种websocket完成下发的，同时边缘端布置pod完毕之后，边缘端还需要实时向云端上报 pod 的运行状态，以及它的运行的一些日志信息。由于这些数据适用于配置 我们这个业务，是一些底层的技术支撑的， 所以说我把它称之为是配置数据。
那么有配置数据对应的就是一些业务数据，从架构设计图当中可以看到，
这边有一个APP和MQTT两个部分，这两种方式的话就是边缘端接入设备的这种方式，接入之后就可以通过这两种方式与我们云端做数据的交互，而这里交互的数据就是与我们业务相关的一些数据，所以说称之为就是业务数据。 有关这两种数据交互的方式，这边有一个EventBus和ServiceBus，
然后就是云边的它一个通信方式的内容。
原文始发于微信公众号（基根奋斗营）：KubeEdge 云边通信方式
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/104792.html
