一种容器无感知启动方法及系统与流程

1.本发明涉及一种容器无感知启动方法及系统，属于云计算技术领域。


背景技术：

2.随着云计算技术的不断发展，无服务技术(serverless)已经成为云计算发展的必然趋势，企业只需向云供应商提供租用资源的费用，即可在有用户请求到来时占用资源调用服务，没有用户请求时不占用任何资源，按照调用次数、时长进行计费，相比传统的在线服务模式,无服务器计算极大降低了用户的使用成本，使用户可以完全不必关注服务器的配置问题从而简化了开发，以及提供了相比传统在线服务更好的伸缩性。然而，无服务器采用按需结构,在运行时会删除空闲的函数实例，因此再次调用该函数时，平台将重新启动一个新实例，并重新部署运行环境及软件代码，导致服务调用过程中产生大量的函数启动延迟，严重影响无服务器的响应能力。
3.因此，许多研究者针对无服务的冷启动问题提出了优化，比如oakes等人试图通过将函数所需包缓存在工作节点来减少云函数的启动时间，并提出共享包缓存，当一个云函数被分配给一个工作节点时，缓存器检查所需的包是否被缓存了，不足之处是大量缓存包占用了服务资源。mohan等人采用容器池策略减少冷启动延迟,他们通过预先运行空容器，从而函数触发时可直接从容器池中获取新的容器，无需重新启动新的容器，但是该方法采用静态的容器池容量，在函数用户请求少时会导致资源浪费。harter等人研究启动函数实例时所安装软件包，从而优先处理必要软件包实现快速的软件部署,非必须的软件包则延迟加载,虽然这种方法可以有效降低实例启动延迟，但仍旧无法避免冷启动的出现，难以满足快速响应型函数的要求。


技术实现要素：

4.本发明的目的在于克服现有技术中的不足，提供一种容器无感知启动方法及系统，能够降低无服务器计算调用的延迟。
5.为达到上述目的，本发明是采用下述技术方案实现的：
6.第一方面，本发明提供了一种容器无感知启动方法，所述方法包括：
7.接收并解析用户请求，以获取用户请求所需依赖的软件包；
8.以软件包的名称为关键字与本地数据库进行容器信息匹配，根据匹配结果将用户请求塞入冷备队列或热备队列；
9.对冷备队列和热备队列的用户请求进行安全认证，对通过安全认证的用户请求进行聚类分析，获取用户请求的指令类别；
10.若用户请求的指令来自热备队列，则在热备池中选择一个相似度最高且正在运行的容器作为目标容器执行用户请求的函数事件；
11.若用户请求的指令来自冷备队列，则在冷备池中新建一个容器，并将新建容器调度到热备池。
12.结合第一方面，进一步的，根据匹配结果将用户请求塞入冷备队列或热备队列的方法包括：
13.若容器信息匹配结果为空，则为该用户请求贴上属性值为0的标签，并将该用户请求塞入冷备队列；
14.若容器信息匹配到n个容器，则为该用户请求贴上属性值为n个容器的信息列表的标签，并将该用户请求塞入热备队列；
15.其中n＝1,2,3
……
；容器的信息列表包括：容器cpu信息、内存信息、磁盘空间信息、软件包数量以及每个软件包大小。
16.结合第一方面，进一步的，对通过安全认证的用户请求进行聚类分析的方法包括：
17.将所贴标签的属性值为0的用户请求划为一类，其优先级最低；
18.当用户请求所贴标签的属性值非0时进行二次聚类，任选两个属性值非0的用户请求ra、rb，计算ra、rb的依赖环境交集：
19.ra∩rb＝{s1…
,sm}，
20.其中，ra、rb表示用户请求；sm表示依赖环境的交集；
21.当依赖环境交集的值占总依赖环境的50％及以上时，将用户请求ra，rb划分为一类，这类用户请求优先级高于依赖环境交集的值在总依赖环境的占比低于50％的用户请求。
22.结合第一方面，进一步的，所述容器的相似度采用下述公式计算获取：
[0023][0024]
其中，zi表示容器i的相似度；w1 w2 w3＝1，ci、mi分别表示容器i的cpu使用率、内存使用率，t
si
表示容器i命中用户请求的软件包个数，md为t
si
内每个软件包大小，t表示热备池中容器的总数量，t、m分别为用户请求依赖软件包的个数、总大小。
[0025]
结合第一方面，进一步的，所述安全认证包括认证用户请求的来源、权限和功能。
[0026]
结合第一方面，进一步的，所述方法还包括对热备池进行动态监视，包括合并容器、分解容器和/或周期性启停容器。
[0027]
结合第一方面，进一步的，所述合并容器的方法包括：
[0028]
计算本地数据库容器信息表中两个容器的相似度；
[0029]
若相似度小于设定阈值，则合并两容器形成新的容器，并加入到本地数据库容器信息表中；
[0030]
其中，被合并的两个容器满足：合并前容器函数均处于非活跃状态；合并后，新的容器的cpu、内存及磁盘空间使用率均不超过相应的设定阈值。
[0031]
结合第一方面，进一步的，计算本地数据库容器信息表中两个容器的相似度之前分别对两个容器的属性值进行标准化处理及归一化处理。
[0032]
结合第一方面，进一步的，分解容器的方法包括：
[0033]
从本地数据库查询容器的软件包信息，获取至少包括软件包对应不同容器的安装次数在内的软件包属性值；
[0034]
按照软件包对应不同容器的安装次数的大小进行软件包排序，取出软件包对应不
同容器的安装次数不小于设定阈值的软件包；
[0035]
在热备池内启动一个新容器，将所取出的软件包调度到新容器内，更新本地数据库容器信息表，容器分解完毕。
[0036]
结合第一方面，进一步的，周期性启停容器的方法包括：
[0037]
查询热备池内的容器，根据容器在时间t
set
内被调用次数预测下次启停的时间段；
[0038]
容器预测的停止时间小于等于当前时刻，若容器处于运行状态，则停止容器运行，并预测容器下次启动时间；容器预测的启动时间小于等于当前时刻，若容器处于停止状态，立刻启动容器并预测容器下次停止时间；
[0039]
容器不处于预测的启停时间段内，查询该容器在时间t
set
内冷启动次数以及总启动次数，其中，冷起动次数表述该容器预测失败被动启动次数；
[0040]
在对容器预测失败的情况下，重新优化预测函数，并使用更新后的预测函数对容器下一个启停时间段进行预测。
[0041]
第二方面，本发明提供一种容器无感知启动系统，所述系统包括：
[0042]
解释器：用于接收并解析用户请求，以获取用户请求所需依赖的软件包；以软件包的名称为关键字与本地数据库进行容器信息匹配，根据匹配结果将用户请求塞入冷备队列或热备队列；
[0043]
处理器：用于对冷备队列和热备队列的用户请求进行安全认证，对通过安全认证的用户请求进行聚类分析，获取用户请求的指令类别；
[0044]
容器管理器：用于当用户请求的指令来自热备队列时，在热备池中选择一个相似度最高且正在运行的容器作为目标容器执行用户请求的函数事件；以及，用于当用户请求的指令来自冷备队列时，在冷备池中新建一个容器，并将新建容器调度到热备池。
[0045]
结合第二方面，进一步的，所述系统还包括资源监视器：用于对热备池进行动态监视，包括合并容器、分解容器和/或周期性启停容器。
[0046]
与现有技术相比，本发明所达到的有益效果：
[0047]
1.本发明针对无服务器计算场景下频繁创建容器导致资源竞争带来的性能瓶颈，引入了容器的置信度匹配策略，在热备池匹配到相似度最高的容器作为目标容器触发函数，减少依赖包加载时间和容器的初始化，提高平台整体性能；
[0048]
2.本发明针对现有无服务器计算平台在执行无服务器实例后立即销毁容器的问题，设计了一种热备池缓存容器策略，在执行完无服务器实例后不立即销毁容器，这样减少了容器启动、准备软件包的开销，提高了系统整体的资源利用率；
[0049]
3.本发明针对现有无服务器计算平台存在多个包含环境相同容器占用平台资源的问题，设计了一种容器合并策略，通过合并依赖环境相似的容器增加容器的命中下一次用户请求的概率，减少容器冷启动时间和资源浪费；
[0050]
4.本发明针对现有无服务器计算平台需要强制保持不活跃函数容器处于活跃状态，设计了一种容器周期性启停策略，通过预测容器下一个启动时间段，使容器在非启动时间段保持停止状态，减少了系统的内存、cpu等资源开销。
附图说明
[0051]
图1为本发明实施例提供的基于serverless平台的容器无感知启动系统的结构示
意图；
[0052]
图2为本发明实施例提供的基于serverless平台的容器匹配的方法流程图；
[0053]
图3为本发明实施例提供的基于serverless平台的容器合并的结构示意图；
[0054]
图4本发明的实施例提供的基于serverless平台的容器分解的结构示意图；
[0055]
图5为本发明实施例提供的基于serverless平台的周期性巡检启停容器的方法流程图。
具体实施方式
[0056]
下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本技术实施例以及实施例中的具体特征是对本技术技术方案的详细的说明，而不是对本技术技术方案的限定，在不冲突的情况下，本技术实施例以及实施例中的技术特征可以相互组合。
[0057]
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
[0058]
实施例一：
[0059]
本发明实施例提供一种容器无感知启动方法，基于serverless平台实现，具体包括如下步骤：
[0060]
步骤一：服务访问网关接收用户请求，用户请求包括函数依赖及函数源码，以获取用户请求所需依赖的软件包；所述软件包指启动函数实例时所安装软件包；
[0061]
步骤二：以软件包的名称为关键字与本地数据库进行容器信息匹配，根据匹配结果将用户请求塞入冷备队列或热备队列；
[0062]
本发明实施例使用树状结构存储容器信息和依赖的软件包，对用户请求需要的依赖软件包进行解析后，以软件包名称为关键字再本地数据库匹配容器信息，如果匹配信息为空，为用户请求贴上属性值为0的标签，并将该用户请求塞入冷备队列，等待调用转发；
[0063]
若匹配到n个容器，则为该用户请求贴上属性值为n个容器的信息列表的标签，并将该用户请求塞入热备队列；
[0064]
其中n＝1,2,3
……
，容器的信息列表包括：容器cpu信息、内存信息、磁盘空间信息、软件包数量以及每个软件包大小等。
[0065]
步骤三：对冷备队列和热备队列的用户请求进行安全认证，对通过安全认证的用户请求进行聚类分析，获取用户请求的指令类别；具体包括：
[0066]
处理器从冷备队列和热备队列读取request用户请求后，首先对用户请求做安全校验，包括校验信息的来源、权限、功能，若用户请求信息异常，过滤该用户请求并发出告警；
[0067]
一旦用户请求通过安全校验，则开始对用户请求进行聚类分析：
[0068]
所贴标签的属性值为0的用户请求为一类，其优先级最低；
[0069]
当用户请求所贴标签的属性值非0时进行二次聚类，具体为：假设非0的用户请求为ra，rb，则ra，rb所依赖环境的交集为：ra∩rb＝{s1…
,sm}；其中，ra表示、rb表示用户请求，sm表示依赖环境的交集；
[0070]
当依赖环境交集的值占总依赖环境的50％及以上时，将用户请求ra，rb划分为一类，这类用户请求优先级高于依赖环境交集的值在总依赖环境的占比低于50％的用户请
求；
[0071]
本发明实施例通过聚类分析对用户请求进行优先级划分，其优势在于同一类用户请求能够高概率的共享相同容器，减少容器内依赖包的加载和初始化。
[0072]
步骤四：若用户请求的指令来自热备队列，则在热备池中选择一个相似度最高且正在运行的容器作为目标容器执行用户请求的函数事件；容器的相似度可以采用下述公式计算获取：
[0073][0074]
其中，采用w表示权值，则w1 w2 w3＝1，ci、mi分别表示容器i的cpu使用率、内存使用率；t
si
表示容器i命中用户请求的软件包个数，md为t
si
内每个软件包大小，t表示热备池中容器的总数量，t、m分别为用户请求依赖软件包个数、总大小。
[0075]
步骤五：若用户请求的指令来自冷备队列，则在冷备池中新建一个容器，并将新建容器调度到热备池。
[0076]
如图2所示，是本发明实施例提供的一种容器快速匹配方法，包括如下步骤：
[0077]
步骤201：以软件包的名称为关键字与本地数据库进行容器信息匹配，根据匹配结果将用户请求塞入冷备队列或热备队列，热备队列的用户请求优先级高于冷备队列。
[0078]
步骤202：容器管理器接收来自热备队列的用户请求指令后，立刻执行相似度匹配算法，快速匹配到相似度最高且正在运行的容器作为目标容器。
[0079]
步骤203：容器管理器接收来自冷备队列的用户请求指令后，立刻在冷备区启动一个新容器作为目标容器。
[0080]
步骤204：容器管理器检查目标容器中已安装好的依赖包，与指令用户请求中需要的软件包对比，如果目标容器依赖环境大于或等于指令用户请求需要的软件包，则进入步骤209，否则进入步骤205。
[0081]
步骤205：本发明实施例支持本地软件包缓存，缓存的信息通过软件注册列表的结构存放在本地数据，处理器通过查询软件注册列表确认软件包是否已经被缓存。
[0082]
步骤206：软件注册列表未查询到软件信息，容器管理器向镜像仓库发起用户请求，拉取软件到本地容器内。
[0083]
步骤207：更新软件注册列表，缓存软件到本地节点。
[0084]
步骤208：软件注册列表可查询到软件信息时，直接从本地拉取软件到容器内。
[0085]
步骤209：目标容器内的依赖环境准备完毕后，执行函数触发器，完成用户请求执行的任务。
[0086]
本发明实施例提供的基于serverless平台的容器无感知启动方法，还包括对热备池进行动态监视，由资源监视器负责热备池内容器的创建、更新和关闭，包括合并容器、分解容器和/或周期性启停容器。
[0087]
所述合并容器是指合并属性相同的容器，其目的一是减少运行容器的数量，避免平台资源浪费，二是在于合并相同属性的容器后，使得容器包含的依赖环境越俱全，增加用户请求命中的概率，避免容器冷启动过程。
[0088]
下面对容器合并方法做出如下解释说明：
[0089]
假设本地数据库查询容器信息表为{d1,d2...,dn}，其中容器di属性值为{l1,l2...,lm}；
[0090]
计算容器di，dj的相似度z，当z小于设定的阈值时，合并容器di，dj形成新的容器d’ij
，并加入到本地数据库容器信息表中；合并容器后，容器的频数依次加一，重复软件包依赖值依次加一；
[0091]
需要说明的是：被合并的两个容器di，dj应当满足：合并前容器di，dj函数均处于非活跃状态；且，合并后，新的容器d’ij
的cpu使用率、内存使用率及磁盘空间使用率均不超过相应的设定阈值。
[0092]
容器di，dj的相似度z可以采用欧式几何检测计算，计算公式如下：
[0093][0094]
z值越小，表示容器di和容器dj相似度越高。
[0095]
容器属性值相差较大会导致z有误差，为提高准确度，在计算相似度之前可以标准化处理容器的属性值，若容器di属性值为{l1,l2...,lm}，标准化处理后的属性值为其中：表示第i个属性的特征值，m表示均值，s为方差；
[0096]
同时，为去掉不同属性值间在量纲上的差别，可以采用归一化处理容器的属性值，例如：容器di的属性值
[0097]
作为本发明的一种实施例，对于容器分解的具体方法可以包括如下步骤：
[0098]
从本地数据库查询容器的软件包信息，获取软件包属性值，软件包属性值包括：软件包对应不同容器的安装次数、软件包大小{s1,s2...,sm}、占用cpu大小{c1,c2...,cm}、占用内存大小{m1,m2…
,mm}等；
[0099]
在本发明实施例中按照软件包对应不同容器的安装次数的大小进行软件包排序，取出i个软件包的属性值，使剩余软件包的属性值小于设定的阈值；
[0100]
在热备池内启动一个新容器，将i个软件包调度到新容器内，新本地数据库容器信息表，容器分解完毕。
[0101]
下面结合具体实施例进一步对容器合并及分解的方法做出解释说明，如图3、图4所示，假定共有3个容器：d1、d2、d3，d1容器的权重为2，d2容器的权重为1，d3容器的权重为3，d1对应的软件包及依赖值{s1:3,s2:2,s3:1},d2对应的软件包及依赖值{s1:1,s2:1,s7:1}，d3对应的软件包及依赖值{s4:3,s5:2,s6:1}，假设初始状态中容器d3已经出现过载现象，容器d1、d2合并后不会出现过载现象。
[0102]
如图3所示，基于serverless平台的容器合并的方法可以为：
[0103]
步骤301：资源监视器检查到容器d1、d2有相同的软件环境，且判断出容器d1权重值大于容器d2权重值，立刻停止容器d2内软件包s1,s2运行。
[0104]
步骤302：容器d2内软件停止后的状态反馈到容器管理中。
[0105]
步骤303：容器d2内软件停止成功，且未出现异常现象，更新容器d1内软件包s1,s2依赖值。
[0106]
步骤304：将容器d2的软件包s7调度到容器d1内，同步更新容器d1的权重。
[0107]
步骤305：销毁容器d2，减少系统开销。
[0108]
本发明实施例针对现有无服务器计算平台在执行无服务器实例后立即销毁容器的问题，设计了一种热备池缓存容器策略，在执行完无服务器实例后不立即销毁容器，这样减少了容器启动、准备软件包的开销，提高了系统整体的资源利用率。
[0109]
如图4所示，基于serverless平台的容器分解流程如下：
[0110]
步骤320：从本地库查询容器d3的软件包信息，包括软件包依赖值、软件包大小、cpu、内存占用比例等；其中，软件包的依赖值越低，软件与容器的关系越脆弱，优先选择依赖值最小的软件作为分解对象，使得分解后剩余的软件所占资源小于设定的阈值；
[0111]
步骤321：容器管理器接收到分解指令后，快速启动一个新容器dn，并将d3内的s6软件调度到dn内，同时停止d3内s6软件运行，并更容器信息表。
[0112]
所述的周期性启停容器是以容器函数调用频率、容器cpu、内存使用率为特征值，构建多元线性回归模型预测容器启停时间；假设一组容器{d1,d2…
,dn}，在时间t
set
内被调用{f1,f2…
,fn}次，回归模型预测di再次被调用的时间为ti，在(0,ti)时间内di处于关闭状态，ti后再次启动容器，减少资源浪费。
[0113]
如图5所示，周期性巡检启停容器的方法包括如下步骤：
[0114]
步骤401：资源监视器查询热备池内的容器，根据容器在时间t内被调用次数预测下次启停的时间段。
[0115]
步骤402：容器预测的停止时间小于等于当前时刻，若容器处于运行状态，则停止容器运行，并预测容器下次启动时间；容器预测的启动时间小于等于当前时刻，若容器处于停止状态，立刻启动容器并预测容器下次停止时间。
[0116]
步骤403：容器不处于预测的启停时间段内，查询该容器时间t内冷启动次数以及总启动次数，其中，冷起动次数表述该容器预测失败被动启动次数。
[0117]
步骤404：在对容器预测失败的情况下，资源监视器会选择重新优化预测函数。
[0118]
步骤405：使用更新后的预测函数对容器下一个启停时间段进行预测。
[0119]
实施例二：
[0120]
如图1所示，本发明实施例提供一种基于serverless平台的容器无感知启动系统，可以用于实现实施例一所述的容器无感知启动方法，包括解释器、处理器和容器管理器；
[0121]
解释器：用于接收并解析用户请求，以获取用户请求所需依赖的软件包；以软件包的名称为关键字与本地数据库进行容器信息匹配，根据匹配结果将用户请求塞入冷备队列或热备队列；
[0122]
处理器：用于对冷备队列和热备队列的用户请求进行安全认证，对通过安全认证的用户请求进行聚类分析，获取用户请求的指令类别；
[0123]
容器管理器：用于当用户请求的指令来自热备队列时，在热备池中选择一个相似度最高且正在运行的容器作为目标容器执行用户请求的函数事件；以及，用于当用户请求的指令来自冷备队列时，在冷备池中新建一个容器，并将新建容器调度到热备池。
[0124]
本实施例中提供的容器无感知启动方法可以采用如图1所示的系统实现，包括解释器、处理器、容器管理器及资源管理器；具体包括如下步骤：
[0125]
步骤101：解释器作为系统对外访问的统一入口，负责接收解析http用户请求或其
他响应事件用户请求，并通过本地结构化的容器实例对比，决定将用户请求发送到冷备或热备队列；
[0126]
步骤102：冷备或热备队列负责把用户发起的任务用户请求接收过来缓存到消息队列中，防止用户请求丢失，同时支持多进程推送，提高系统吞吐量。
[0127]
步骤103：处理器用来处理冷备或热备队列推送的用户请求，当处理器处于空闲状态时,它会自动窃取负载最高队列中的用户请求。在整个系统中,处理器是负责平台高效运行的核心组件,它通过队列推送的用户请求信息，对用户请求进行标签化和聚类处理，同时采用优先级调度策略，按照标签属性值对用户请求进行优先级转发。
[0128]
步骤104：容器管理器是系统中的主要工作者，它负责管理平台中的资源，以及负责底层容器的操作，它通过容器相似度策略找出最合适的容器进行实例的部署，当未匹配到函数容器时，它会读取用户请求函数信息,以及创建附带函数代码和其依赖管理的相应资源,最终创建带有资源的容器。
[0129]
步骤105：容器管理器每新建一个新容器时，会实时跟踪容器函数的运行状态，当函数触发结束后，为减少每次创建容器带来的冷启动延迟，容器管理器选择将容器调度到热备池。
[0130]
步骤106：容器管理器通过相似度策略匹配到合适的函数容器，选择将用户请求指令调度到该容器内执行。
[0131]
本发明实施例提供的基于serverless平台的容器无感知启动系统，还包括资源监视器，资源监视器用于对热备池进行动态监视，包括合并容器、分解容器和/或周期性启停容器。
[0132]
资源监视器巡检到热备池有相同属性值的容器时，首先判断容器的运行状态以及合并后是否存在过载现象，判断通过后，资源监视器执行合并容器操作。
[0133]
资源监视器巡检到热备池存在容器资源超过阈值时，按照容器和软件依赖值关系分解容器。
[0134]
资源监视器合并容器、分解容器以及周期性启停容器的具体方法步骤可以参见实施例一，在此不做赘述。
[0135]
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。