CN114301809B - 一种边缘计算平台架构 - Google Patents

Abstract

本申请公开了一种边缘计算平台架构，包括：设于数据中心的管理节点，用于获取自身与各个边缘计算节点之间的网络状态，暂停对异常网络状态的边缘计算节点的健康监测服务；与管理节点通过公网连接的多个边缘计算节点，用于在确定自身处于异常网络状态时为发送请求的端侧设备提供计算资源，并存储节点信息和节点状态。本申请在边缘计算节点和管理节点之间断开连接时，管理节点暂停对异常网络状态的边缘计算节点的健康监测服务，避免获取大量错误日志，各个边缘计算节点具有边缘自治能力，为发送请求的端侧设备提供计算资源，保证响应及时。

Description

一种边缘计算平台架构

技术领域

本申请涉及边缘计算管理领域，特别涉及一种边缘计算平台架构。

背景技术

边缘计算平台，是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。其应用程序在边缘侧发起，产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。

已有的边缘计算平台，如华为智能边缘平台，其底层技术采用自研的KubeEdge，KubeEdge对Kubernetes进行了部分轻量化裁剪，但是由于改变了Kubernetes的源码及新增了一些库文件，导致Kubernetes产生了侵入式的修改，不能很好兼容各个开源版本，为适配原有***中的Kubernetes与后续升级、维护带来很大的不便利性。同时对于边缘自治和边缘化这两个重要的特性，华为智能边缘平台也暂时没有进行很好的支持。

因此，如何提供一种解决上述技术问题的方案是本领域技术人员目前需要解决的问题。

发明内容

本申请的目的是提供一种边缘计算平台架构，在边缘计算节点和管理节点之间断开连接时，管理节点暂停对异常网络状态的边缘计算节点的健康监测服务，避免获取大量错误日志，各个边缘计算节点具有边缘自治能力，为发送请求的端侧设备提供计算资源，保证响应及时。

为解决上述技术问题，本申请提供了一种边缘计算平台架构，包括：

设于数据中心的管理节点，用于获取自身与各个边缘计算节点之间的网络状态，暂停对异常网络状态的边缘计算节点的健康监测服务；

与所述管理节点通过公网连接的多个边缘计算节点，用于在确定自身处于所述异常网络状态时为发送请求的端侧设备提供计算资源，并存储节点信息和节点状态。

可选的，所述端侧设备，用于向所述管理节点发送所述请求，同时通过网关向对应的所述边缘计算节点发送请求。

可选的，所述请求包括服务请求或更新请求。

可选的，所述边缘计算节点，还用于当自身从所述异常网络状态重新与所述管理节点建立连接后，将所述节点状态和所述节点信息发送给所述管理节点。

可选的，所述管理节点，还用于获取各个所述边缘计算节点的关联性信息，基于所述关联性信息确定边缘集群，处于所述边缘集群中的各个所述边缘计算节点之间存在通信连接；

所述边缘集群中的每一所述边缘计算节点，用于当所述边缘集群与所述管理节点失联后，判断自身是否满足管理节点条件，若是，向所述边缘集群中的其他所述边缘计算节点广播管理节点更换信息。

可选的，所述管理节点条件为自身为CPU节点。

可选的，还包括：

设于所述每一边缘集群中的同步模块，用于获取其所在边缘集群中各个所述边缘计算节点的节点数据，利用istio与其他所述边缘集群同步所述节点数据。

可选的，所述管理节点，还用于基于错误日志确定网络状态。

可选的，该边缘计算平台架构还包括；

监测模块，用于为所述管理节点和每一所述边缘计算节点设置常驻进程服务，所述常驻进程服务用于监听与收发检测信息，并通过所述信息的完整度和延迟时间确定所述网络状态。

本申请提供了一种边缘计算平台架构，包括：设于数据中心的管理节点，用于获取自身与各个边缘计算节点之间的网络状态，暂停对异常网络状态的边缘计算节点的健康监测服务；与管理节点通过公网连接的多个边缘计算节点，用于在确定自身处于异常网络状态时为发送请求的端侧设备提供计算资源，并存储节点信息和节点状态。

在实际应用中，采用本申请的方案，当边缘计算节点和管理节点之间断开连接，管理节点暂停对异常网络状态的边缘计算节点的健康监测服务，避免获取大量错误日志，各个边缘计算节点具有边缘自治能力，为发送请求的端侧设备提供计算资源，保证响应及时。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请所提供的一种边缘计算平台架构的结构示意图；

图2为本申请所提供的另一种边缘计算平台架构的结构示意图；

图3为本申请所提供的一种边缘集群的结构示意图。

具体实施方式

本申请的核心是提供一种边缘计算平台架构，在边缘计算节点和管理节点之间断开连接时，管理节点暂停对异常网络状态的边缘计算节点的健康监测服务，避免获取大量错误日志，各个边缘计算节点具有边缘自治能力，为发送请求的端侧设备提供计算资源，保证响应及时。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参照图1，图1为本申请所提供的一种边缘计算平台架构的结构示意图，该边缘计算平台架构包括：

设于数据中心的管理节点1，用于获取自身与各个边缘计算节点2之间的网络状态，暂停对异常网络状态的边缘计算节点2的健康监测服务；

与管理节点1通过公网连接的多个边缘计算节点2，用于在确定自身处于异常网络状态时为发送请求的端侧设备提供计算资源，并存储节点信息和节点状态。

具体的，边缘计算平台架构包括云端、边缘端和终端，云端包括数据中心，管理节点1设置在数据中心，边缘端包括多个边缘计算节点2，终端包括端侧设备，端侧设备与边缘计算节点2连接。

其中，管理节点1通过公网与各个边缘计算节点2建立通信连接，现有技术中，端侧设备向管理节点1发送请求，管理节点1为该请求分配边缘计算节点2，由分配的边缘计算节点2为端侧设备提供计算支持，采用这种方案，一旦管理节点1和边缘计算节点2之间存在网络传输能力较弱、网络健康程度较弱或出现网络连接中断的问题，即管理节点1和边缘计算节点2的网络状态为异常网络状态，边缘计算节点2无法及时为该请求输出计算力，影响服务的运行。基于此，本申请设置了独立的网关，端侧节点可以通过网关将请求直接发送给对应的边缘计算节点2，以便边缘计算节点2可以持续为端侧设备提供边-端设备绑定状态与计算资源支持，保证边缘计算节点2在与管理节点1失联的状态下，依然不间断的输出计算力。

具体的，下面对如何判断网络传输能力较弱、网络健康程度较弱进行说明，传输能力较弱和健康程度较弱本质相同，由以下两种方法可以判断网络状态，一是通过Kubernetes原生节点健康检查机制，当节点组件、网络等出现问题，后台会产生错误日志，通过解析日志可以判断网络状态；二是通过本申请所提供的监测模块为管理节点1和边缘计算节点2分别设置常驻进程服务，负责监听与收发检测信息，并通过信息的完整度与延迟时间判断网络状态。管理节点1还可以获取造成异常网络状态的原因，具体可以通过Kubernetes原生节点监控检查机制提供的健康问题的汇报信息确定造成异常网络状态的原因。

具体的，考虑到当某一边缘计算节点2和管理节点1之间的网络状态为异常网络状态，管理节点1会收集到大量的错误日志及错误信息上报，为避免此问题出现，管理节点1通过上述方案确定异常网络状态对应的边缘计算节点2后，暂停对异常网络状态的边缘计算节点2的健康监测服务。

参照上文所述，当边缘计算节点2根据上述方案判断出自身处于异常网络状态时，如果接收到端侧设备通过网关发送的请求，则直接响应，为端侧设备输出计算力。

本实施例中，每一边缘计算节点2独立存储节点信息和状态，可以理解的是独立存储节点信息和状态时边缘计算节点2实现边缘自治的前提条件，边缘自治能够使离线的边缘计算节点2不至于在断网时失去推理服务计算能力，使边缘计算节点2能够依然保持与端侧设备的绑定，并且为从端侧设备传输来的信息或数据做计算。当边缘计算节点2和管理节点1之间的网络恢复时，边缘计算节点2独立存储的节点上的Pod信息、负载信息、操作信息等会同步给管理节点1，从而解决管理节点1与边缘计算节点2之间信息不一致的问题。其中，节点状态包括Ready、Unknown、NotReady等Kubernetes对节点状态的定义信息等，节点信息包括但不限于Pod信息、负载信及操作信息等。

可见，本实施例中，当边缘计算节点和管理节点之间断开连接，管理节点暂停对异常网络状态的边缘计算节点的健康监测服务，避免获取大量错误日志，各个边缘计算节点具有边缘自治能力，为发送请求的端侧设备提供计算资源，保证响应及时。

在上述实施例的基础上：

作为一种可选的实施例，请求包括服务请求或更新请求。

具体的，本实施例提供从数据中心到边缘端设备的服务下发与更新能力，应用协同实现边缘应用的统一注册接入，体验一致的分布式部署，集中化的全生命周期管理，来源于中心云的云服务与云生态伙伴所提供的能力，包括数据类、智能类、应用使能类的能力，通过云原生架构，提供服务接入框架，为边缘服务的分发订阅、接入、发现、使用、运维提供一整套流程。

具体的，下面对数据中心和边缘设备对于服务下发和更新进行说明，相对于数据中心，管理节点1将AI模型或镜像文件发送至边缘计算节点2，在边缘计算节点2使用docker将模型或镜像文件以Container(容器)形式拉起，推理请求发送至管理节点1，管理节点1依据模型类型将推理请求转发至边缘计算节点2，利用边缘计算节点2的计算资源(CPU、GPU、FPGA等)进行AI服务的推理计算；服务更新同上述流程，重新拉取AI模型或镜像，并以容器形式提供服务；边缘端的服务的基本流程基本同数据中心，不同点为推理请求发送给管理节点1的同时，还通过独立的网关配置直接发送至对应的边缘计算节点2，从而减少数据/请求转发带来的时间延迟。

作为一种可选的实施例，管理节点1，还用于获取各个边缘计算节点2的关联性信息，基于关联性信息确定边缘集群，处于边缘集群中的各个边缘计算节点2之间存在通信连接；

边缘集群中的每一边缘计算节点2，用于当边缘集群与管理节点1失联后，判断自身是否满足管理节点1条件，若是，向边缘集群中的其他边缘计算节点2广播管理节点1更换信息。

具体的，当某一业务中存在较多数量的边缘计算节点2时，管理节点1可以获取边缘计算节点2的信息，并且在边缘计算节点2在地理位置、承载应用与流量分配等使用场景中存在较多关联性信息时，平台能够根据以上指标对现有集群内(现有集群由数据中心的管理节点1和各个边缘计算节点2构成)的多个边缘计算节点2确定边缘集群，边缘集群处于边缘端，参照图2所示，节点1和节点2作为边缘集群，节点3作为独立的边缘计算节点。边缘集群中的各个边缘计算节点2之间存在通信连接，当边缘集群和数据中心的管理节点1失联后，在该边缘集群中重新确定管理节点1，由新的管理节点1代替数据中心的管理节点1实现对应的功能。由于边缘集群中的各个边缘计算节点2之间存在通信连接，可以相互传输各自的节点状态和信息，相互传输的数据包括但不限于节点负载信息、存储空间、资源利用率、节点类型等。其中，管理节点1条件包括节点类型为CPU节点，若无CPU节点，则可根据存储空间、资源利用率、节点负载信息来确定自身是否可以成为新的管理节点1，比如在没有CPU节点的基础上，若管理节点1条件为资源利用率最低，那么如果判定自身是所有边缘计算节点2中资源利用率最低的边缘计算节点2，则判定自身为新的管理节点1，新的管理节点1向该边缘集群中的其他各边缘计算节点2广播管理节点更换信息。

可以理解的是，当边缘集群中的某一边缘计算节点2与管理节点1之间的网络状态为异常网络状态，则该边缘计算节点2启动边缘自治。作为一种可选的实施例，还包括：

设于每一边缘集群中的同步模块，用于获取其所在边缘集群中各个边缘计算节点2的节点数据，利用istio与其他边缘集群同步节点数据。

具体的，本实施例所提供的边缘计算平台架构还可以提供边缘节点的服务与资源监控能力，在大规模的边缘集群中，需要确保边缘集群间的服务、数据的一致性，保证边缘集群在创建、启动和故障恢复时的状态同步，并且通过监控模块进行线上服务、***状态与计算资源的实时汇总与指标分析。

具体的，可以通过监控服务模块，采集服务的资源使用状态、服务状态、推理请求内容、请求计算返回值；通过Kubernetes原生监控组件对资源进行监控；通过同步模块采集边缘集群内每个边缘计算节点2的状态，参照图3所示，图3中以master表示管理节点1，以node表示边缘计算节点2。在不同边缘集群之间采用同步Istio Map数据，达到多集群微服务调用、创建、启动和状态信息同步的能力。

进一步的，本实施例所提供的边缘计算平台架构还可以提供边缘节点的异构设备接入能力，通过自研基于Kubernetes的统一插件(device plugin)实现对寒武纪MLU270、鲲云X9、高通AIC100、Xilinx FPGA Alveo U200、FPGA-F10A、FPGA-F37X芯片接入及调度的支持。

综上所述，本申请旨在解决如何利用非侵入式Kubernetes方案对边缘端设备与服务进行管理，并可以为边缘推理服务或计算平台提供相关功能和特性，例如边缘自治，边缘区域集群管理，边缘流量拓扑管理，沙盒容器，边缘无服务器和FaaS，以及异构资源支持，同时可以帮助用户解决在大量边缘和设备资源上的交付，运维和大型应用程序控制的问题。相比现有技术，除了具备Kubernetes零侵入以及边缘自治特性，还支持独有的分布式健康检查以及边缘服务访问控制等高级特性，极大地消减了云边网络不稳定对服务的影响，同时也很大程度上方便了边缘集群服务的发布与治理。本申请可以带来的有益效果如下：

可以实现工业互联网助力工业企业智能化转型，工业现场的边缘计算节点2必须具备一定的计算能力，能够自主判断并解决问题，云端也负责对数据传输监控和边缘设备使用进行管理；边缘计算服务助力传统能源产业向能源互联网升级，终端设备或者传感器具备一定的计算能力，能够对采集到的数据进行实时处理；把汇集的数据与云端进行交互，进行大数据和人工智能的模式识别、节能和策略改进等操作；智慧交通借助云边协同向车路协同发展，边缘节点集成地图***、交通信号信息和移动目标信息，为车辆提供决策、事故预警、辅助驾驶等服务；云计算中心收集边缘节点的数据，通过大数据和人工智能算法，为边缘节点下发合理的调度指令；边缘端能力引领安防智能化技术潮流，边缘计算节点2上搭载AI人工智能视频分析模块，弥补当前视频分析产生的时延大、用户体验较差的问题；通过云端可对边缘应用全生命周期进行管理，降低运维成本。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其他实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (7)

1.一种边缘计算平台架构，其特征在于，包括：

设于数据中心的管理节点，用于获取自身与各个边缘计算节点之间的网络状态，暂停对异常网络状态的边缘计算节点的健康监测服务；

与所述管理节点通过公网连接的多个边缘计算节点，用于在确定自身处于所述异常网络状态时为发送请求的端侧设备提供计算资源，并存储节点信息和节点状态；

所述管理节点，还用于获取各个所述边缘计算节点的关联性信息，基于所述关联性信息确定边缘集群，处于所述边缘集群中的各个所述边缘计算节点之间存在通信连接；

所述边缘集群中的每一所述边缘计算节点，用于当所述边缘集群与所述管理节点失联，判断自身是否满足管理节点条件，若是，向所述边缘集群中的其他所述边缘计算节点广播管理节点更换信息；

还包括：

设于所述每一边缘集群中的同步模块，用于获取其所在边缘集群中各个所述边缘计算节点的节点数据，利用istio与其他所述边缘集群同步所述节点数据。

2.根据权利要求1所述的边缘计算平台架构，其特征在于，所述端侧设备，用于向所述管理节点发送所述请求，同时通过网关向对应的所述边缘计算节点发送请求。

3.根据权利要求1所述的边缘计算平台架构，其特征在于，所述请求包括服务请求或更新请求。

4.根据权利要求1所述的边缘计算平台架构，其特征在于，所述边缘计算节点，还用于当自身从所述异常网络状态重新与所述管理节点建立连接后，将所述节点状态和所述节点信息发送给所述管理节点。

5.根据权利要求1所述的边缘计算平台架构，其特征在于，所述管理节点条件为自身为CPU节点。

6.根据权利要求1-5任意一项所述的边缘计算平台架构，其特征在于，所述管理节点，还用于基于错误日志确定网络状态。

7.根据权利要求6所述的边缘计算平台架构，其特征在于，该边缘计算平台架构还包括；

监测模块，用于为所述管理节点和每一所述边缘计算节点设置常驻进程服务，所述常驻进程服务用于监听与收发检测信息，并通过所述信息的完整度和延迟时间确定所述网络状态。