容器云资源弹性分配方法、装置、计算机设备及介质

技术领域

本发明涉及云计算领域，更具体地说是容器云资源弹性分配方法、装置、计算机设备及介质。

背景技术

城市化的快速发展导致灾害安全问题日益突出，城市灾害事故总量和破坏程度大幅增高，提升城市灾害防控能力已成为城市发展的重要使命之一。云资源弹性分配技术是灾害应急云计算中心的关键技术之一，通过建立合理的资源调度和分配方法，可以有效解决高并发场景下应用的稳定性和性能等问题。

随着数据规模和用户请求量的指数级增长，对灾害应急云计算中心提出了更高的服务质量要求。容器云以其能够提供更加轻量级的虚拟化解决方案，成为支撑高并发访问的主流云计算平台之一。与传统虚拟化云相比，容器云具有系统开销更小、部署应用启动速度更快等优点。调查表明，75％的页面访问者在加载时间超过4s时将不会再次访问该网站。

kubernetes作为目前主流的容器云资源管理平台，内置的响应式HPA弹性伸缩策略存在着资源供应过度、不足和响应延迟等问题，供应过度会增加成本和资源浪费，供应不足和响应延迟则会导致服务水平协议(SLA,service level agreement)违约，服务质量(Qos,quality of service)降低，影响用户访问体验。

发明内容

本发明的目的在于克服现有技术的不足，提供容器云资源弹性分配方法、装置、计算机设备及介质，以保证用户访问体验和平台服务的稳定性，避免资源浪费。

为实现上述目的，本发明采用以下技术方案：

一方面，容器云资源弹性分配方法，包括：

采集容器云处理平台的用户请求到达率；

抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据；

根据请求到达率采用预测模型对下一时刻的请求到达率进行预测；

根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量；

根据预测所需Pod服务单元数量进行资源分配。

其进一步技术方案为：所述抓取与用户请求相关的应用的Qos指标，包括：

采用kubelet组件内的cAdvisor组件采集CPU使用率和内存使用率数据；

通过prometheus获取请求响应时间数据；

采用prometheus适配器将prometheus采集到的请求响应时间数据转换成kubernetesAPI接口可以识别的格式；

通过指标聚合器将转换成kubernetes API接口可以识别的格式的请求响应时间数据再转换成与cAdvisor组件采集CPU使用率和内存使用率数据相兼容的数据。

其进一步技术方案为：所述根据请求到达率采用预测模型对下一时刻的请求到达率进行预测，所述预测模型为Prophet-TCN混合模型。

其进一步技术方案为：所述Prophet-TCN混合模型的计算公式为：

Y

其进一步技术方案为：所述根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量，包括：

获取预测的下一时刻的请求到达率值；

设定Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比和Qos最大服务单元数；

根据下一时刻的请求到达率值和设定的Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比以及Qos最大服务单元数计算出预测所需Pod服务单元数量。

其进一步技术方案为：所述根据预测所需Pod服务单元数量进行资源分配，包括：

若预测所需Pod服务单元数量大于当前Pod服务单元数量，则进行预测扩容。

其进一步技术方案为：所述根据预测所需Pod服务单元数量进行资源分配，还包括：

若预测所需Pod服务单元数量小于当前Pod服务单元数量，则进行响应式缩容。

第二方面，容器云资源弹性分配装置，包括采集单元、抓取单元、预测单元、计算单元以及资源分配单元；

所述采集单元，用于采集容器云处理平台的用户请求到达率；

所述抓取单元，用于抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据；

所述预测单元，用于根据请求到达率采用预测模型对下一时刻的请求到达率进行预测；

所述计算单元，用于根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量；

所述资源分配单元，用于根据预测所需Pod服务单元数量进行资源分配。

第三方面，一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述的容器云资源弹性分配方法步骤。

第四方面，一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令被处理器执行时，使得所述处理器执行如上述的容器云资源弹性分配方法步骤。

本发明与现有技术相比的有益效果是：本发明采集容器云处理平台的用户请求到达率；抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据；根据请求到达率采用预测模型对下一时刻的请求到达率进行预测；根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量；根据预测所需Pod服务单元数量进行资源分配。通过根据预测所需Pod服务单元数量进行资源弹性分配，实现对部署在容器云集群上的应用资源使高峰到来之前提前响应分配，减少了响应时间，提高了户访问体验和平台服务的稳定性，避免了资源浪费。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明技术手段，可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征及优点能够更明显易懂，以下特举较佳实施例，详细说明如下。

附图说明

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

图1为本发明具体实施例提供的容器云资源弹性分配方法的流程图；

图2为本发明具体实施例提供的容器云资源弹性分配装置的示意性框图；

图3为本发明具体实施例提供的一种计算机设备的示意性框图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

请参考图1，图1为本发明具体实施例提供的容器云资源弹性分配方法的流程图。

如图1所示，容器云资源弹性分配方法，包括以下步骤：S10-S50。

S10、采集容器云处理平台的用户请求到达率。

用户请求是指用户访问容器云处理平台上的应用的请求。

本实施例中，请求序列表征为排队等待服务的请求，将部署在kubernetes平台上的Pod服务单元表征为提供服务的服务台，构建成为M/M/m排队网络。假设请求到达和请求服务彼此独立，则等待时间和服务时间是相互独立的，服务请求按泊松流到达，服务单元对请求的服务时间服从负指数分布，那么，可认为容器云处理平台是一个用户请求到达率为λ，各服务Pod处理效率为μ且Pod服务单元数为s的M/M/s排队系统。用户请求到达率会采用roundrobin负载均衡算法到分发到Pod服务单元集上，同时也会将其持久化到PostgreSQL数据库。

S20、抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据。

用户请求相关的应用是指安装于容器云处理平台上的应用，当用户访问应用时，响应时间是访问用户体验最为关心的SLA指标。

在一些实施例中，步骤S20具体包括以下步骤：S201-S204。

S201、采用kubelet组件内的cAdvisor组件采集CPU使用率和内存使用率数据。

S202、通过prometheus获取请求响应时间数据。

S203、采用prometheus适配器将prometheus采集到的请求响应时间数据转换成kubernetesAPI接口可以识别的格式。

S204、通过指标聚合器将转换成kubernetesAPI接口可以识别的格式的请求响应时间数据再转换成与cAdvisor组件采集CPU使用率和内存使用率数据相兼容的数据。

对于步骤S201-S204，在本实施例中，CPU使用率和内存使用率负载信息主要采用kubelet组件内的cAdvisor组件采集，自定义请求响应时间指标通过prometheus获取微服务接口性能数据，由于两者数据格式不兼容，需要通过prometheus适配器将prometheus采集到的数据转换成kubernetesAPI接口可以识别的格式，最后通过指标聚合器转换成内存平均使用率、CPU平均使用率、请求平均响应时间和最大请求响应时间指标。

S30、根据请求到达率采用预测模型对下一时刻的请求到达率进行预测。

在本实施例中，预测模型为Prophet-TCN混合模型。

对于Prophet-TCN混合模型，其中，Prophet模型可以友好的解决时间序列的趋势性、周期性和季节性等难题，拟合速度较快，本质上是一个基于自加性模型的预测时间序列数据模型。时间卷积网络TCN型是一种用于解决时间序列预测的算法，根据云资源时间序列的特点，设计的一种加权分配策略，为prophet模型和TCN模型分配不同的权值，相比单一模型具有更高的预测精度。

Prophet-TCN混合模型的计算公式为：

Y

若设置α初始值为1，则TCN初始权值为0，令α每次以步长为0.01的递减方式进行迭代，计算Prophet-TCN模型的mae值，最终从所有遍历结果中取出最小的mae对应的权值α。

TCN模型作为神经网络的一种，训练调参需要很长时间，为了找到最优调参组合，使用TPOT(tree-basedpipelien optimization tool)调参思想优化TCN模型的参数组合，一方面减少了模型的训练时间，另一方面为xgboost模型找到了全局最优参数组合。TPOT是一种优化机器学习模型和自动选择模型参数的工具，也是自动化机器学习aotoML的一种具体应用，是网格搜索的扩展，实现在预测模型配置中调节各个参数并达到最佳设置，能够自动执行机器学习问题中的主要步骤，从而节省模型调参时间。

S40、根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量。

在一些实施例中，步骤S40具体包括以下步骤：S401-403。

S401、获取预测的下一时刻的请求到达率值。

S402、设定Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比和Qos最大服务单元数。

S403、根据下一时刻的请求到达率值和设定的Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比以及Qos最大服务单元数计算出预测所需Pod服务单元数量。

对于步骤S401-403，在本实施例中，设定Qos最大服务单元数目的是防止无限制分配资源。

预测所需Pod服务单元数量的计算所采用的公式为：

通过求得的ρ，ρ

通过计算请求到达不用等待的概率可计算得到请求有0到s*k个等待的概率，如果0到s*k个等待的概率中有超过Qos响应时间百分比的请求便能够在最大响应时间内被处理，从而可确定出所需Pod服务单元数量。

S50、根据预测所需Pod服务单元数量进行资源分配。

在一实施例中，步骤S50具体包括以下步骤：S501-S502。

S501、若预测所需Pod服务单元数量大于当前Pod服务单元数量，则进行预测扩容。

S502、若预测所需Pod服务单元数量小于当前Pod服务单元数量，则进行响应式缩容。

在本实施例中，如果预测所需Pod服务单元数大于当前Pod服务单元数，则进行预测扩容；考虑到通常需要在请求高峰到来之前完成扩容，以避免Pod初始化过程带来的响应延迟，因此扩容阶段采取提前一个时间单位扩容的策略，以让应用实例有充分的时间完成初始化。如果预测所需Pod服务单元数小于当前Pod服务单元数，考虑到提前触发缩容可能会导致资源不足，响应服务质量，因此，缩容阶段采取传统的响应式伸缩策略。

本发明通过根据预测所需Pod服务单元数量进行资源弹性分配，实现对部署在容器云集群上的应用资源使高峰到来之前提前响应分配，减少了响应时间，提高了户访问体验和平台服务的稳定性，避免了资源浪费。

图2为本发明实施例提供的容器云资源弹性分配装置的示意性框图；对应于上述的容器云资源弹性分配方法，本发明实施例还提供了容器云资源弹性分配装置100。

如图2所示，容器云资源弹性分配装置100，包括采集单元110、抓取单元120、预测单元130、计算单元140以及资源分配单元150。

采集单元110，用于采集容器云处理平台的用户请求到达率。

用户请求是指用户访问容器云处理平台上的应用的请求。

本实施例中，请求序列表征为排队等待服务的请求，将部署在kubernetes平台上的Pod服务单元表征为提供服务的服务台，构建成为M/M/m排队网络。假设请求到达和请求服务彼此独立，则等待时间和服务时间是相互独立的，服务请求按泊松流到达，服务单元对请求的服务时间服从负指数分布，那么，可认为容器云处理平台是一个用户请求到达率为λ，各服务Pod处理效率为μ且Pod服务单元数为s的M/M/s排队系统。用户请求到达率会采用roundrobin负载均衡算法到分发到Pod服务单元集上，同时也会将其持久化到PostgreSQL数据库。

抓取单元120，用于抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据。

用户请求相关的应用是指安装于容器云处理平台上的应用，当用户访问应用时，响应时间是访问用户体验最为关心的SLA指标。

在一些实施例中，抓取单元120包括采集模块、获取模块、转换模块、聚合模块。

采集模块，用于采用kubelet组件内的cAdvisor组件采集CPU使用率和内存使用率数据。

获取模块，用于通过prometheus获取请求响应时间数据。

转换模块，用于采用prometheus适配器将prometheus采集到的请求响应时间数据转换成kubernetesAPI接口可以识别的格式。

聚合模块，用于通过指标聚合器将转换成kubernetesAPI接口可以识别的格式的请求响应时间数据再转换成与cAdvisor组件采集CPU使用率和内存使用率数据相兼容的数据。

对于采集模块、获取模块、转换模块和聚合模块，在本实施例中，CPU使用率和内存使用率负载信息主要采用kubelet组件内的cAdvisor组件采集，自定义请求响应时间指标通过prometheus获取微服务接口性能数据，由于两者数据格式不兼容，需要通过prometheus适配器将prometheus采集到的数据转换成kubernetesAPI接口可以识别的格式，最后通过指标聚合器转换成内存平均使用率、CPU平均使用率、请求平均响应时间和最大请求响应时间指标。

预测单元130，用于根据请求到达率采用预测模型对下一时刻的请求到达率进行预测。

在本实施例中，预测模型为Prophet-TCN混合模型。

对于Prophet-TCN混合模型，其中，Prophet模型可以友好的解决时间序列的趋势性、周期性和季节性等难题，拟合速度较快，本质上是一个基于自加性模型的预测时间序列数据模型。时间卷积网络TCN型是一种用于解决时间序列预测的算法，根据云资源时间序列的特点，设计的一种加权分配策略，为prophet模型和TCN模型分配不同的权值，相比单一模型具有更高的预测精度。

Prophet-TCN混合模型的计算公式为：

Y

若设置α初始值为1，则TCN初始权值为0，令α每次以步长为0.01的递减方式进行迭代，计算Prophet-TCN模型的mae值，最终从所有遍历结果中取出最小的mae对应的权值α。

TCN模型作为神经网络的一种，训练调参需要很长时间，为了找到最优调参组合，使用TPOT(tree-based pipelien optimization tool)调参思想优化TCN模型的参数组合，一方面减少了模型的训练时间，另一方面为xgboost模型找到了全局最优参数组合。TPOT是一种优化机器学习模型和自动选择模型参数的工具，也是自动化机器学习aotoML的一种具体应用，是网格搜索的扩展，实现在预测模型配置中调节各个参数并达到最佳设置，能够自动执行机器学习问题中的主要步骤，从而节省模型调参时间。

计算单元140，用于根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量。

在一些实施例中，计算单元140包括获取模块、设定模块和计算模块。

获取模块，用于获取预测的下一时刻的请求到达率值。

设定模块，用于设定Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比和Qos最大服务单元数。

计算模块，用于根据下一时刻的请求到达率值和设定的Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比以及Qos最大服务单元数计算出预测所需Pod服务单元数量。

对于获取模块、设定模块和计算模块，在本实施例中，设定Qos最大服务单元数目的是防止无限制分配资源。

预测所需Pod服务单元数量的计算所采用的公式为：

通过求得的ρ，ρ

通过计算请求到达不用等待的概率可计算得到请求有0到s*k个等待的概率，如果0到s*k个等待的概率中有超过Qos响应时间百分比的请求便能够在最大响应时间内被处理，从而可确定出所需Pod服务单元数量。

资源分配单元150，用于根据预测所需Pod服务单元数量进行资源分配。

在本实施例中，如果预测所需Pod服务单元数大于当前Pod服务单元数，则进行预测扩容；考虑到通常需要在请求高峰到来之前完成扩容，以避免Pod初始化过程带来的响应延迟，因此扩容阶段采取提前一个时间单位扩容的策略，以让应用实例有充分的时间完成初始化。如果预测所需Pod服务单元数小于当前Pod服务单元数，考虑到提前触发缩容可能会导致资源不足，响应服务质量，因此，缩容阶段采取传统的响应式伸缩策略。

本发明通过根据预测所需Pod服务单元数量进行资源弹性分配，实现对部署在容器云集群上的应用资源使高峰到来之前提前响应分配，减少了响应时间，提高了户访问体验和平台服务的稳定性，避免了资源浪费。

上述容器云资源弹性分配装置可以实现为计算机程序的形式，该计算机程序可以在如图3所示的计算机设备上运行。

请参阅图3，图3是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500可以是服务器，其中，服务器可以是独立的服务器，也可以是多个服务器组成的服务器集群。

如图3所示，该计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述的容器云资源弹性分配方法步骤。

该计算机设备700可以是终端或服务器。该计算机设备700包括通过系统总线710连接的处理器720、存储器和网络接口750，其中，存储器可以包括非易失性存储介质730和内存储器740。

该非易失性存储介质730可存储操作系统731和计算机程序732。该计算机程序732被执行时，可使得处理器720执行任意一种容器云资源弹性分配方法。

该处理器720用于提供计算和控制能力，支撑整个计算机设备700的运行。

该内存储器740为非易失性存储介质730中的计算机程序732的运行提供环境，该计算机程序732被处理器720执行时，可使得处理器720执行任意一种容器云资源弹性分配方法。

该网络接口750用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备700的限定，具体的计算机设备700可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。其中，所述处理器720用于运行存储在存储器中的程序代码，以实现以下步骤：

采集容器云处理平台的用户请求到达率；

抓取与用户请求相关的应用的Qos指标，Qos指标包括Pod服务处理单元的CPU使用率、内存使用率和请求响应数据；

根据请求到达率采用预测模型对下一时刻的请求到达率进行预测；

根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量；

根据预测所需Pod服务单元数量进行资源分配。

在一实施例中：所述抓取与用户请求相关的应用的Qos指标，包括：

采用kubelet组件内的cAdvisor组件采集CPU使用率和内存使用率数据；

通过prometheus获取请求响应时间数据；

采用prometheus适配器将prometheus采集到的请求响应时间数据转换成kubernetesAPI接口可以识别的格式；

通过指标聚合器将转换成kubernetes API接口可以识别的格式的请求响应时间数据再转换成与cAdvisor组件采集CPU使用率和内存使用率数据相兼容的数据。

在一实施例中：所述根据请求到达率采用预测模型对下一时刻的请求到达率进行预测，所述预测模型为Prophet-TCN混合模型。

在一实施例中：所述Prophet-TCN混合模型的计算公式为：

Y

在一实施例中：所述根据预测的下一时刻的请求到达率计算预测所需Pod服务单元数量，包括：

获取预测的下一时刻的请求到达率值；

设定Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比和Qos最大服务单元数；

根据下一时刻的请求到达率值和设定的Qos最大平均请求响应时间、Qos平均请求响应时间、Qos响应时间百分比以及Qos最大服务单元数计算出预测所需Pod服务单元数量。

在一实施例中：所述根据预测所需Pod服务单元数量进行资源分配，包括：

若预测所需Pod服务单元数量大于当前Pod服务单元数量，则进行预测扩容。

在一实施例中：所述根据预测所需Pod服务单元数量进行资源分配，还包括：

若预测所需Pod服务单元数量小于当前Pod服务单元数量，则进行响应式缩容。

应当理解，在本申请实施例中，处理器720可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器720还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable GateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域技术人员可以理解，图3中示出的计算机设备700结构并不构成对计算机设备700的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在本发明的另一实施例中提供了一种计算机可读存储介质。该计算机可读存储介质可以为非易失性的计算机可读存储介质。该计算机可读存储介质存储有计算机程序，其中计算机程序被处理器执行时实现本发明实施例公开的容器云资源弹性分配方法。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为逻辑功能划分，实际实现时可以有另外的划分方式，也可以将具有相同功能的单元集合成一个单元，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。