CN113703867B - 一种无服务计算中加速启动方法及系统 - Google Patents
一种无服务计算中加速启动方法及系统 Download PDFInfo
- Publication number
- CN113703867B CN113703867B CN202110985231.2A CN202110985231A CN113703867B CN 113703867 B CN113703867 B CN 113703867B CN 202110985231 A CN202110985231 A CN 202110985231A CN 113703867 B CN113703867 B CN 113703867B
- Authority
- CN
- China
- Prior art keywords
- container
- task
- user
- containers
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000001133 acceleration Effects 0.000 title claims abstract description 16
- 238000004364 calculation method Methods 0.000 title claims description 9
- 230000008569 process Effects 0.000 claims abstract description 32
- 238000002955 isolation Methods 0.000 claims abstract description 20
- 230000007246 mechanism Effects 0.000 claims abstract description 17
- 238000005070 sampling Methods 0.000 claims description 22
- 238000003860 storage Methods 0.000 claims description 18
- 238000004891 communication Methods 0.000 claims description 16
- 238000004064 recycling Methods 0.000 claims description 6
- 230000014759 maintenance of location Effects 0.000 claims description 2
- 238000010438 heat treatment Methods 0.000 claims 1
- 238000011084 recovery Methods 0.000 abstract description 4
- 230000004044 response Effects 0.000 abstract description 4
- 230000006870 function Effects 0.000 description 30
- 238000013459 approach Methods 0.000 description 6
- 238000012360 testing method Methods 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000005012 migration Effects 0.000 description 3
- 238000013508 migration Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000002474 experimental method Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 244000035744 Hura crepitans Species 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000002060 circadian Effects 0.000 description 1
- 238000007635 classification algorithm Methods 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000009499 grossing Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 238000001356 surgical procedure Methods 0.000 description 1
- 238000010792 warming Methods 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
- G06F9/4451—User profiles; Roaming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
一种无服务计算中加速启动方法及系统，涉及无服务计算技术领域，用以解决现有无服务计算中由于冷启动的存在而导致任务执行的响应时间过长的问题。本发明的技术要点包括：构建两层容器：用户容器和任务容器，每个用户容器对应一个用户设备，对于每个任务请求，容器启动的过程包括查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至用户容器；在用户容器中启动任务容器处理任务请求。本发明中用户容器负责隔离，任务容器负责执行任务，任务容器经过裁剪具有很低的启动延迟；利用过去调用规律预测未来启动来减少冷启动次数，进一步降低启动延迟，相比现有冷启动回收机制具有大幅度提升。
Description
技术领域
本发明涉及无服务计算技术领域，具体涉及一种无服务计算中加速启动方法及系统。
背景技术
无服务计算(Serverless)是随着当前云计算发展而出现的一种新的服务模型，无服务计算将运行的任务包装成一个自定义的代码。在大多数情况下，开发人员只需要关心他们的代码即可，因为事件队列、底层环境、动态扩展和调度等都是由服务商来处理，而服务商往往通过方便的容器服务向开发者提供功能支持。
在Serverless中，用户将代码上传到云端，云平台提供商为代码的运行提供一个调用方式(例如一个URL)。在过去的云计算中需要注意的问题，问题例如哪些资源需要分配、何时分配，以及保留多久，这些问题虽然仍然需要被处理，但它们被转移到了云平台提供商那里，云提供商在不影响用户体验地情况下对这些资源进行调度，调度造成的额外消耗不会直接向用户收费，其中调用函数的方式多种多样。
低延迟的服务使得支持需要极高可靠性和极低延时的用例成为可能，这些用例包括工业自动化、智能交通、智能电网、娱乐支持以及远程诊断和手术。相比于用户设备的性能一般较低，边缘计算集群往往可以由几台服务器组成，服务器上可以配置计算加速等设备来提高性能。同时边缘计算节点之间和到云的网络连接往往是通过有线高速网络连接，服务质量有很大的保证。而在Serverless平台上实现低延迟启动，有一个很大的阻碍是冷启动问题。冷启动是指当一个函数被触发，但其应用还没有按照平台的机制加载到内存中时，就会发生冷启动调用。当函数发生冷启动的情况时，平台为应用程序实例化一个工作实例，加载所有需要的运行时间和库，并调用该函数。
当冷启动发生时，会大大延长响应时间，从而带来一个巨大的延迟(相对于调用)。在Serverless平台中，每个函数的运行和调用往往需要一个“工作实例”来完成，目前绝大多数平台中都是以一个容器的概念呈现。公有云为了保证平台的稳健性，往往会使用带有虚拟内核的容器实现，因此带来额外的启动开销也可以因为云上丰富的资源而不会太过于影响性能。而私有云中的Serverless框架往往会选择简化的隔离方式，例如常见的基于cgroupfs实现的Docker。尽管容器一般比虚拟机启动要快不少，但它们的冷启动时间仍然是典型函数执行时间的一个重要组成部分，并且随着函数触发器并发性的增加而急剧增加。相对于函数的执行，这个过程可能需要很长的时间。对于128MB内存大小函数实例的创建，在Google Cloud Platform中冷启动的时间的中位数为493ms，Amazon Web Services下为265ms。同时，在云上的不到20％的应用程序负责99.6％的调用。而50％的函数平均执行时间小于1秒，最大执行时间小于3秒。可以看出，即使是在公有云有着丰富的服务器资源的情况下，函数冷启动时间在整个函数执行时间里面的比例都是不低的。因此对于冷启动的处理是提高Serverless平台服务质量的一个关键因素，缩减冷启动时间可以有效地提高函数调用速度和性能。
发明内容
鉴于以上问题，本发明提出一种无服务计算中加速启动方法及系统，用以解决现有无服务计算中由于冷启动的存在而导致任务执行的响应时间过长的问题。
根据本发明一方面，提出一种无服务计算中加速启动方法，该方法在无服务计算架构中构建两层容器：用户容器和任务容器，每个用户容器对应一个用户设备，且每个用户容器包含多个任务容器；对于每个任务请求，容器启动的过程包括：
步骤一、在存储包括节点网络信息和容器地址信息的数据库中查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至所述用户容器；
步骤二、在所述用户容器中启动任务容器处理任务请求。
进一步地，步骤一中创建对应的用户容器的过程包括：
步骤一一、设置镜像和系统资源，镜像里提供二进制程序和依赖库；所述系统资源包括网络资源；
步骤一二、为每个用户容器设置独立的网络栈、存储、虚拟IP地址、进程间通信，并将用户容器与用户设备相关联。
进一步地，步骤一一中对于系统资源中网络资源的设置为：构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离。
进一步地，步骤二中在所述用户容器中没有对应该任务请求的任务容器时，则首先创建任务容器，创建过程包括：
首先，加载用户容器的镜像并设置镜像目录；
然后，设置新数据目录，以存储任务容器新产生的数据；
然后，通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层；
然后，将创建的任务容器加入到overlay网络中；
然后，复用用户容器的系统资源到创建的任务容器中；
最后，通过OCI运行时规范将根据上述步骤配置的文件传递给Crun，以用于启动；其中，Crun表示一个基于cgroup实现的容器运行时。
进一步地，步骤二中对于已经创建的任务容器，通过记录并识别每个任务容器的调用模式，预先计算出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留。
进一步地，预先计算出每个任务容器在系统中的保持时间和预热权重的具体过程为：首先，统计上一个采样周期M分钟内每个任务容器被调用的次数，并通过下述公式计算获得第一估计值：
y1(t)＝a1xt-1+(1-a1)y1(t-1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计前一天每个任务容器被调用的次数，并通过下述公式计算获得第二估计值：
y2(t)＝a2xs-1+(1-a2)y2(t-1)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xs-1表示前一天被调用的次数真实值；
然后，统计固定值N分钟内每个任务容器被调用的次数，并通过下述公式计算获得第i个任务容器在系统中的保持时间estimate和预热权重score：
estimate(i)＝max(y1+y2+N,M)
score(i)＝log10(y1*y2+1)
其中，N<M。
进一步地，在步骤二任务容器处理完成任务请求后，在该任务容器不需要在系统中保留的前提下，根据设置的计时器在计时结束后对其进行回收。
根据本发明另一方面，提出一种无服务计算中加速启动系统，该系统包括：
任务执行模块，用于对于每个任务请求，启动容器处理任务请求，具体包括：在存储模块中查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至所述用户容器；在所述用户容器中启动任务容器处理任务请求；
用户容器创建模块，用于创建用户容器，具体包括：设置镜像和系统资源，镜像里提供二进制程序和依赖库；为每个用户容器设置独立的网络栈、存储、虚拟IP地址、进程间通信，并将用户容器与用户设备相关联；
任务容器创建模块，用于创建任务容器，具体包括：首先，加载用户容器的镜像并设置镜像目录；然后，设置新数据目录，以存储任务容器新产生的数据；然后，通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层；然后，将创建的任务容器加入到overlay网络中；然后，复用用户容器的系统资源到所述任务容器中；最后，通过OCI运行时规范将根据上述步骤配置的文件传递给Crun，以用于启动；其中，Crun表示一个基于cgroup实现的容器运行时；
任务容器回收模块，用于任务执行模块处理完成任务请求后，在该任务容器不需要在系统中保留的前提下，根据设置的计时器在计时结束后对其进行回收；
存储模块，用于存储节点网络信息和容器地址信息。
进一步地，所述用户容器创建模块中对于系统资源中网络资源的设置为：构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离。
进一步地，所述任务执行模块中对于已经创建的任务容器，通过记录并识别每个任务容器的调用模式，预先计算出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留；其中，预先计算出每个任务容器在系统中的保持时间和预热权重的具体过程为：首先，统计上一个采样周期M分钟内每个任务容器被调用的次数，并通过下述公式计算获得第一估计值：
y1(t)＝a1xt-1+(1-a1)y1(t-1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计前一天每个任务容器被调用的次数，并通过下述公式计算获得第二估计值：
y2(t)＝a2xt-1+(1-a2)y2(t-1)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计固定值N分钟内每个任务容器被调用的次数，并通过下述公式计算获得第i个任务容器在系统中的保持时间estimate和预热权重score：
estimate(i)＝max(y1+y2+N,M)
score(i)＝log10(y1*y2+1)
其中，N<M。
本发明的有益技术效果是：
本发明提出根据“用户”概念将容器分为两层容器，用户容器负责隔离，而任务容器负责执行任务，任务容器经过裁剪，具有很低的启动延迟；为了进一步降低启动延迟，通过利用过去规律预测未来的启动，从而减少冷启动次数，进一步降低启动延迟，相比现有平台的冷启动回收机制有了很大的提升。
附图说明
本发明可以通过参考下文中结合附图所给出的描述而得到更好的理解，所述附图连同下面的详细说明一起包含在本说明书中并且形成本说明书的一部分，而且用来进一步举例说明本发明的优选实施例和解释本发明的原理和优点。
图1是本发明用户容器和任务容器的结构示意图；
图2是本发明中任务容器的一个任务周期的状态转换示意图；
图3是本发明中任务状态和冷启动的关系示意图；
图4是本发明中重复启动相同的任务容器而得到的任务容器创建延迟统计图；
图5是本发明与原生Docker创建方式对于任务容器创建延迟的结果对比图；
图6是本发明冷启动发生次数对比统计图；
图7是本发明一种无服务计算中加速启动系统的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，在下文中将结合附图对本发明的示范性实施方式或实施例进行描述。显然，所描述的实施方式或实施例仅仅是本发明一部分的实施方式或实施例，而不是全部的。基于本发明中的实施方式或实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式或实施例，都应当属于本发明保护的范围。
本发明实施例提供一种无服务计算中加速启动方法，首先，抽象出用户设备识别的接口，用SessionID来代替，SessionID会出现在HTTP请求数据头部中，每一个SessionID会和一个用户实体关联，SessionID本身是可见的，SessionID的安全性由Authorization头的数据内容来保证。对于每个用户请求的流程：S1.查找对应的UE容器即用户容器，如果没有查找到UE容器则进行创建；S2.根据查找到的地址在etcd数据库中找到的地址进行转发；S3.在UE容器中启动或者复用任务容器。下面对任务执行的过程进行详细的介绍。
1.任务执行的容器结构
考虑到边缘计算中出现的用户角色，每个用户需要有自己的任务。本发明中的隔离机制的主要思路是：同一个用户之间的任务采用较为轻量的隔离机制，而不同用户之间采用较强的隔离机制。这样设计的原因是同一个用户的任务之间需要大量的数据传输，同时同一个用户任务之间互相泄露数据的风险不大，同时任务创建销毁的频率较高，因此可以使用隔离程度较低的容器技术。而不同用户之间的数据则需要增强隔离，避免数据泄露，同时用户对象创建销毁的频率较低。对于同一个用户的任务来说，可以一定程度地复用网络、存储等资源，因此可以使用较为复杂的隔离技术，提高隔离程度。
如图1所示，每一个连接到系统中的用户/用户设备(User Equipment)将会对应一个UE容器即用户容器，UE容器使用较强的隔离方式，用户数据在这个容器中完全可见。对于用户设备每个要调用的函数使用的容器叫做任务容器，每个用户容器包含多个任务容器。UE容器中直接执行的代码应该完全由平台开发商编写，UE容器需要负责任务容器的启动、回收、复用等生命周期的管理，任务容器之间的通信，用户数据的读写和任务容器之间的隔离。
而任务容器中需要提供最基本的函数运行的功能，和可选的初始化和回收。每个任务需要通过平台的规范读取、处理、返回数据。每个任务需要有自己的描述文件，描述文件里需要规定自己所需的权限和数据。
容器环境中使用了如下技术：
(1)Gvisor：Gvisor是一个容器运行环境。相比标准的runc，Gvisor提供了沙箱机制，可以有效地实现容器内程序和容器外的宿主机系统的隔离。Gvisor内设置了一个组件Sentry，Sentry会对容器内进程的系统调用做捕获和重新实现，角色类似于虚拟机内的内核，而真实的任务程序则运行在用户空间中。Gvisor提供了类似于虚拟机的隔离，但是和完整的虚拟机相比，有着更低的系统占用。在捕获系统调用上有两种机制，本发明使用的是KVM方式。使用Gvisor创建UE容器。
(2)Crun：Runc是由Docker开源的容器运行环境，也是Docker目前默认的运行环境，和Docker一样由Go语言实现。因为原生的Runc受制于go语言设计时本身的一些限制(例如fork/exec的语义问题)，Red Hat推出了类似于runc的功能的Crun，Crun表示一个基于cgroup实现的容器运行时。与Go语言不同，C语言默认不是多线程的，它是围绕fork/exec模型建立和设计的。它可以以更简洁的方式处理OCI运行时的这一部分。同样受益于C语言直接和内核交互，也不需要GMP模型等方式优化，crun本身带来的额外内存开销更小，更适合运行在低性能的环境。使用crun创建任务容器。
对于UE容器的启动，通过Docker Domain Socket创建基于gvisor的容器，每个容器的镜像是事先编译好的Ubuntu 20.04的镜像，镜像里提供了基本的二进制程序支持和依赖库支持。在容器的设置上，为每个容器设置独立的网络、存储、cgroup、进程间通信等命名空间。每个容器都有自己独立的网络栈、IP地址，有独立的存储，进程间通信一般也都会只发生在同一个容器中。容器之间不共享网络栈、存储等资源，容器内运行的程序和别的容器之间是隔离的。
在存储上，每个UE容器中将通过挂载的方式提供容器运行环境、用户任务库和用户数据。用户任务库放置了所有注册在当前MEC节点上的用户任务。为了避免UE容器异常退出，UE容器将只管理用户数据，但用户数据并不存储到容器的存储空间中，而是通过bind的方式由宿主机进行管理。
系统资源配置如网络配置方面，因为UE容器之间需要通信，构建了一个overlay网络，实现各个节点之间的通信。如前面关于隔离部分的描述中提到的，每个UE容器都会有自己的网卡、网络栈，因此每个UE容器也会有自己的虚拟的IP。虚拟的原因是这个IP并没有物理的网络设备做支持，完全通过宿主机实现。每个容器创建的时候，自动分配IP并且将自己的IP注册到etcd数据库中，帮助其他服务可以发现自己。容器内的任务可以共享这个IP，在被许可的情况下通过这个IP连接云、甚至监听服务。而这些通信数据全部都会到宿主机上完成。宿主机会将这些虚拟IP发出的包解析、做必要的修改，之后根据本地的路由表决定应该被转发到自身的另一个容器，或者是互联网/城际网。因为用户容器的数据会通过宿主机重新解析，因此这些网络地址将会和宿主机共享的不是同一段IP，例如这些容器可以属于10.244.0.0/16子网，而宿主机可以工作在10.10.0.0/16子网中，两个网络通过这种方式隔离开，将这两个部分分别称作为用户数据平面和控制平面。将用户数据平面和控制平面分离的方式，提高了系统的安全性，可以有序地控制两个网络之间的流量。同时抽象出虚拟的用户数据平面，用户数据平面成为了容器网络和物理网络中间的一层，后续扩展物理网络时容器本身的网络不会受影响，只需要通过一定技术将用户数据平面扩展到新的节点即可。
对于任务容器的启动，不通过Docker接口而是直接通过OCI规范构建容器启动。OCI运行时规范(OCI Runtime Spec)是由Linux Foundations推出的一个容器规范标准，包含实现对容器的标准操作所需的元数据。这包括要运行的流程、要注入的环境变量、要使用的沙箱功能等。OCI运行时规范启动可以避开Docker本身对于容器启动所做的预备工作，例如网络、用户命名空间等的配置，很大程度地降低启动时间。同时可以灵活限制每个容器的权限，例如能否访问网络、能否监听端口等，做好细粒度的权限控制。目前绝大多数的容器运行时都兼容OCI运行时规范。
具体到容器的配置，首先需要构建每个容器的文件系统。每个任务会有自己需要修改的系统参数、配置文件等。为了避免这些修改传导到UE容器，保障各个任务容器之间的隔离，每个容器的文件系统是独立于UE容器的。通过overlayfs组装容器，以pivot_root设置容器的根目录。具体为：加载用户容器的镜像并设置镜像目录；设置新数据目录，以存储任务容器新产生的数据；通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层。并将创建的任务容器加入到overlay网络中；复用用户容器的系统资源到任务容器中。
任务容器的Network Namespace和Cgroup Namespace等命名空间将会加入到UE容器中，减少创建命名空间的开销，简化网络结构避免过于复杂的网络结构的出现，同时更好的提升用户之间的隔离性。用户之间的数据泄露需要同时穿透Sentry和内核namespace的限制。容器的权限设置则会根据任务的描述文件进行配置。描述文件将需要指定是否需要网络连接、需要的capabilities等。
容器内的函数将会默认通过标准输入输出的方式进行传输。这种传入方法兼容于CGI接口，可以适配很多类型的任务。在Runc当中的标准输入输出不能像平时启动Docker一样直接绑定到用户的标准输入输出，因此UE容器中的ue-watchdog通过Domain Socket的方式来实现标准输入输出的交互。UE容器中的ue-watchdog将用户需要的数据传入到DomainSocket中，由用户任务处理后返回结果到同一个域套接字中，ue-watchdog再将这个请求转发回客户端。每一个Domain Socket都会对应一个任务容器，Domain Socket随着任务创建而生成。
在这一机制的帮助下，当任务不需要通过网络连接来完成任务执行时，就可以不再赋予这个任务网络权限。这些对于不会和数据库、云等做交互的任务来说会是很好的一个安全隔离方式。小到简单的返回当前时间，大到对图片进行一些裁剪、目标识别等，都可以用这种方式代替网络连接功能。同时每个任务也不再需要监听端口，从而避免了端口之间会发生冲突的问题。
对于每一个任务容器来说都会持续地监听标准输入输出并且对内容作出处理。任务容器不会复用为其他的任务容器，任务容器的回收由系统来估算等待时间，在等待时间内收到了新的请求则重置等待时间。而对于UE容器而言，在用户访问(或者即将访问)这个节点时，UE容器的生命周期就开始了。而当这个节点上的UE容器不再代表这个用户并且必需的迁移已经完成时。系统将会估算这个容器需要被删除或者是回收。对于需要回收的容器，系统将会清空这个UE容器对应的用户在本地存储的数据，和执行过程中产生的临时数据，同时重启这个容器。通过这一机制将会清空掉前一个用户所产生的所有状态，这个UE容器将会等待下一个用户的数据。
2.etcd数据库
每个节点之间通过etcd来保持配置的一致性。etcd保证每个节点看到的数据都是一样的。同时选取一部分节点共同持有一个etcd数据库，通过节点间共同的etcd数据库来保证数据写入正确。
Flannel网络组件通过etcd来互相同步网络数据。在网络配置的时候，Flannel将自己的网络信息(连接地址、连接方式、MAC地址等)写入etcd中。其他Flannel节点同样将自己的网络信息也写到etcd中。每个物理节点上的Flannel监听着新加入etcd的所有节点，及时更新自己的网络信息。
同时，etcd数据库中保存了所有的容器的位置信息。对于每个UE容器来说，etcd数据库保存了每个用户和对应UE容器在数据平面的地址。每当有请求来访问时，网关将会转发请求到对应地址，由UE容器完成后续的步骤。对于不存在于etcd中的地址，说明本地没有用户数据，需要在共有的数据库里查找该用户数据所在的位置并且请求迁移。
同时，节点间共同的etcd数据库则是负责同步用户所在的任务节点。当用户从一个节点迁移到另一个节点时，之前的节点需要退出所有任务后，主动地将地址修改为新的物理节点。新的物理节点在监听到这一改变后，才可以开始任务的创建。
3.任务容器创建和回收模型
对于每个任务周期，将容器分为三个动作(Action)：Init(初始化)、Run(代码处理)、Close(回收调用)和四个阶段Initializing,Running,Waiting和Closing.Init是开发者设置的用来初始化任务容器的，不接受参数，开发者要在这个阶段完成可能耗时的初始化过程，例如模型下载、与云端数据库建立连接等，因为存在迁移的情况，因此在这个阶段需要开发者判断资源是否有必要重新下载；Run是开发者设置的代码处理部分，在这个函数中需要任务从标准输入输出中读取数据并且处理；Close是开发者设置的回收调用，在容器被回收的时候进行必要的关闭连接等工作。任务状态的转换如图2所示。
需要注意的是，因为任务启动的Fork机制可以让一个任务在同一时间为同一个用户服务多次，因此尽管通过裁剪容器使得任务容器在冷启动的时候仍然可以表现出在很短时间内即可启动的特性，冷启动仍然会造成一定程度的资源消耗，因此对任务容器“保暖”是有必要的。通过让任务容器持续保留在内存中，可以很大程度上提高响应速度，改善用户的服务质量。
当用户请求到达系统的时候，如果任务容器正在监听任务，则可以很快地对请求进行响应。但是在边缘上，每个节点的性能又有限制，每个节点不能无限制地保存这每个任务的预热节点。任务的调用方式是多种多样的。根据数据的统计，有29％的调用是直接通过定时器方式调用的。调用流量表现出明显的昼夜模式和每周模式。因此在上述的数据结构基础上，本发明中对调度算法提出了如下需求：1)调度算法需要尽可能地降低平均每个任务冷启动带来的额外时间消耗。2)调度算法需要至少可以适配调用的昼夜规律。3)调度算法需要同时对无规律的调用表现出一部分的兼容，对于短时间内的调用爆发可以做到一定程度的缓冲。
本发明设计策略为根据每个应用程序的调用频率和模式进行调整。通过记录、识别应用程序的调用模式，给出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留。
本发明实施例中将M＝15分钟设置为一次采样周期，统计在一个采样周期内每个用户和系统整体任务被调用的次数。同时本发明中记录前一天一个任务每15分钟调用的次数。如图3所示，当请求在Warming、Initializating状态后访问节点时，发生的将会是热启动。而当请求在其他时间周期访问时，就不得不发生创建容器的过程。
每个容器的保留时间评分由三部分组成。第一部分是按照上一采样周期统计得到的值。第二部分是按照前一天得到的数据推测的值。第三部分是一个固定值N＝5分钟。对于每一个用户，计算每个任务的评分，取前W个任务。在这个W个任务中，如果容器已经在内存中则不进行热启动，如果W个容器不在容器池中则初始化该容器。除此之外的容器则应该开始回收。而对于其他的任务，在被触发后则会在系统上保留一定时间。
W的大小由节点的性能决定，原则上应该为节点能容纳的最大任务数量。节点的任务数量上限可以由公式估计。MemAvg和CpuAvg表示的是任务CDF分布90％处的值。
第一部分的数据通过一次平滑的方式进行预测。这个指数通过前一周期(前15分钟)的预测值、前一周期的真实值和参数a1来计算出结果。计算公式为公式(1)。
y1(t)＝a1xt-1+(1-a1)y1(t-1) (1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值。
第二部分的数据是按照前一天一次指数平滑的方式进行预测。首先绝大多数平台的Timer设置方式都是通过cron字符串的方式进行设置，而cron字符串通过制定周、日、时、分的值来实现。以"11***"这个字符串为例，这个cron表达式表示的是每天01:01执行一次任务，这种任务会在01:00-01:15的时间区间上表现出显著的数字特征。此处的公式类似第一部分数据。如公式(2)所示。
y2(t)＝a2xs-1+(1-a2)y2(t-1) (2)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xs-1表示前一天被调用的次数真实值。
同时，用户本身的行为也是具有一定的时间规律的。用户每天的上学、上班、回家等行为也会在一天的时间范围内具有周期性。因此这个指数通过前一天的预测值、前一天真实值和预测模型的值和参数a1来实现。
对于保持时间estimate和预热权重score的设置，分别为公式(3)和公式(4)所示。两个指标计算方式不同的原因是两种计算方式对突然增加的调用的敏感性不同。在实验中发现，存在一些函数的调用短期内大量增加，短周期相关的y1指标值极大而日周期相关的指标y2并不高，这些函数因为短时间调用量激增，往往保留在任务容器池中。而周期性的任务会因为这一原因score值不高，系统不能正确地根据日的周期性来提前启动容器。指数的方式可以降低对这类激增的敏感性。
estimate(i)＝max(y1+y2+5min,15min) (3)
score(i)＝log10(y1*y2+1) (4)
通过实验验证本发明的技术效果。
上述模型中，本发明中有四个参数a1、a2和M、N需要预先设置。其中，采样周期M＝15分钟；并通过在数据集上测试来确定另外三个值的确定方式。
微软Azure Functions Dataset是微软在2019年公开的一个数据集，里面的内容是Azure Cloud从2019年7月15日至7月28日期间Azure整个基础设施中所有函数调用的数据。数据集中包含了调用计数：每个函数，以1分钟为单位；每个函数的触发器；每个函数的执行时间：平均、最小、最大和样本数，每30秒的间隔，每个工作容器记录；以及每个应用程序的内存使用量：由运行时间每5秒采样一次，每分钟对每个工作者进行平均计算。平均、最小、最大和样本数，用于分配和常驻内存。
本发明通过重放的方式来进行实践，通过网格调参的方式来确定最后的值。首先确定公式来计算每种方法减少的冷启动次数；其次，将a1和a2分别设置0.2、0.5和0.8。对于日规律明显的任务，可以设置a1＝0.2,a2＝0.8；对于一些一次调用后下个周期(15分钟后)大概率还会继续需要的任务，可以设置a1＝0.8,a2＝0.2；在其他情况下可以设置a1＝a2＝0.5。对于N的确定，需要每个边缘节点上估计的用户数量。EUA-Dataset是澳大利亚墨尔本的一个边缘计算用户数据集，这个数据集统计了在墨尔本CBD等地方的边缘计算服务器节点数量和用户数量。根据EUA-Dataset的分析，在墨尔本的CBD，平均每个服务器有6.528个用户。根据Azure的调用数据集估计，任务的内存90％分位约为256MB。因此对于一个32核、64G内存的服务器而言，当48G的内存用作Serverless平台时，最多可以缓存192个容器。根据EUA数据集中的结果，每个节点上预期有8个用户，每个用户可以缓存24个任务。
为了测试应用本发明方法的容器启动速度，选取了一些实例进行测试。如表1所示，Resnet50是一个图片分类算法，Bitnami/tensorflow-resnet镜像通过Tensorflow将其实现，通过Flask完成请求，返回结果为分类结果。Imagemagick是一个对图片进行调整的工具，在这里使用OpenFaas开发的ImageMagick镜像，它的功能是缩放输入的图片。Minio和nginx的功能如表1所示。
表1实验容器属性
考虑到Minio本身是一个对象存储的实现，很少会通过一次性调用后销毁的方式提供服务，因此不测试Minio在多个任务同时存在时的启动优化。本发明中通过重复启动相同的任务容器来测试容器启动速度，测试平台是i5-8400处理器、8G内存、Ubuntu 18.04，测试结果如图4所示。从图4可以看到，随着容器数量增多，确实实现了容器创建延迟的上升，但是总体创建延迟保持在50ms下。图5对比了原生Docker创建方式，原生Docker的创建方式被用在常见的无服务计算运行时中，而本发明中采用的方式是OCI直接创建的方式，采用的数据是前述实验创建速度的均值。通过图5对比可以看到，原生Docker随着容器数量增多启动速度快速增加，而OCI直接创建增长速度缓慢。
图6是冷启动发生次数对比统计图，从图6中可以看到，本发明方法中通过预测启动有效的将冷启动次数从固定时间回收策略的5611次降低至a1＝0.5,a2＝0.2的1812次，降低比例最高达到了67.7％。可以观察到一个特点，即a1和a2的选择带来的效果差别不大。对于这个问题，分析有两方面原因：第一个原因是数据集的选择，a1参数主要影响的是短周期的规律性的权重，而a2影响的是长周期规律性的权重，当数据在这两个角度上的规律性保持一致时，因为score值最终是通过排序的方式得出，这两个参数的大小关系不会明显影响排序结果。
本发明另一实施例，提供一种无服务计算中加速启动系统，如图7所示，该系统包括：
任务执行模块110，用于对于每个任务请求，启动容器处理任务请求，具体包括：在存储模块中查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至用户容器；在用户容器中启动任务容器处理任务请求；
用户容器创建模块120，用于创建用户容器，具体包括：设置镜像和系统资源，镜像里提供二进制程序和依赖库；为每个用户容器设置独立的网络栈、存储、虚拟IP地址、进程间通信，并将用户容器与用户设备相关联；所述系统资源包括网络资源；
任务容器创建模块130，用于创建任务容器，具体包括：首先，加载用户容器的镜像并设置镜像目录；然后，设置新数据目录，以存储任务容器新产生的数据；然后，通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层；然后，将创建的任务容器加入到overlay网络中；然后，复用用户容器的系统资源到创建的任务容器中；最后，通过OCI运行时规范将根据上述步骤配置的文件传递给Crun，以用于启动；其中，Crun表示一个基于cgroup实现的容器运行时；
任务容器回收模块140，用于任务执行模块处理完成任务请求后，在该任务容器不需要在系统中保留的前提下，根据设置的计时器在计时结束后对其进行回收；
存储模块150，用于存储节点网络信息和容器地址信息。
其中，用户容器创建模块120中对于系统资源中网络资源的设置为：构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离。
其中，任务执行模块110中对于已经创建的任务容器，通过记录并识别每个任务容器的调用模式，预先计算出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留；其中，预先计算出每个任务容器在系统中的保持时间和预热权重的具体过程为：首先，统计上一个采样周期M分钟内每个任务容器被调用的次数，并通过下述公式计算获得第一估计值：
y1(t)＝a1xt-1+(1-a1)y1(t-1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计前一天每个任务容器被调用的次数，并通过下述公式计算获得第二估计值：
y2(t)＝a2xs-1+(1-a2)y2(t-1)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xs-1表示前一天被调用的次数真实值；
然后，统计固定值N分钟内每个任务容器被调用的次数，并通过下述公式计算获得第i个任务容器在系统中的保持时间estimate和预热权重score：
estimate(i)＝max(y1+y2+N,M)
score(i)＝log10(y1*y2+1)
其中，N<M。
本实施例所述一种无服务计算中加速启动系统的功能可以由前述一种无服务计算中加速启动方法说明，因此本实施例未详述部分，可参见以上方法实施例，在此不再赘述。
尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。
Claims (7)
1.一种无服务计算中加速启动方法，其特征在于，在无服务计算架构中构建两层容器：用户容器和任务容器，每个用户容器对应一个用户设备，且每个用户容器包含多个任务容器；对于每个任务请求，容器启动的过程包括：
步骤一、在存储包括节点网络信息和容器地址信息的数据库中查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至所述用户容器；其中创建对应的用户容器的过程包括：
步骤一一、设置镜像和系统资源，镜像里提供二进制程序和依赖库；所述系统资源包括网络资源，对于系统资源中网络资源的设置为：构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离；
步骤一二、为每个用户容器设置独立的网络栈、存储、虚拟IP地址、进程间通信，并将用户容器与用户设备相关联；
步骤二、在所述用户容器中启动任务容器处理任务请求；当所述用户容器中没有对应该任务请求的任务容器时，则创建任务容器，创建过程包括：
首先，加载用户容器的镜像并设置镜像目录；
然后，设置新数据目录，以存储任务容器新产生的数据；
然后，通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层；
然后，将创建的任务容器加入到overlay网络中；
然后，复用用户容器的系统资源到创建的任务容器中。
2.根据权利要求1所述的一种无服务计算中加速启动方法，其特征在于，步骤二中在创建任务容器后，通过OCI运行时规范将根据任务容器创建过程配置的文件传递给Crun，以用于启动；其中，Crun表示一个基于cgroup实现的容器运行时。
3.根据权利要求2所述的一种无服务计算中加速启动方法，其特征在于，步骤二中对于已经创建的任务容器，通过记录并识别每个任务容器的调用模式，预先计算出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留。
4.根据权利要求3所述的一种无服务计算中加速启动方法，其特征在于，预先计算出每个任务容器在系统中的保持时间和预热权重的具体过程为：首先，统计上一个采样周期M分钟内每个任务容器被调用的次数，并通过下述公式计算获得第一估计值：
yi(t)＝a1Xt-1+(1-a1)y1(t-1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计前一天每个任务容器被调用的次数，并通过下述公式计算获得第二估计值：
y2(t)＝a2xs-1+(1-a2)y2(t-1)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xs-1表示前一天被调用的次数真实值；
然后，统计固定值N分钟内每个任务容器被调用的次数，并通过下述公式计算获得第i个任务容器在系统中的保持时间estimate和预热权重score：
estimate(i)＝max(y1+y2+N,M)
Score(i)＝log10(y1*y2+1)
其中，N<M。
5.根据权利要求4所述的一种无服务计算中加速启动方法，其特征在于，在步骤二任务容器处理完成任务请求后，在该任务容器不需要在系统中保留的前提下，根据设置的计时器在计时结束后对其进行回收。
6.一种无服务计算中加速启动系统，其特征在于，包括：
任务执行模块，用于对于每个任务请求，启动容器处理任务请求，具体包括：在存储模块中查找该任务请求对应的用户容器，如果没有查找到则创建对应的用户容器；创建成功或查找到则将该任务请求转发至所述用户容器；在所述用户容器中启动任务容器处理任务请求；
用户容器创建模块，用于创建用户容器，具体包括：设置镜像和系统资源，镜像里提供二进制程序和依赖库；为每个用户容器设置独立的网络栈、存储、虚拟IP地址、进程间通信，并将用户容器与用户设备相关联；所述系统资源包括网络资源，对于系统资源中网络资源的设置为：构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离；
任务容器创建模块，用于创建任务容器，具体包括：首先，加载用户容器的镜像并设置镜像目录；然后，设置新数据目录，以存储任务容器新产生的数据；然后，通过overlayfs机制组装镜像目录和新数据目录，作为根目录；其中，镜像目录设置在底层，新数据目录设置在上层；然后，将创建的任务容器加入到overlay网络中；然后，复用用户容器的系统资源到创建的任务容器中；在创建任务容器后，通过OCI运行时规范将根据任务容器创建过程配置的文件传递给Crun，以用于启动；其中，Crun表示一个基于cgroup实现的容器运行时；
任务容器回收模块，用于任务执行模块处理完成任务请求后，在该任务容器不需要在系统中保留的前提下，根据设置的计时器在计时结束后对其进行回收；
存储模块，用于存储节点网络信息和容器地址信息。
7.根据权利要求6所述的一种无服务计算中加速启动系统，其特征在于，所述任务执行模块中对于已经创建的任务容器，通过记录并识别每个任务容器的调用模式，预先计算出每个任务容器在系统中的保持时间和预热权重，将预热权重按照从大到小的顺序排序，设置上述排序排名靠前的多个任务容器按照其各自对应的保持时间在系统中保留；其中，预先计算出每个任务容器在系统中的保持时间和预热权重的具体过程为：首先，统计上一个采样周期M分钟内每个任务容器被调用的次数，并通过下述公式计算获得第一估计值：
y1(t)＝a1xt-1+(1-a1)y1(t-1)
其中，a1为预设参数；y1(t-1)表示上一个采样周期被调用的次数预测值；xt-1表示上一个采样周期被调用的次数真实值；
然后，统计前一天每个任务容器被调用的次数，并通过下述公式计算获得第二估计值：
y2(t)＝a2xs-1+(1-a2)y2(t-1)
其中，a2为预设参数；y2(t-1)表示前一天被调用的次数预测值；xs-1表示前一天被调用的次数真实值；
然后，统计固定值N分钟内每个任务容器被调用的次数，并通过下述公式计算获得第i个任务容器在系统中的保持时间estimate和预热权重score：
estimate(i)＝max(y1+y2+N，M)
score(i)＝log10(y1*y2+1)
其中，N<M。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110985231.2A CN113703867B (zh) | 2021-08-26 | 2021-08-26 | 一种无服务计算中加速启动方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110985231.2A CN113703867B (zh) | 2021-08-26 | 2021-08-26 | 一种无服务计算中加速启动方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113703867A CN113703867A (zh) | 2021-11-26 |
| CN113703867B true CN113703867B (zh) | 2024-01-30 |
Family
ID=78654933
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110985231.2A Active CN113703867B (zh) | 2021-08-26 | 2021-08-26 | 一种无服务计算中加速启动方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113703867B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116501438A (zh) * | 2022-01-19 | 2023-07-28 | 华为技术有限公司 | 一种容器加载方法及装置 |
| CN115145683B (zh) * | 2022-06-22 | 2024-05-28 | 北京火山引擎科技有限公司 | 云服务实现方法及装置 |
| CN115277419B (zh) * | 2022-08-09 | 2024-01-26 | 湖南大学 | 一种无服务计算中加速网络启动方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105029A (zh) * | 2017-04-18 | 2017-08-29 | 北京友普信息技术有限公司 | 一种基于Docker技术的CDN动态内容加速方法及系统 |
| CN109062658A (zh) * | 2018-06-29 | 2018-12-21 | 优刻得科技股份有限公司 | 实现计算资源服务化的调度方法、装置、介质、设备及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200081745A1 (en) * | 2018-09-10 | 2020-03-12 | Nuweba Labs Ltd. | System and method for reducing cold start latency of serverless functions |
-
2021
- 2021-08-26 CN CN202110985231.2A patent/CN113703867B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105029A (zh) * | 2017-04-18 | 2017-08-29 | 北京友普信息技术有限公司 | 一种基于Docker技术的CDN动态内容加速方法及系统 |
| CN109062658A (zh) * | 2018-06-29 | 2018-12-21 | 优刻得科技股份有限公司 | 实现计算资源服务化的调度方法、装置、介质、设备及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113703867A (zh) | 2021-11-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102541295B1 (ko) | 온-디맨드 네트워크 코드 실행 시스템에서의 운영 체제 커스터마이제이션 | |
| US11836516B2 (en) | Reducing execution times in an on-demand network code execution system using saved machine states | |
| CN113703867B (zh) | 一种无服务计算中加速启动方法及系统 | |
| US10884722B2 (en) | Cross-environment application of tracing information for improved code execution | |
| US10528390B2 (en) | Idempotent task execution in on-demand network code execution systems | |
| US10725752B1 (en) | Dependency handling in an on-demand network code execution system | |
| US10713080B1 (en) | Request-based virtual machine memory transitioning in an on-demand network code execution system | |
| US11003377B2 (en) | Transactions in a decentralized control plane of a computing system | |
| US10884787B1 (en) | Execution guarantees in an on-demand network code execution system | |
| US10671377B2 (en) | Method to deploy new version of executable in node based environments | |
| CN111901294A (zh) | 一种构建在线机器学习项目的方法及机器学习系统 | |
| Kanso et al. | Serverless: beyond the cloud | |
| Mavridis et al. | Orchestrated sandboxed containers, unikernels, and virtual machines for isolation‐enhanced multitenant workloads and serverless computing in cloud | |
| CN111290839A (zh) | 一种基于openstack的iaas云平台系统 | |
| CN115086166A (zh) | 计算系统、容器网络配置方法及存储介质 | |
| Naranjo et al. | A serverless gateway for event‐driven machine learning inference in multiple clouds | |
| JP6385471B2 (ja) | 移行および遠隔ランタイム統合 | |
| CN110365743B (zh) | 一种基于Zookeeper实现的支持多种可自定义负载算法的负载均衡器实现方法 | |
| CN111104212A (zh) | 一种调度任务执行方法、装置、电子设备及存储介质 | |
| CN114860203A (zh) | 项目创建方法、装置、服务器及存储介质 | |
| US11121981B1 (en) | Optimistically granting permission to host computing resources | |
| CN115686811A (zh) | 进程管理方法、装置、计算机设备及存储介质 | |
| Kolb | Spawnpoint: Secure Deployment of Distributed, Managed Containers | |
| US20240103942A1 (en) | On-demand code execution data management | |
| WO2023274014A1 (zh) | 容器集群的存储资源管理方法、装置及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |