边缘环境容器加速供给方法、系统、电子设备和存储介质

技术领域

本发明属于边缘计算技术领域，具体涉及一种边缘环境容器加速供给方法、系统、电子设备和存储介质。

背景技术

边缘计算作为一种新型计算模式一经推出便受到学术界及工业界的重视。对于边缘计算而言，边缘节点资源受限的特性使得容器技术能够与边缘计算有机结合。此外，容器高内聚、低耦合的特性也非常适合边缘环境，这也使得容器化逐渐成为了边缘计算平台的事实标准。将边缘计算与容器技术相结合存在优势如下：1)采用容器技术能够在边缘环境中快速部署或终止服务；2)容器技术为边缘设备提供了便捷的服务迁移和服务发现的方法，以便在边缘设备中管理服务；3)容器技术能够提高服务的容错能力，增强边缘节点的可用性和可靠性；4)边缘端可以对容器的镜像及所需的数据采取缓存策略，从而提高边缘服务的整体性能。

然而，引入容器技术为边缘计算提供边缘服务部署解决方案的同时，也随之产生了新的问题。容器的建立需要基于相应的镜像文件，而镜像文件的大小少则几十M，多则几G。由于边缘节点网络带宽有限，下载镜像的过程会产生大量时延，从而影响当前服务质量(英文全称为QualityofService，英文缩写为QoS)。

针对提高服务镜像的下载速度这一问题，已有多种方案来提高容器的供给速度。目前提出的解决方案都需要定制化镜像，或对应用容器引擎(英文名称为Docker)的下载机制进行源码级的重新设计并实现。例如一种名为FogDocker的机制，通过将镜像层中的基础文件构建成一个特殊的基础层，同时修改Docker的容器部署过程，从而提高镜像的下载速度。但由于其对每一个镜像都进行了定制化的修改，这在更接近公有云的边缘环境中难以实现；又如另一种容器部署加速方案DockerPI，其主要思想为采用多线程技术加速Docker镜像下载后的解压过程，并将镜像获取过程的下载、解压、落盘这一串行过程并行化，从而加速容器部署。但是这一方案对Docker进行了源码级的修改，破坏了Docker的整体性。

这些非普适性的加速策略难以在实际应用中普及推广。此外，传统的分布式存储策略主要针对视频、数据等单一文件，并未考虑到镜像层的复用这一重要特性。因此，如何在不改变Docker及镜像原有组织结构的基础上在边缘端加速镜像的下载速度是亟待解决的关键问题。

发明内容

本发明提供一种边缘环境容器加速供给方法、系统、电子设备和存储介质，以在不改变Docker及镜像原有组织结构的基础上在边缘端加速镜像的下载速度。

为解决上述技术问题，本发明第一方面提供一种边缘环境容器加速供给方法，包括：S1、应用容器引擎原生守护进程(英文名称为DockerDaemon)生成下载请求；S2、下载代理(英文名称为DownloadProxy)拦截所述下载请求；S3、查询所述下载请求的文件是否为镜像的描述清单(英文名称为Manifests)；若是，则将所述请求直接转发至云端镜像仓库；若否，则根据请求的SHA256值向中心节点发送请求查询镜像层文件所在位置，接受返回位置并重新构建下载请求；S4、查询所述镜像层文件是否缓存在边缘节点上；若否，则将所述请求直接转发至云端镜像仓库；若是，则将所述下载请求转发至相应边缘节点；S5、将请求的下载结果转发至DockerDaemon。

一些示例性实施例中，在所述步骤S1中，具体包括：S101、DockerDaemon接收到构建容器请求后会检索自身缓存，查找本地是否存在所述容器相应的镜像文件；若是，DockerDaemon直接获取镜像的Manifests表单；若否，DockerDaemon生成下载相应镜像的Manifests的GET请求，并将其发送至所述云端镜像仓库，以获取镜像的Manifests表单；S102、接收到返回的Manifests表单后，DockerDaemon对所述Manifests表单进行反序列化，并对所述Manifests表单中的fslayers字段进行轮询；DockerDaemon以所述fslayer字段作为镜像层唯一标识的SHA256值，在本地镜像层文件中查找是否存在能够复用的层文件；若是，DockerDaemon将所述请求直接转发至云端镜像仓库；若否，DockerDaemon为本地不存在的层文件生成下载请求，并向云端镜像仓库发送该请求。

一些示例性实施例中，在所述步骤S2中，具体包括：DownloadProxy对该所述下载请求进行拦截，并依据所述下载请求中携带的SHA256值生成相应的查询缓存位置请求，并将所述查询缓存位置请求转发至中心节点的任务处理模块。

一些示例性实施例中，在所述步骤S3中，具体包括：S301、中心节点的任务处理模块接到所述查询缓存位置请求后并转发至开源的轻量级分布式键值存储数据库(简称为ETCD数据库)，查找是否存在所述镜像层的相应位置信息；ETCD数据库将相应结果返回至中心节点的任务处理模块；其中，ETCD数据库以键值对的形式存储了缓存该镜像层的全部边缘设备的ID，镜像层的缓存位置存储在ETCD数据库的/location/路径下；S302、中心节点的任务处理模块拿取到所述结果后并返回至DownloadProxy；若自ETCD数据库中查找到所述镜像层的相应位置信息，则将Key-Value返回至DownloadProxy；若未在ETCD数据库中查找到所述镜像层的相应位置信息，则向DownloadProxy返回一个空值。

一些示例性实施例中，在所述步骤S4中，具体包括：当边缘节点的DownloadProxy接收到响应消息时，若所述响应消息为空值，DownloadProxy将下载请求直接转发至云镜像仓库，并将得到的镜像层文件交付至DockerProxy；若当所述响应消息不为空时，DownloadProxy构建新下载请求，并发送至相应的边缘节点，从而获取缓存在边缘集群中的镜像层tar.gz压缩文件。

一些示例性实施例中，在所述步骤S5中，具体包括：当DockerDaemon接收到相应请求层的tar.gz压缩文件后，采用Docker原有的解压方式及文件系统，将其解压并挂载至同一挂载点上，最终形成完整的镜像。

本发明第二方面提供一种边缘环境容器加速供给系统，该系统包括：云端存储层，所述云端存储层用于作为整个集群的集中式镜像仓库，并存储边缘系统中的全部镜像；重定向层，所述重定向层部署在中心节点端，用于存储边缘集群中边缘设备与其缓存层的对应关系，及对缓存镜像层放置位置进行集中管理；本地缓存层，所述本地缓存层部署在缓存节点端，用于存储实际缓存的文件及在Docker进行镜像下载时拦截镜像下载请求，并依据重定向层转发的镜像层位置信息，为Docker的镜像下载请求进行重定向。

一些示例性实施例中，所述重定向层包括ETCD、缓存放置模块和下载任务处理模块；所述ETCD部署至中心节点，用于作为开源的轻量级分布式键值存储数据库，存储镜像层存储位置的信息；所述缓存放置模块内置缓存放置算法，用于计算镜像层的缓存位置，并根据节点需求及节点间网络状况计算出整个边缘集群的缓存文件下载代价，以及通过分布式求解使得代价最小化；所述下载任务处理模块与所述ETCD通信连接，用于接收边缘节点转发的下载请求，并依据该请求从ETCD中读取相应的文件缓存位置信息，并将其返回至请求节点；所述本地缓存层包括DockerDaemon、DownloadProxy和本地仓库(英文名称为LocalRegistry)；所述DockerDaemon是Docker的原生守护进程，用于接收用户发送的请求，下载相应的镜像，并根据镜像构建相应的容器；所述DownloadProxy以容器的形式部署在边缘节点上，用于拦截DockerDaemon的镜像下载请求，依据请求向下载任务处理模块请求相应的镜像层存储位置，并根据返回的结果将下载请求重定向至云端镜像仓库或边缘缓存节点；所述LocalRegistry作为一个小型的镜像仓库，用于在边缘设备上存储分配到的边缘层数据。

本发明第三方面提供一种电子设备，其特征在于，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上述的边缘环境容器加速供给方法。

本发明第四方面提供一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的边缘环境容器加速供给方法。

本发明提供的技术方案至少具有以下优点：

本发明提供一种边缘环境容器加速供给方法、系统、电子设备和存储介质，该方法基于原生Docker的镜像下载机制，在保持Docker及镜像的完整性的同时，设计并实现了一种以层为粒度的镜像缓存机制，并采取对下载请求重定向的方式将镜像下载请求转发至相应的边缘缓存节点，对镜像下载速度进行提速，从而加快容器部署速度。此外，与传统的单节点缓存相比，该方案以分布式缓存的方式将所有边缘节点的存储资源整合起来，从而拓展了缓存内容范围，进一步为镜像下载速度提速。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，除非有特别申明，附图中的图不构成比例限制。

图1为本发明中基于分布式缓存的镜像加速下载方案(英文全称为ImageAccelerated DownloadSchemebasedonDistributedCache，英文简称为IADSDC)加速下载方案架构图；

图2为本发明中IADSDC针对镜像下载请求的处理流程图；

图3为本发明中IADSDC处理镜像下载请求的响应流程示意图；

图4为为本发明提供的一种电子设备的结构示意图。

具体实施方式

由背景技术可知，现有技术中存在着边缘节点受限于网络带宽，无法快速的从云端镜像仓库下载所需的镜像；且边缘节点存储容量有限，在节点本地仅能缓存极少部分的镜像文件的问题。

为克服背景技术中提到的镜像下载速度慢的问题，且增加方案的普适性，发明人经过研究在原有的Docker镜像下载流程的基础上设计了一种基于分布式缓存的镜像加速下载方案IADSDC。该方案采用了中心式设计，将边缘节点分为中心节点和缓存节点两种角色，缓存节点负责以层为粒度存储镜像，中心节点用于管理缓存元数据。此外，该方案将全部组件容器化的部署至边缘节点上，而不对Docker进行代码层面的更改，真正意义上的实现了高内聚低耦合，能够做到即插即用。解决了在边缘计算中加速容器镜像的下载速度，以及在存储空间受限的边缘集群放置镜像缓存的问题。

下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。

如图1、图3所示，本发明第一方面提供一种边缘环境容器加速供给方法，包括：

S1、DockerDaemon生成下载请求。

S2、DownloadProxy拦截所述下载请求。

S3、查询所述下载请求的文件是否为镜像的Manifests；

若是，则将所述请求直接转发至云端镜像仓库；

若否，则根据请求的SHA256值向中心节点发送请求查询层所在位置，接受返回位置并重新构建下载请求。

S4、查询所述层是否缓存在边缘节点上；若否，则将所述请求直接转发至云端镜像仓库；若是，则将所述下载请求转发至相应边缘节点；S5、将请求的下载结果转发至DockerDaemon。

一些示例性实施例中，在所述步骤S1中，具体包括：

S101、DockerDaemon接收到构建容器请求后会检索自身缓存，查找本地是否存在所述容器相应的镜像文件；

若是，DockerDaemon直接获取镜像的Manifests表单；

若否，DockerDaemon生成下载相应镜像的Manifests的GET请求，并将其发送至所述云端镜像仓库，以获取镜像的Manifests表单。

S102、接收到返回的Manifests表单后，DockerDaemon对所述Manifests表单进行反序列化，并对所述Manifests表单中的fslayers字段进行轮询；DockerDaemon以所述fslayer字段作为镜像层唯一标识的SHA256值，在本地镜像层文件中查找是否存在能够复用的层文件；

若是，DockerDaemon将所述请求直接转发至云端镜像仓库；

若否，DockerDaemon为本地不存在的层文件生成下载请求，并向云端镜像仓库发送该请求。

一些示例性实施例中，在所述步骤S2中，具体包括：

DownloadProxy对该所述下载请求进行拦截，并依据所述下载请求中携带的SHA256值生成相应的查询缓存位置请求，并将所述查询缓存位置请求转发至中心节点的任务处理模块。

一些示例性实施例中，在所述步骤S3中，具体包括：

S301、中心节点的任务处理模块接到所述查询缓存位置请求后并转发至ETCD数据库，查找是否存在所述镜像层的相应位置信息；ETCD数据库将相应结果返回至中心节点的任务处理模块；其中，ETCD数据库以键值对的形式存储了缓存该镜像层的全部边缘设备的ID，镜像层的缓存位置存储在ETCD数据库的/location/路径下。

S302、中心节点的任务处理模块拿取到所述结果后并返回至DownloadProxy；

若自ETCD数据库中查找到所述镜像层的相应位置信息，则将Key-Value返回至DownloadProxy；

若未在ETCD数据库中查找到所述镜像层的相应位置信息，则向DownloadProxy返回一个空值。

一些示例性实施例中，在所述步骤S4中，具体包括：

当边缘节点的DownloadProxy接收到响应消息时，若所述响应消息为空值，Download Proxy将下载请求直接转发至云镜像仓库，并将得到的镜像层文件交付至DockerProxy；若当所述响应消息不为空时，DownloadProxy构建新下载请求，并发送至相应的边缘节点，从而获取缓存在边缘集群中的镜像层tar.gz压缩文件。

一些示例性实施例中，在所述步骤S5中，具体包括：

当DockerDaemon接收到相应请求层的tar.gz压缩文件后，采用Docker原有的解压方式及文件系统，将其解压并挂载至同一挂载点上，最终形成完整的镜像。

本发明第二方面提供一种边缘环境容器加速供给系统，该系统包括：

云端存储层，所述云端存储层用于作为整个集群的集中式镜像仓库，并存储边缘系统中的全部镜像；其中，该镜像仓库采用了与DockerHub相同的API接口，用户端感觉不到在进行镜像下载时其下载过程与从DockerHub进行获取的不同。因此，在云-边结合的环境中，采用Harbor在云端建立私有镜像仓库，为整个边缘集群存储镜像。

重定向层，所述重定向层部署在中心节点端，用于存储边缘集群中边缘设备与其缓存层的对应关系，及对缓存镜像层放置位置进行集中管理。

本地缓存层，所述本地缓存层部署在缓存节点端，用于存储实际缓存的文件及在Docker进行镜像下载时拦截镜像下载请求，并依据重定向层转发的镜像层位置信息，为Docker的镜像下载请求进行重定向。

一些示例性实施例中，参见图2，所述重定向层包括ETCD、缓存放置模块和下载任务处理模块。

所述ETCD部署至中心节点，用于作为开源的轻量级分布式键值存储数据库，存储镜像层存储位置的信息。

所述缓存放置模块内置缓存放置算法，用于计算镜像层的缓存位置，并根据节点需求及节点间网络状况计算出整个边缘集群的缓存文件下载代价，以及通过分布式求解使得代价最小化。

所述下载任务处理模块与所述ETCD通信连接，用于接收边缘节点转发的下载请求，并依据该请求从ETCD中读取相应的文件缓存位置信息，并将其返回至请求节点。

继续参见图2，所述本地缓存层包括DockerDaemon、DownloadProxy和LocalRegistry。

所述DockerDaemon是Docker的原生守护进程，用于接收用户发送的请求，下载相应的镜像，并根据镜像构建相应的容器。具体的，Daemon的主要功能包括镜像管理、镜像构建、RESTAPI、身份验证、安全、核心网络以及编排。

所述DownloadProxy以容器的形式部署在边缘节点上，用于拦截DockerDaemon的镜像下载请求，依据请求向下载任务处理模块请求相应的镜像层存储位置，并根据返回的结果将下载请求重定向至云端镜像仓库或边缘缓存节点。

所述LocalRegistry作为一个小型的镜像仓库，用于在边缘设备上存储分配到的边缘层数据。其中，所述LocalRegistry由于其镜像采用了Docker官方发布的Registry:v2镜像，其内部核心路由机制与DockerHub相同，因此，该组件与DockerHub所采用的API接口相同，无需对下载请求进行重新设计。

参考图4，本申请另一实施例提供了一种电子设备，包括：至少一个处理器110；以及，与至少一个处理器通信连接的存储器111；其中，存储器111存储有可被至少一个处理器110执行的指令，指令被至少一个处理器110执行，以使至少一个处理器110能够执行上述任一方法实施例。

其中，存储器111和处理器110采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器110和存储器111的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器110处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器110。

处理器110负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器111可以被用于存储处理器110在执行操作时所使用的数据。

本申请另一实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例上述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各自更动与修改，因此本申请的保护范围应当以权利要求限定的范围为准。