一种应用部署方法、装置、设备及存储介质与流程

本申请涉及计算机技术领域，尤其涉及一种应用部署方法、装置、设备及存储介质。

背景技术：

随着云计算数据中心的规模不断增大，用户数量以及用户应用的数量都在不断增加，在每时每刻都需要将大量的应用部署到有限数量的物理服务器上。

由于物理服务器资源有限，而且不同应用对服务器资源的需求量各不相同，此时，如何将大量的应用合理地部署到物理服务器上，成为了云计算数据中心运营过程中面临的实际难题。

技术实现要素：

基于上述难题，本申请提出一种应用部署方法、装置、设备及存储介质，能够根据应用的资源需求，将应用部署到物理服务器上。

一种应用部署方法，包括：

从待部署应用集合中获取当前批次待部署的应用；

根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类；

基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上；其中，部署在同一物理服务器上的应用属于不同应用类。

可选的，所述基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上，包括：

确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数；

参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上。

可选的，所述确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数，包括：

分别计算所述当前批次待部署的各个应用中的、每两个属于不同应用类的应用之间的资源需求相关系数；

或者，

分别计算各个应用类之间的资源需求相关系数，并将任一应用类与另一应用类之间的资源需求相关系数，设定为该应用类中的任意一个应用与该另一应用类中的任意一个应用之间的资源需求相关系数。

可选的，所述参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上，包括：

在部署当前批次待部署的每个应用时，查询目标物理服务器中是否已部署与该应用属于同一应用类的应用；其中，所述目标物理服务器是从预设的至少一个物理服务器中选取的物理服务器；

如果已部署与该应用属于同一应用类的应用，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器；

如果未部署与该应用属于同一应用类的应用，则判断该应用与所述目标物理服务器中已部署的应用之间的资源需求相关系数是否小于预设的资源需求相关系数阈值；

如果小于预设的资源需求相关系数阈值，则将该应用部署在所述目标物理服务器上；

如果不小于预设的资源需求相关系数阈值，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器。

可选的，所述从待部署应用集合中获取当前批次待部署的应用，包括：

从待部署应用集合中获取延时敏感应用，并将所获取的延时敏感应用设定为当前批次待部署的应用；

所述方法还包括：

基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上。

可选的，所述基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上，包括：

在部署所述待部署应用集合中的未部署的每个应用时，确定目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过所述目标物理服务器的资源总量；其中，所述目标物理服务器是从所述预设的至少一个物理服务器中选取的物理服务器；所述共享资源量为该应用的平均资源需求量，与所述目标物理服务器中已部署的应用的附加资源需求量中的较大者；所述附加资源需求量为峰值资源需求量与平均资源需求量的差值；

如果不超过所述目标物理服务器的资源总量，则将该应用部署在所述目标物理服务器上；

如果超过所述目标物理服务器的资源总量，则从所述预设的至少一个物理服务器中选取下一个物理服务器作为目标物理服务器。

可选的，所述根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类，包括：

分别对当前批次待部署的各个应用的资源需求量进行二值化处理；

由二值化处理后的所述当前批次待部署的各个应用的资源需求量构成资源需求量集合；

通对所述资源需求量集合进行聚类处理，将所述当前批次待部署的各个应用划分为至少一个应用类。

一种应用部署装置，包括：

应用选择单元，用于从待部署应用集合中获取当前批次待部署的应用；

聚类处理单元，用于根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类；

第一部署单元，用于基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上；其中，部署在同一物理服务器上的应用属于不同应用类。

可选的，所述第一部署单元，包括：

系数确定单元，用于确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数；

部署处理单元，用于参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上。

可选的，所述系数确定单元确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数时，具体用于：

分别计算所述当前批次待部署的各个应用中的、每两个属于不同应用类的应用之间的资源需求相关系数；

或者，

分别计算各个应用类之间的资源需求相关系数，并将任一应用类与另一应用类之间的资源需求相关系数，设定为该应用类中的任意一个应用与该另一应用类中的任意一个应用之间的资源需求相关系数。

可选的，所述部署处理单元参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上时，具体用于：

在部署当前批次待部署的每个应用时，查询目标物理服务器中是否已部署与该应用属于同一应用类的应用；其中，所述目标物理服务器是从预设的至少一个物理服务器中选取的物理服务器；

如果已部署与该应用属于同一应用类的应用，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器；

如果未部署与该应用属于同一应用类的应用，则判断该应用与所述目标物理服务器中已部署的应用之间的资源需求相关系数是否小于预设的资源需求相关系数阈值；

如果小于预设的资源需求相关系数阈值，则将该应用部署在所述目标物理服务器上；

如果不小于预设的资源需求相关系数阈值，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器。

可选的，所述应用选择单元从待部署应用集合中获取当前批次待部署的应用时，具体用于：

从待部署应用集合中获取延时敏感应用，并将所获取的延时敏感应用设定为当前批次待部署的应用；

所述装置还包括：

第二部署单元，用于基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上。

可选的，所述第二部署单元基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上时，具体用于：

在部署所述待部署应用集合中的未部署的每个应用时，确定目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过所述目标物理服务器的资源总量；其中，所述目标物理服务器是从所述预设的至少一个物理服务器中选取的物理服务器；所述共享资源量为该应用的平均资源需求量，与所述目标物理服务器中已部署的应用的附加资源需求量中的较大者；所述附加资源需求量为峰值资源需求量与平均资源需求量的差值；

如果不超过所述目标物理服务器的资源总量，则将该应用部署在所述目标物理服务器上；

如果超过所述目标物理服务器的资源总量，则从所述预设的至少一个物理服务器中选取下一个物理服务器作为目标物理服务器。

可选的，所述聚类处理单元根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类时，具体用于：

分别对当前批次待部署的各个应用的资源需求量进行二值化处理；

由二值化处理后的所述当前批次待部署的各个应用的资源需求量构成资源需求量集合；

通对所述资源需求量集合进行聚类处理，将所述当前批次待部署的各个应用划分为至少一个应用类。

一种应用部署设备，包括：

存储器和处理器；

其中，所述存储器与所述处理器连接，用于存储程序；

所述处理器，用于通过运行所述存储器中存储的程序，实现上述的应用部署方法。

一种存储介质，所述存储介质上存储有计算机程序，该计算机程序被处理器运行时，实现上述的应用部署方法。

本申请提出的应用部署方法根据待部署的各个应用的资源需求量，对待部署的各个应用进行聚类处理，将待部署的应用划分为至少一个应用类，然后，基于待部署的各个应用所属的应用类，将待部署的各个应用部署到预设的至少一个物理服务器上，并且，本申请实施例控制部署在同一物理服务器上的应用属于不同的应用类。通过执行上述技术方案，可以将应用分配部署到物理服务器上，即实现应用向物理服务器的部署。同时，上述应用部署方法将资源需求量不相似的应用部署到相同的物理服务器上，而将资源需求量相似的应用部署到不同的物理服务器上，由此实现了对物理服务器资源的科学、高效利用。

进一步的，本申请实施例对应用的聚类处理，可以快速地确定待部署的各个应用之间的资源需求量的关系，利于提升应用部署效率。

附图说明

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

图1是本申请实施例提供的一种应用部署方法的流程示意图；

图2是本申请实施例提供的应用的资源需求波动曲线示意图；

图3是本申请实施例提供的另一种应用部署方法的流程示意图；

图4是本申请实施例提供的另一种应用部署方法的流程示意图；

图5是本申请实施例提供的另一种应用部署方法的流程示意图；

图6是本申请实施例提供的另一种应用部署方法的流程示意图；

图7是本申请实施例提供的一种应用部署装置的结构示意图；

图8是本申请实施例提供的一种应用部署设备的结构示意图。

具体实施方式

本申请实施例技术方案适用于将应用部署到物理服务器的应用场景，尤其是适用于将多个应用分布部署到多个物理服务器中的应用场景，采用本申请实施例技术方案，能够将应用快速、合理地部署到物理服务器上，以实现对物理服务器资源的科学利用。

需要说明的是，实际的应用部署处理，通常需要将应用先加载到应用虚拟机，然后再将应用虚拟机部署到物理服务器。本申请实施例技术方案的重点在于为待部署的应用确定目标物理服务器，也就是明确分配各个应用应该分别部署到哪个物理服务器上，在此基础上，待部署应用向物理服务器部署的具体过程，可以参照现有技术方案执行。例如，可以先将应用加载到应用虚拟机上，然后再将加载应用的应用虚拟机部署到目标物理服务器上等。

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

本申请实施例提供了一种应用部署方法，参见图1所示，该方法包括：

s101、从待部署应用集合中获取当前批次待部署的应用；

其中，上述待部署应用集合是指所有需要部署到物理服务器的应用构成的应用集合，并且，上述的应用，可以是任意类型的应用。例如，假设有100个应用需要部署到物理服务器，则该100个应用可构成一个待部署应用集合。

本申请实施例设定，分批次地对上述的待部署应用集合中的应用进行部署，即每次部署应用是部署一批应用。相应的，上述的当前批次待部署的应用，是指本次部署应用时所选出的，准备部署到物理服务器的各个应用。例如，假设每次部署应用时具体是部署10个应用，则当前批次待部署的应用，即为本次部署应用时从上述的待部署应用集合中选出的10个待部署的应用。

需要说明的是，上述的“从待部署应用集合中获取当前批次待部署的应用”，仅用于表达是从所有待部署应用中选出一定数量的应用作为当前批次待部署的应用。上述的“待部署应用集合”，仅仅是本申请实施例为便于表达对所有待部署的应用设定的名称，并不限定必须对所有待部署的应用构建集合。

s102、根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类；

具体的，上述的应用的资源需求量，是指应用对物理服务器的物理资源的需求量，例如对cpu资源、内存资源的需求量等。示例性的，可以将应用对物理服务器的某一项物理资源的需求量作为应用的资源需求量，例如将应用对物理服务器的cpu资源的需求量作为该应用的资源需求量等；或者，也可以将应用对物理服务器的各项物理资源的需求量的总和作为应用的资源需求量，例如将应用对物理服务器的cpu资源和内存资源的需求量的总和作为该应用的资源需求量等。作为一种示例性的实现方式，本申请实施例将应用对物理服务器的cpu资源的需求量作为应用的资源需求量，并以此为依据执行本申请实施例提出的应用部署方法。

另一方面，上述应用的资源需求量，可以是应用在某一时刻的资源需求量，也可以是应用在各时刻的资源需求量的平均值，或者是应用在运行的各个时刻的资源需求量等。其中，应用在运行的各个时刻的资源需求量最能真实反映应用的资源需求量，因此，本申请实施例将应用在运行的各个时刻的资源需求量，作为上述的应用的资源需求量。可以理解，应用在运行的各个时刻的资源需求量，反映了应用的资源需求量在时域上的变化情况。

本申请实施例分别确定上述的当前批次待部署的应用中的各个应用的资源需求量，也就是分别确定各个应用的资源需求量在时域上的变化情况，然后，以此为依据，对当前批次待部署的各个应用进行聚类处理，得到至少一个应用类。

对上述的各个应用进行基于资源需求量的聚类处理，可以将资源需求量相关的应用聚为一类，从而得到至少一个应用类，即，经过上述的聚类处理，属于同一应用类的各个应用的资源需求量相关，也就是属于同一应用类的应用的资源需求量在时域上的变化情况相类似，而属于不同应用类的应用之间的资源需求量不相关，也就是属于不同应用类的应用的资源需求量在时域上的变化情况差异较大。

例如图2所示，假设应用a、b、c、d、e的资源需求量分别如图2中的资源需求波动曲线a、b、c、d、e所示，从图中所示可以确定，应用a、c的资源需求量在时域上的变化情况相关(相似)，而应用b、d、e的资源需求量在时域上的变化情况相关(相似)。在此基础上，按照本申请上述实施例技术方案，根据应用a、b、c、d、e的资源需求量对应用a、b、c、d、e进行聚类时，会将应用a、c聚为一类，同时将应用b、d、e聚为一类，得到两个应用类。

可以理解，经过本申请实施例上述的聚类处理，可以将资源需求量相关的应用聚为一类，从而，当比较上述当前批次待部署的应用中的任意两个应用之间的资源需求量的相关性关系时，可以通过判断应用所属的应用类实现。例如，假设两个应用同属于相同的应用类，则可以确定该两个应用的资源需求量相关；假设两个应用分属于不同的应用类，则可以确定该两个应用的资源需求量不相关。

因此，本申请实施例上述的对当前批次待部署的应用的聚类处理，为判断当前批次待部署的应用之间的资源需求量的相关性提供了便利和依据。

示例性的，上述的聚类处理，可以应用现有技术中常规的聚类算法实现。

s103、基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上；其中，部署在同一物理服务器上的应用属于不同应用类。

具体的，在对上述当前批次待部署的各个应用进行聚类之后，可以确定各个应用所属的应用类，根据各个应用所属的应用类，可以确定各个应用的资源需求量相关性，进而可以根据各个应用的资源需求量相关性，对各个应用进行部署。

本申请实施例对上述各个应用的部署原则是，属于同一应用类的应用不能部署到相同的物理服务器上，也就是，部署在同一物理服务器上的应用属于不同的应用类。另外，一项很常规的部署原则是，部署到同一物理服务器上的所有应用的资源需求量之和，不能超过该物理服务器的可用资源总量。

基于上述部署原则，当部署上述当前批次待部署的每个应用时，先从预设的至少一个物理服务器中选择一个物理服务器作为目标物理服务器，然后查询在该目标物理服务器中是否已经部署与该应用属于相同的应用类的应用，如果该目标物理服务器中已经部署与该应用属于相同的应用类的应用，则该应用不能再部署在该目标物理服务器上；如果该目标物理服务器中没有部署与该应用属于相同的应用类的应用，则该应用可以部署在该目标物理服务器上。

可以理解，经过本申请实施例上述的部署处理，可以将属于同一应用类的应用部署到不同的物理服务器上，而属于不同应用类的应用则可以在不超出物理服务器的资源总量的基础上，部署到相同的物理服务器上。

结合本申请实施例步骤s102的介绍可以确定，属于同一应用类的应用之间的资源需求量具有相关性，属于不同应用类的应用之间的资源需求量不相关，因此，本申请实施例上述对应用的部署处理，使得部署到同一物理服务器的应用的资源需求量是不相关的。

进一步的，对于属于不同应用类的应用，还可以进一步计算其相互之间的资源需求量相关性，当需要将属于不同应用类的应用部署到同一物理服务器上时，可以进一步判断应用之间的资源需求量相关性是否足够小，基于该判断，将属于不同应用类的、资源需求量相关性足够小(资源需求量相关性足够小时认为资源需求量不相关)的应用部署到同一物理服务器上，从而保证将部署在同一物理服务器上的应用之间的资源需求量肯定不相关。

资源需求量不相关的应用在资源需求上具有峰谷互补性，该峰谷互补性是指应用的资源需求的波动曲线形状具有互补性，当一个应用的资源需求量处于峰值(波峰)时，另一个应用的资源需求量处于非峰值或谷值(波谷)，此时这两个应用的资源需求具有峰谷互补性。例如图2中的a和b所表示的资源需求波动曲线的形状具有互补性，则可知应用a和应用b在资源需求上具有很好的峰谷互补性。

可以理解，将资源需求量具有峰谷互补性的两个应用部署到同一个物理服务器上，同时，避免将资源需求量相关的两个应用部署到同一个物理服务器，可以实现对物理服务器资源的科学、高效的利用。因为一个应用的资源需求量处于峰值时，如果另一个应用的资源需求量处于谷值，则两者对物理服务器资源的需求量总和为一相对较小值；而如果一个应用的资源需求量处于峰值时，另一个应用的资源需求量也处于峰值，则两者对物理服务器资源的需求量总和为一相对较大值。

因此，在物理服务器的资源总量一定的情况下，采用本申请实施例上述的应用部署方法，可以在一个物理服务器中部署更多的应用，从而提高对物理服务器的资源利用效率。

理论上，直接计算待部署的应用之间的资源需求量相关性，也可以按照本申请实施例上述的应用部署方案实现应用向物理服务器的部署，并且，基于对待部署的应用之间的资源需求量的相关性，也可以实现部署在同一物理服务器上的应用属于不同的应用类。但是，本申请实施例上述对待部署应用的聚类处理，可以批量地区分出资源需求量相关的应用，以及资源需求量不相关的应用，按照应用所属的应用类对应用进行部署，可以减少计算应用之间的资源需求量相关性的计算工作量，从而能够提升应用部署效率。

通过上述介绍可见，本申请实施例提出的应用部署方法根据待部署的各个应用的资源需求量，对待部署的各个应用进行聚类处理，将待部署的应用划分为至少一个应用类，然后，基于待部署的各个应用所属的应用类，将待部署的各个应用部署到预设的至少一个物理服务器上，并且，本申请实施例控制部署在同一物理服务器上的应用属于不同的应用类。通过执行上述技术方案，可以将应用分配部署到物理服务器上，即实现应用向物理服务器的部署。同时，上述应用部署方法将资源需求量不相似的应用部署到相同的物理服务器上，而将资源需求量相似的应用部署到不同的物理服务器上，由此实现了对物理服务器资源的科学、高效利用。

进一步的，本申请实施例对应用的聚类处理，可以快速地确定待部署的各个应用之间的资源需求量的关系，利于提升应用部署效率。

作为一种示例性的实现方式，参见图3所示，本申请实施例还公开了，上述的基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上，包括：

s303、确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数；

具体的，基于本申请实施例对当前批次待部署的各个应用的聚类处理，可以将当前批次待部署的各个应用划分为至少一个应用类。对于属于同一应用类的各个应用，可以认为其相互之间的资源需求量非常相近，甚至可以认为是等同的，因此其相互之间的资源需求量的相关性最高。

而对于属于不同应用类的应用，本申请实施例进一步确定其相互之间的资源需求相关系数。其中，上述的资源需求相关系数，表示资源需求量的相关程度。如果两个应用的资源需求量相关系数较高，则表示这两个应用的资源需求量相关程度较高，也就是这两个应用的资源需求量在时域上的变化情况的相似度较高；如果两个应用的资源需求流量相关系数较低，则表示这两个应用的资源需求量相关程度较低，也就是这两个应用的资源需求量在时域上的变化情况的差异较大。

作为一种可选的实现方式，可以分别计算上述当前批次待部署的各个应用中的、每两个属于不同应用类的应用之间的资源需求相关系数，从而确定属于不同应用类的应用之间的资源需求相关系数。

示例性的，假设应用c1和c2的资源需求序列分别为{c11,c12,...,c1n}和{c21,c22,...,c2n}，其中，cit表示第i个应用在t时刻的资源需求量。

采用pearson相关系数计算公式，可以计算得到c1和c2之间的资源需求相关系数，该公式如下所示：

其中，表示c1的资源需求量平均值，表示c2的资源需求量平均值。

作为另一种优选的实现方式，本申请实施例分别计算各个应用类之间的资源需求相关系数，并将任一应用类与另一应用类之间的资源需求相关系数，设定为该应用类中的任意一个应用与该另一应用类中的任意一个应用之间的资源需求相关系数。

具体的，在对上述当前批次待部署的各个应用进行聚类后，本申请实施例以聚类得到的每个应用类为对象，计算每两个应用类之间的资源需求相关系数。

示例性的，对于聚类得到的每一应用类，计算该应用类中的各个应用在同一时刻的资源需求量平均值，作为该应用类在该时刻的资源需求量，由此可以得到该应用类在各时刻的资源需求量。按照该方法，可以分别确定各个应用类在各时刻的资源需求量，然后参照上述的pearson相关系数计算公式，可以计算得到每两个应用类之间的资源需求相关系数。

在此基础上，任意两个属于不同应用类的应用之间的资源需求相关系数，即可以用其各自所属的应用类之间的资源需求相关系数表示。也就是，将任一应用类与另一应用类之间的资源需求相关系数，设定为该应用类中的任意一个应用与该另一应用类中的任意一个应用之间的资源需求相关系数。

例如，假设按照本申请实施例计算确定应用类x与应用类y之间的资源需求相关系数为0.8，则应用类x中的任意一个应用与应用类y中的任意一个应用之间的资源需求相关系数均为0.8。

参照上述示例，可以分别计算确定上述的当前批次待部署的各个应用中的、任意两个属于不同应用类的应用之间的资源需求相关系数。

s304、参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上。

具体的，在计算确定属于不同应用类的应用之间的资源需求相关系数后，同样按照同一应用类中的应用不能部署到同一物理服务器的原则，对上述当前批次待部署的各个应用进行部署。

在部署过程中，如果两个应用属于同一应用类，则两个应用不能部署到同一个物理服务器上。

如果两个应用分别属于不同应用类，则可以进一步参考这两个应用之间的资源需求相关系数，确定是否可以将这两个应用部署到同一个物理服务器上。示例性的，如果这两个应用之间的资源需求相关系数小于设定的阈值，则可以将这两个应用部署到同一物理服务器上；如果这两个应用之间的资源需求相关系数不小于设定的阈值，则将这两个应用部署到不同的物理服务器上。

按照上述的部署原则，可以将当前批次待部署的应用分布部署到预设的至少一个物理服务器上。

本实施例中的步骤s301、s302分别对应图1所示的方法实施例中的步骤s101、s102，其具体内容请参见图1所示的方法实施例的内容，此处不再赘述。

作为一种示例性的实现方式，参见图4所示，本申请实施例还公开了，上述的参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上，具体包括：

s404、依次遍历当前批次待部署的各个应用；

具体的，对于当前批次待部署的各个应用，本申请实施例采用遍历的方式依次对每个应用进行部署，每遍历到一个应用时，从预设的至少一个物理服务器中选取物理服务器进行部署，直到将所有的应用都遍历完成，并且都部署到物理服务器上。

作为一种优选的实现方式，本申请实施例先将当前批次待部署的各个应用按照资源需求量由大到小的顺序依次进行排序，得到应用序列，然后，从该应用序列的第一个应用开始依次遍历其中的每个应用。

上述对应用的排序处理，可以使得后期的遍历和部署操作从资源需求较大的应用开始，也就是使得资源需求较大的应用优先被部署，如此可以保证应用，尤其是资源需求较大的应用的性能。

每遍历到上述当前批次待部署的应用中的一个应用时，执行步骤s405、查询目标物理服务器中是否已部署与该应用属于同一应用类的应用；

其中，上述目标物理服务器是从预设的至少一个物理服务器中选取的物理服务器。

示例性的，本申请实施例将上述预设的至少一个物理服务器组成服务器集合。当部署遍历到的应用时，从该服务器集合中的第一个物理服务器开始，依次将每个物理服务器设定为目标物理服务器，并且在每次设定一个目标物理服务器时，判断设定的目标物理服务器上是否可以部署该应用。

首先，查询在目标物理服务器中是否已经部署与该应用属于同一应用类的应用，也就是基于上述步骤介绍的对当前待部署的各个应用进行聚类得到的各个应用类，将该目标物理服务器中已部署的应用与该应用进行对比，判断该应用是否与该目标物理服务器中已部署的任意一个应用属于同一应用类。

如果该目标物理服务器中已部署与该应用属于同一应用类的应用，则执行步骤s406、从预设的至少一个物理服务器中选取下一个物理服务器作为目标物理服务器；

具体的，根据上述关于应用类划分的介绍可知，属于同一应用类的各个应用的资源需求量是相关的，因此，如果该目标物理服务器中已经部署与该应用属于同一应用类的应用，则该应用不能部署到该目标物理服务器上，因为资源需求量相关的应用部署在同一物理服务器时，会造成对目标物理服务器的资源利用率降低，造成一定程度的资源浪费。

此时，本申请实施例将上述的服务器集合中的下一个物理服务器设定为目标物理服务器，并且返回步骤s405，重新查询新选取的目标服务服务器中是否已部署与该应用属于同一应用类的应用，也就是重新判断新选取的目标物理服务器上是否可以部署该应用。

如果该目标物理服务器中未部署与该应用属于同一应用类的应用，则执行步骤s407、判断该应用与目标物理服务器中已部署的应用之间的资源需求相关系数是否小于预设的资源需求相关系数阈值；

具体的，上述步骤已经确定当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数，则通过查询已确定的属于不同应用类的应用之间的资源需求相关系数，可以分别确定该应用与目标物理服务器中已部署的各个应用之间的资源需求相关系数。以及，判断该应用与目标物理服务器中已部署的各个应用之间的资源需求相关系数是否均小于预设的资源需求相关系数阈值。

如果小于预设的资源需求相关系数阈值，也就是该应用与该目标物理服务器中已部署的每个应用的资源需求相关系数均小于预设的资源需求相关系数阈值，则执行步骤s408、将该应用部署在该目标物理服务器上；

在完成对遍历到的应用的部署后，返回步骤s404继续遍历下一个应用进行部署。

如果不小于预设的资源需求相关系数阈值，也就是该应用与该目标物理服务器中已部署的任意一个或多个应用的资源需求相关系数不小于预设的资源需求相关系数阈值，则返回执行步骤s406，即重新选取新的目标物理服务器，以及返回步骤s405重新判断是否可以将该应用部署到该新的目标物理服务器上。

另外，如果当部署遍历到的应用时，在上述的目标物理服务器中尚未部署应用，则可以直接将遍历到的应用部署到目标物理服务器上。

如果通过重复执行上述的步骤s405～s407，在预设的至少一个物理服务器中没有选出可以部署遍历到的应用的目标物理服务器，也就是未能将应用部署到上述预设的至少一个物理服务器上，则本申请实施例开启新的物理服务器，并将该应用部署到该物理服务器上。同时，将该新的物理服务器添加到上述预设的至少一个物理服务器构成的服务器集合中，在后期的应用部署中，该物理服务器可以被选定为目标物理服务器，继续部署其他应用。

进一步的，当每次将遍历到的应用部署到目标物理服务器上之后，本申请实施例还进一步计算该目标物理服务器的剩余资源量，如果该目标物理服务器的剩余资源量为零，或者足够小(不足以满足任何应用的资源需求)，则将该目标物理服务器移除上述的服务器集合，即在后期部署应用过程中，不能再将该物理服务器设定为目标物理服务器。

上述的向服务器集合增加新的物理服务器，或者将已经满负荷的物理服务器移除上述的服务器集合，可以使得应用部署得到保证，同时可以使得目标物理服务器的选择更高效。

本实施例中的步骤s401～s403分别对应图3所示的方法实施例中的步骤s301～s303，其具体内容请参见图3所示的方法实施例的内容，此处不再赘述。

作为另一种可选的实现方式，本申请实施例还公开了，上述的基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上的处理过程中，除了确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数之外，还包括：将同一应用类中的各个应用之间的资源需求相关系数设定为预设值，所述预设值大于预设的资源需求相关系数阈值。

基于上述的对同一应用类中的各个应用之间的资源需求相关系数的设定，以及对于不同应用类中的应用之间的资源需求相关系数的确定，本申请实施例确定了当前批次待部署的应用中的任意两个应用之间的资源需求相关系数。

在此基础上，上述的参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上，具体包括：

参考所述属于不同应用类的应用之间的资源需求相关系数，以及属于同一应用类的应用之间的资源需求相关系数，按照资源需求相关系数大于预设的资源需求相关系数阈值的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上。

具体的，由于本申请实施例对当前批次待部署的应用进行了应用类划分，因此，参考属于不同应用类的应用之间的资源需求相关系数，以及属于同一应用类的应用之间的资源需求相关系数，也就是参考当前批次待部署的各个应用之间的资源需求相关系数。

根据当前批次待部署的各个应用之间的资源需求相关系数，将各个应用部署到物理服务器上时，对于资源需求相关系数大于预设的资源需求相关系数阈值的应用不能部署到同一物理服务器上，也就是，部署到同一物理服务器上的各个应用之间的资源需求相关系数不大于预设的资源需求相关系数阈值。

由于本申请实施例将属于同一应用类中的各个应用之间的资源需求相关系数设定为大于预设的资源需求相关系数阈值的预设值，则按照上述的资源需求相关系数大于预设的资源需求相关系数阈值的应用不能部署到同一物理服务器上的原则，属于同一应用类中的应用不会部署到同一物理服务器上。

同时，对于属于不同应用类的各个应用，根据其相互之间的资源需求相关系数，按照资源需求相关系数大于预设的资源需求相关系数阈值的应用不能部署到同一物理服务器上的原则，将各个应用部署到物理服务器上，整体上达到了资源需求量相关的应用不会部署到同一物理服务器上、而部署到同一物理服务器上的应用具有不相关的资源需求相关系数的效果，实现了对物理服务器资源的合理利用。

作为另一种优选的实现方式，参见图5所示，本申请实施例在从待部署应用集合中获取当前批次待部署的应用时，具体是执行步骤s501、从待部署应用集合中获取延时敏感应用，并将所获取的延时敏感应用设定为当前批次待部署的应用。

其中，上述的延时敏感应用，是指对延时要求较高的应用，也就是在运行过程中需要以较小的延时完成运行的应用。对于延时敏感的应用，应该优先保证其资源需求，以便其顺畅运行，尽量降低应用运行时延。

因此，本申请实施例在部署待部署应用集合中的各个应用时，首先从待部署应用集合中筛选出延时敏感应用，作为当前批次待部署的应用。

示例性的，上述的从待部署应用集合中筛选延时敏感应用的处理，可以通过识别应用的类型或者鉴别应用的传输协议等实现，其处理过程较为常规，参照现有技术方案中常见的方案实现即可，本申请实施例不再详细介绍。

然后，对于上述的当前批次待部署的应用，参照图5所示的步骤s502、s503的处理，将其部署到预设的至少一个物理服务器上。其中，上述步骤s502、s503分别对应图1所示的方法实施例中的步骤s102、s103，其具体内容请参见图1所示的方法实施例的内容，此次不再重复。

在完成上述的当前批次待部署的应用的部署之后，也就是完成上述的待部署应用集合中的延时敏感应用的部署之后，对于上述的待部署应用集合中未部署的各个应用，则按照步骤s504进行部署：

s504、基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上。

其中，在上述步骤s501～s503已经实现延时敏感应用部署的基础上，上述的待部署应用集合中的未部署的各个应用，实际上就是待部署应用集合中的非延时敏感应用。

上述的非延时敏感应用，是指对延时要求较低的应用，在这类应用运行过程中，可以允许一定程度的延时。通常情况下，对于非延时敏感应用来说，在其资源需求得不到满足时发生一定程度的延时，属于可以接受的情况。

在通过前述步骤将各个延时敏感应用部署到预设的至少一个物理服务器上之后，对于该预设的至少一个物理服务器中的某一个物理服务器来说，其中可能还剩余部分资源未被利用，此时可以继续在该物理服务器上部署非延时敏感应用，以便实现对该物理服务器的空闲资源的利用。

当延时敏感应用与非延时敏感应用部署在同一物理服务器上时，应当优先保证延时敏感应用的资源需求，但是，非延时敏感应用也并不是可以无限延时的，所以在优先保证延时敏感应用的资源需求的同时，还要保证非延时敏感应用的基本资源需求。这就要求部署在同一物理服务器上的延时敏感应用与非延时敏感应用的资源需求总和应当在物理服务器的资源总量范围内，以保证该物理服务器能够满足延时敏感应用和非延时敏感应用的资源需求。

本申请实施例在部署上述的非延时敏感应用时，以各个非延时敏感应用的资源需求量为依据，以部署到同一物理服务器的延时敏感应用与非延时敏感应用的资源需求总和不超过物理服务器的资源总和为原则，将各个非延时敏感应用部署到预设的至少一个物理服务器上。

本申请实施例先部署延时敏感应用，后部署非延时敏感应用的处理顺序，可以保证延时敏感应用优先被部署到物理服务器，并且优先保证延时敏感应用的资源需求。同时，将延时敏感应用与非延时敏感应用共同部署到物理服务器上，能够实现对物理服务器资源的高效利用。

作为一种示例性的实现方式，参见图6所示，本申请实施例还公开了，上述的基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上，具体包括：

s604、依次遍历未部署的各个应用；

具体的，对于未部署的各个应用，本申请实施例采用遍历的方式依次对每个应用进行部署，每遍历到一个应用时，从预设的至少一个物理服务器中选取物理服务器进行部署，直到将所有的应用都遍历完成，并且都部署到物理服务器上。

作为一种优选的实现方式，本申请实施例先将未部署的各个应用按照资源需求量由大到小的顺序依次进行排序，得到未部署应用序列，然后，从该未部署应用序列的第一个应用开始依次遍历其中的每个应用。

上述对应用的排序处理，可以使得后期的遍历和部署操作从资源需求较大的应用开始，也就是使得资源需求较大的应用优先被部署，如此可以保证应用性能。

每遍历到未部署的应用中的一个应用时，执行步骤s605、确定目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过该目标物理服务器的资源总量；

其中，上述的目标物理服务器，是指从上述的预设的至少一个物理服务器中选出的物理服务器。

参见图4所示的方法实施例，本申请实施例将上述预设的至少一个物理服务器组成服务器集合。当部署遍历到的未部署应用时，从该服务器集合中的第一个物理服务器开始，依次将每个物理服务器设定为目标物理服务器，并且在每次设定一个目标物理服务器时，确定该目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过该目标物理服务器的资源总量。

上述已部署的应用的平均资源需求量，是指已经部署到该目标物理服务器的延时敏感应用在各个时刻的平均资源需求量。该平均资源需求量可以通过对应用在各个时刻的资源需求量求均值计算得到，当该目标物理服务器中部署多个延时敏感应用时，上述已部署的应用的平均资源需求量，具体是指多个延时敏感应用在各个时刻的资源需求量的平均值。

上述的共享资源量，是指遍历到的未部署的应用的平均资源需求量，与该目标物理服务器中已部署的应用的附加资源需求量中的较大者。

上述的目标物理服务器中已部署的应用的附加资源需求量，是指目标物理服务器中已部署的延时敏感应用的峰值资源需求量与平均资源需求量的差值，也就是应用的峰值资源需求量比平均资源需求量多出的部分。

一般的，应用的峰值资源需求量会比平均资源需求量大出十几倍甚至是几十倍，但是应用的峰值资源需求通常是瞬时的，只在某些时刻会出现峰值资源需求。为了保证延时敏感应用的正常运行，其峰值资源需求应当被满足，也就是部署该延时敏感应用的物理服务器的资源总量应当大于该延时敏感应用的峰值资源需求。

但是上述的延时敏感应用在正常运行过程中，并不会一直处于峰值资源需求状态，只是在某些时刻会瞬时达到峰值资源需求。在延时敏感应用处于非峰值资源需求状态的时候，在部署该延时敏感应用的物理服务器上会有大量的物理资源处于空闲状态，这部分空闲的物理资源的数量，也就是该延时敏感应用的附加资源需求量。

为了提高对这部分空闲的物理资源的利用，本申请实施例将其分配给非延时敏感应用。由于非延时敏感应用可以允许一定程度的延时，所以当延时敏感应用处于峰值资源需求时，上述的空闲的物理资源被延时敏感应用占用，此时非延时敏感应用可能由于其物理资源需求得不到满足而发生延时，但是由于延时敏感应用的峰值资源需求的瞬时性，延时敏感应用会很快从峰值资源需求回归到正常资源需求状态，这时候延时敏感应用又会释放出一部分物理资源，非延时敏感应用则可以利用延时敏感应用释放出的物理资源继续运行。

可见，将延时敏感应用和非延时敏感应用部署在同一物理服务器上，可以实现对服务器资源的共享。本申请实施例将上述的可以被延时敏感应用和非延时敏感应用共享的物理资源定义为共享资源。并且，本申请实施例将上述的共享资源量，设定为延时敏感应用的附加资源需求量与非延时敏感应用的平均资源需求量中的较大者，也就是将延时敏感应用的附加资源需求量与非延时敏感应用的平均资源需求量中较大的量设定为共享资源量。可以理解，按照本申请实施例设定的共享资源量，可以满足非延时敏感应用的平均资源需求，并且该共享资源量与延时敏感应用的平均资源量相加的物理资源量，可以满足延时敏感应用的峰值资源需求。

在部署上述未部署的应用，也就是部署非延时敏感应用时，本申请实施例判断目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过目标物理服务器的资源总量。

以上述的资源是cpu资源为例，上述的已部署的应用的平均资源需求量与共享资源量之和是否不超过目标物理服务器的资源总量，可以表示为：

其中，α^th表示延时敏感应用的峰值cpu资源需求门限，表示延时敏感应用的平均cpu资源需求量，表示延时敏感应用的附加cpu资源需求量，β^mean表示非延时敏感应用的均值cpu资源需求门限，表示非延时敏感应用的平均cpu资源需求量，c^cpu表示目标物理服务器的cpu资源总量。

如果不超过目标物理服务器的资源总量，则执行步骤s606、将该应用部署在该目标物理服务器上；然后，返回步骤s604继续遍历下一个未部署的应用进行部署。

如果超过目标物理服务器的资源总量，则执行步骤s607、从预设的至少一个物理服务器中选取下一个物理服务器作为目标物理服务器，并且返回执行步骤s605，直到将该应用部署到物理服务器上后，继续遍历下一个未部署的应用进行部署。

具体的，目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过目标物理服务器的资源总量，说明该目标物理服务器的资源总量可以满足上述延时敏感应用与上述非延时敏感应用在资源共享工作状态中的资源需求总和，因此可以将上述非延时敏感应用与上述延时敏感应用部署在同一物理服务器上。

如果上述的目标物理服务器上尚未部署应用，则可以直接将应用部署到该目标物理服务器上。

如果对于某一个未部署的应用，通过重复执行上述的步骤未能将其部署到预设的至少一个物理服务器上，则本申请实施例开启新的物理服务器，并将该未部署的应用部署到该物理服务器上。同时，将该新的物理服务器添加到上述预设的至少一个物理服务器构成的服务器集合中，在后期的应用部署中，该物理服务器可以被选定为目标物理服务器，继续部署其他未部署的应用。

进一步的，当每次将遍历到的应用部署到目标物理服务器上之后，本申请实施例还进一步计算该目标物理服务器的剩余资源量，如果该目标物理服务器的剩余资源量为零，或者足够小(不足以满足任何应用的资源需求)，则将该目标物理服务器移除上述的服务器集合，即在后期部署应用过程中，不再将该物理服务器设定为目标物理服务器。

本实施例中的步骤s601～s603分别对应图5所示的方法实施例中的步骤s501～s503，其具体内容请参见图5所示的方法实施例的内容，此处不再赘述。

作为一种示例性的实现方式，本申请实施例还公开了，上述的根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类，包括：

首先，分别对当前批次待部署的各个应用的资源需求量进行二值化处理；

示例性的，利用门限值r^th＝cpu^th将当前批次待部署的各个应用的资源需求量二值化处理为(0,1)表示，其中0表示低的资源需求量，1表示高的资源需求量。

具体的，通过将待部署的各个应用的资源需求量与上述的门限值进行对比，对应用的资源需求量进行如下的二值化处理：

其中，cpui表示应用i的资源需求量，cpu^th表示资源需求量门限值。

然后，由二值化处理后的所述当前批次待部署的各个应用的资源需求量构成资源需求量集合；

具体的，将对当前批次待部署的各个应用的资源需求量进行二值化之后的结果进行归集为集合，得到资源需求量集合。

例如，假设待部署的各个应用的资源需求量构成集合表示为：

vm＝{(5)¹，(1)²，(6)³…}

其中，(5)¹、(1)²、(6)³分别表示第一个应用的资源需求量为5、第二个应用的资源需求量为1、第三个应用的资源需求量为6。

资源需求量门限值为r^th＝4，则对上述各个应用的资源需求量进行二值化处理可以得到资源需求量集合：

vm′＝{(1)¹，(0)²，(1)³…}

其中，(1)¹、(0)²、(1)³分别表示第一个应用的资源需求量为1、第二个应用的资源需求量为0、第三个应用的资源需求量为1。

最后，通对所述资源需求量集合进行聚类处理，将所述当前批次待部署的各个应用划分为至少一个应用类。

具体的，本申请实施例采用无监督的聚类算法—k均值(k-means)聚类算法，执行对上述的资源需求量集合的聚类处理，该算法的主要作用是将相似的资源需求特性的应用自动归到一个类别中。

k-means算法的核心思想是在给定k值和k个初始类簇中心点的情况下，把每个点分到离其最近的类簇中心点所代表的类簇中，当所有点分配完毕之后，根据一个类簇内的点重新计算该类簇的中心点(取平均值)，然后再迭代的进行分配点和更新类簇中心点的步骤，直至类簇中心点的变化很小，或者达到指定的迭代次数。k-means算法的优点是简单有效，计算复杂度相对较小。

但是，设定合理的k值和k个初始类簇中心点对于算法性能好坏具有很大的影响，如果人为设定难以把握。

因此，本申请实施例采用k-means++算法进行初始类簇中心点的选取。

k-means++算法从输入的数据点集合中，也就是从上述的资源需求量集合中，随机选出一个点作为第一个聚类中心；对于资源需求量集合中的每一个点(数据)，计算它与最近聚类中心(指已选择的聚类中心)的距离；在上述距离计算基础上，选择一个新的数据点作为新的聚类中心，选择的原则是数据点与聚类中心的距离越大，则该数据点被选为聚类中心的概率就越大；重复上述的距离计算以及新的聚类中心选取处理，直到k个聚类中心被选出来。

在确定了k个聚类中心后，再利用这k个聚类中心运行k-means算法，将上述的资源需求量集合划分为k个类，将每个类中的各个资源需求量对应的应用归集到一起，即得到一个应用类，按照上述处理，可以得到k个应用类，即将当前待部署的各个应用划分为k个应用类。

需要说明的是，本申请实施例上述的对当前待部署的各个应用的资源需求量进行二值化处理，可以简化对应用的资源需求量数值表示，使应用的资源需求量数值表示更简洁，进而可以使后续的聚类处理的计算复杂度更低，能够提升后续的聚类效率。在实际实施本申请实施例技术方案时，可以直接对待部署的各个应用的资源需求量进行聚类处理，实现对各个应用的聚类。或者，上述的聚类处理过程也可以通过人工设定初始聚类中心的方式进行，而不限定必须借助k-means++算法确定初始聚类中心。

与上述的应用部署方法相对应的，本申请实施例还提出一种应用部署装置，参见图7所示，该装置包括：

应用选择单元100，用于从待部署应用集合中获取当前批次待部署的应用；

聚类处理单元110，用于根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类；

第一部署单元120，用于基于所述当前批次待部署的各个应用所属的应用类，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上；其中，部署在同一物理服务器上的应用属于不同应用类。

本申请实施例提出的应用部署装置的聚类处理单元110能够根据应用选择单元100获取的待部署的各个应用的资源需求量，对待部署的各个应用进行聚类处理，将待部署的应用划分为至少一个应用类，然后，第一部署单元120基于待部署的各个应用所属的应用类，将待部署的各个应用部署到预设的至少一个物理服务器上，并且，本申请实施例控制部署在同一物理服务器上的应用属于不同的应用类。通过执行上述技术方案，可以将应用分配部署到物理服务器上，即实现应用向物理服务器的部署。同时，上述应用部署装置将资源需求量不相似的应用部署到相同的物理服务器上，而将资源需求量相似的应用部署到不同的物理服务器上，由此实现了对物理服务器资源的科学、高效利用。

进一步的，本申请实施例对应用的聚类处理，可以快速地确定待部署的各个应用之间的资源需求量关系，利于提升应用部署效率。

作为一种可选的实现方式，所述第一部署单元120，包括：

系数确定单元，用于确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数；

部署处理单元，用于参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上。

作为一种可选的实现方式，所述系数确定单元确定所述当前批次待部署的各个应用中的、属于不同应用类的应用之间的资源需求相关系数时，具体用于：

分别计算所述当前批次待部署的各个应用中的、每两个属于不同应用类的应用之间的资源需求相关系数；

或者，

分别计算各个应用类之间的资源需求相关系数，并将任一应用类与另一应用类之间的资源需求相关系数，设定为该应用类中的任意一个应用与该另一应用类中的任意一个应用之间的资源需求相关系数。

作为一种可选的实现方式，所述部署处理单元参考所述属于不同应用类的应用之间的资源需求相关系数，按照属于同一应用类的应用不能部署到同一物理服务器的原则，将所述当前批次待部署的各个应用部署到预设的至少一个物理服务器上时，具体用于：

在部署当前批次待部署的每个应用时，查询目标物理服务器中是否已部署与该应用属于同一应用类的应用；其中，所述目标物理服务器是从预设的至少一个物理服务器中选取的物理服务器；

如果已部署与该应用属于同一应用类的应用，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器；

如果未部署与该应用属于同一应用类的应用，则判断该应用与所述目标物理服务器中已部署的应用之间的资源需求相关系数是否小于预设的资源需求相关系数阈值；

如果小于预设的资源需求相关系数阈值，则将该应用部署在所述目标物理服务器上；

如果不小于预设的资源需求相关系数阈值，则从所述预设的至少一个物理服务器中选取下一物理服务器作为目标物理服务器。

作为一种可选的实现方式，所述应用选择单元100从待部署应用集合中获取当前批次待部署的应用时，具体用于：

从待部署应用集合中获取延时敏感应用，并将所获取的延时敏感应用设定为当前批次待部署的应用；

所述装置还包括：

第二部署单元，用于基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上。

作为一种可选的实现方式，所述第二部署单元基于所述待部署应用集合中的未部署的各个应用的资源需求量，以及已经部署到所述预设的至少一个物理服务器上的各个应用的资源需求量，将所述待部署应用集合中的未部署的各个应用部署到所述预设的至少一个物理服务器上时，具体用于：

在部署所述待部署应用集合中的未部署的每个应用时，确定目标物理服务器中已部署的应用的平均资源需求量与共享资源量之和是否不超过所述目标物理服务器的资源总量；其中，所述目标物理服务器是从所述预设的至少一个物理服务器中选取的物理服务器；所述共享资源量为该应用的平均资源需求量，与所述目标物理服务器中已部署的应用的附加资源需求量中的较大者；所述附加资源需求量为峰值资源需求量与平均资源需求量的差值；

如果不超过所述目标物理服务器的资源总量，则将该应用部署在所述目标物理服务器上；

如果超过所述目标物理服务器的资源总量，则从所述预设的至少一个物理服务器中选取下一个物理服务器作为目标物理服务器。

作为一种可选的实现方式，所述聚类处理单元110根据当前批次待部署的各个应用的资源需求量，对所述当前批次待部署的各个应用进行聚类处理，得到至少一个应用类时，具体用于：

分别对当前批次待部署的各个应用的资源需求量进行二值化处理；

由二值化处理后的所述当前批次待部署的各个应用的资源需求量构成资源需求量集合；

通对所述资源需求量集合进行聚类处理，将所述当前批次待部署的各个应用划分为至少一个应用类。

上述的应用部署装置的各个实施例中的各个单元的具体工作内容，请参见上述的应用部署方法的实施例的介绍，此处不再重复。

本申请另一实施例还提出了一种应用部署设备，参见图8所示，该设备包括：

存储器200和处理器210；

其中，所述存储器200与所述处理器210连接，用于存储程序；

所述处理器210，用于通过运行所述存储器200中存储的程序，实现上述任一实施例介绍的应用部署方法的各个处理步骤。

具体的，上述应用部署设备还可以包括：总线、通信接口220、输入设备230和输出设备240。

处理器210、存储器200、通信接口220、输入设备230和输出设备240通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器210可以是通用处理器，例如通用中央处理器(cpu)、微处理器等，也可以是特定应用集成电路(application-specificintegratedcircuit，asic)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器210可包括主处理器，还可包括基带芯片、调制解调器等。

存储器200中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器200可以包括只读存储器(read-onlymemory，rom)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(randomaccessmemory，ram)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备230可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备240可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口220可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(ran)，无线局域网(wlan)等。

处理器2102执行存储器200中所存放的程序，以及调用其他设备，可用于实现本申请实施例所提供的应用部署方法的各个步骤。

本申请另一实施例还提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时，实现上述任一实施例提供的应用部署方法的各个步骤。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请各实施例种装置及终端中的模块和子模块可以根据实际需要进行合并、划分和删减。

本申请所提供的几个实施例中，应该理解到，所揭露的终端，装置和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，模块或子模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个子模块或模块可以结合或者可以集成到另一个模块，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件单元，或者二者的结合来实施。软件单元可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

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

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