CN110399213B - 确定应用程序的资源需求的方法、装置、电子设备及介质 - Google Patents

Abstract

本申请提供了一种确定应用程序的资源需求的方法。该方法包括：根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据；确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；从所述应用服务器获取所述应用程序在运行时的资源使用数据；根据所述资源使用数据重新确定所述应用程序的资源需求数据。本申请实施例能够准确确定应用程序的资源需求数据，使得最大化地利用应用服务器的资源以及降低运营成本成为可能。

Description

确定应用程序的资源需求的方法、装置、电子设备及介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种确定应用程序的资源需求的方法、装置、电子设备及介质。

背景技术

随着互联网的发展，各种类型的应用也如雨后春笋般出现，为用户提供了多样化的网络业务，如视频应用、游戏应用、网络直播应用等等，极大地丰富了用户的生活。

有些应用在运行时会与另一个或另一些应用一起共享应用服务器的资源，例如，多个游戏应用程序共享一个游戏服务器的CPU、内存、显卡等资源。在为应用分配应用服务器时，需要准确地确定该应用所需要的资源，以为其分配适当的应用服务器。

发明内容

本申请实施例提出一种确定应用程序的资源需求的方法、装置、电子设备及介质，能够准确地确定应用程序所需要的资源数据。

根据本申请实施例的一方面，公开了一种确定应用程序的资源需求的方法，所述方法包括：

根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据；

确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；

从所述应用服务器获取所述应用程序在运行时的资源使用数据；

根据所述资源使用数据重新确定所述应用程序的资源需求数据。

根据本申请实施例的一方面，公开了一种确定应用程序的资源需求的装置，包括：

需求数据获取模块，用于根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据；

分配模块，用于确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；

使用数据获取模块，用于从所述应用服务器获取所述应用程序在运行时的资源使用数据；

确定模块，用于根据所述资源使用数据重新确定要所述应用程序的资源需求数据。

根据本申请实施例的一方面，公开了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个计算机程序，所述一个或多个计算机程序在被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

根据本申请实施例的一方面，公开了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被处理器执行时，使处理器执行如上所述的方法。

本申请的实施例提供的技术方案可以包括以下有益效果：

在本申请实施例提供的技术方案中，从应用服务器获取应用程序在运行时所使用的资源的数据，并根据该数据重新确定应用程序的资源需求数据，从而通过这样的反馈机制能准确地确定出应用程序所需的资源，使得根据准确的资源需求为应用程序分配合适的应用服务器以最大程度地利用服务器资源、降低运行成本成为可能。

本申请实施例的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请实施例的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了根据本申请一个实施例的适用于根据本申请实施例的资源分配方法的系统构架的示意图。

图2示出了根据本申请一个实施例的资源分配方法应用在云游戏的示意应用场景图。

图3示出了根据本申请一个实施例的资源分配方法的示意流程图。

图4示出了图3实施例中的步骤S310的一个示例具体实施方式的示意流程图。

图5示出了图3实施例中的步骤S320的一个示例具体实施方式的示意流程图。

图6示出了图3实施例中的步骤S340的一个示例具体实施方式的示意流程图。

图7示出了图3实施例中的步骤S340的另一个示例具体实施方式的示意流程图。

图8示出了根据本申请一个实施例的资源分配装置的框图。

图9示出了根据本申请一个实施例的电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本申请的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本申请实施例的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本申请的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本申请实施例的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本申请实施例的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面先参照图1描述一下适用于本申请实施例的资源分配方法的示例体系构架。

该示例系统架构可以包括客户端101、调度服务器102、应用服务器103。调度服务器102根据客户端101的运行应用程序的运行请求为应用程序选择合适的应用服务器103，应用服务器103为应用程序提供运行环境，客户端101为用户提供与基于应用服务器103运行的应用程序的接口。在一些实施例中，例如如图1中所示，系统架构还可以包括接入服务器104，用于为客户端101提供接入应用服务器103的服务。

客户端101可以是任意终端设备，例如，其可以是智能手机，还可以是平板电脑、便携式计算机、台式计算机等等。

调度服务器102与客户端101、应用服务器103以及接入服务器104相连接，其可以预先存储多个应用程序的相应资源需求数据的列表，并根据客户端101的运行请求，为运行请求所针对的应用程序获取资源需求数据，以便根据资源需求数据为该应用程序确定合适的应用服务器。在本申请实施例中，调度服务器102可以从运行该应用程序的应用服务器103获取该应用程序在运行时的资源使用数据，并根据资源使用数据重新确定资源需求数据，从而得到更加准确的资源需求数据，以供之后为该应用程序确定应用服务器时使用。根据本申请实施例的调度服务器102可以是具有数据处理能力和通信能力的任意计算设备。

应该理解，图1中的客户端101、调度服务器102、应用服务器103、接入服务器104的数目仅仅是示意性的。根据实现需要，可以具有任意数目的客户端101、调度服务器102、应用服务器103、接入服务器104。

下面结合图2描述根据本申请实施例的资源分配方法应用在云游戏的场景。

在云游戏的应用场景中，云端调度服务器102接受客户端101的游戏应用A、游戏应用B、游戏应用C运行请求，然后根据资源需求数据列表选择满足该游戏应用的资源需求数据的应用服务器103。其中，游戏资源需求数据列表中的初始游戏资源需求数据是已知的，可以由每款游戏的开发商提供的对应游戏所需的最低配置和需要的资源配额数据生成。

在本申请的一些实施例中，采用容器虚拟化技术对游戏运行环境进行隔离，执行镜像时，游戏应用A、游戏应用B、游戏应用C会分别运行在一个隔离环境中，并且不会共享宿主机的内存、CPU(Central Processing Unit，中央处理器)、GPU(Graphics ProcessingUnit，图形处理器)以及磁盘等，这就保证了容器内进程不能监控容器外的任何进程。使用容器虚拟化技术对游戏运行环境进行隔离能够对游戏资源使用进行限制，能够实现对硬件资源进行细粒度调度，还能够定时向云端调度服务器102上报运行状态和资源使用信息。

当云端调度服务器102接收到游戏应用运行过程中的资源使用数据后，云端调度服务器102可以根据该资源使用数据，为游戏应用重新确定适合其运行的应用服务器103，资源使用数据可以包括例如计算机CPU占用量、GPU占用量、存储器资源量、磁盘I/O(Input/Output，输入/输出)带宽资源量和网络带宽资源量等。随着游戏的运行，可以确定游戏应用的资源使用情况与计算机的计算能力的关系，达到最大的资源利用率和最小的运营成本的目的，并且合理的资源分配既能够保障容器的稳定高效的运行又能充分的利用计算资源来完成所要求的任务。

根据本申请的一个实施例，提供了一种确定应用程序的资源需求的方法。图3示出了根据本申请一示例性实施例的确定应用程序的资源需求的方法的示意流程图。该示例方法可以由如图1中所示的调度服务器102来执行。如图3所示，所述示例方法包括：

步骤S310、根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据；

步骤S320、确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；

步骤S330、从所述应用服务器获取所述应用程序在运行时的资源使用数据；

步骤S340、根据所述资源使用数据重新确定所述应用程序的资源需求数据。

下面对这些步骤进行详细描述。

在步骤S310中，应用程序是指为完成某项或多项特定工作的计算机程序，它运行在用户模式，可以和用户进行交互，可以具有可视的用户界面。例如，该应用程序包括可安装在终端设备中的各种应用，如游戏应用、微信应用、爱奇艺、UC浏览器、淘宝应用、支付宝应用、QQ音乐应用、各种游戏应用程序等。此处不做唯一限定。

应用程序的资源需求数据是指运行所述应用程序所需要的资源，比如GPU资源、CPU资源、存储器资源、磁盘I/O带宽资源和网络带宽资源等。资源需求数据是为应用程序确定相应的应用服务器的基础。

在步骤S320中，与所述应用程序的资源需求数据相对应的应用服务器是指该应用服务器的配置资源能够满足应用程序的资源需求数据的要求。举例来说，假设应用程序A需要3核CPU，12GB内存，应用程序B需要12核CPU和64GB内存。而应用服务器C服务器配置16核CPU，32G内存，应用服务器D配置16核CPU，128G内存，那么对于应用程序A来说，应用服务器C和应用服务器D均满足要求，而对于应用程序B来说，应用服务器C不满足要求，应用服务器D满足要求。

在步骤S330中，从所述应用服务器获取所述应用程序运行时的资源使用数据。

资源使用数据是与资源需求数据相对应的，是根据应用程序在实际运行过程中所使用的资源数据来确定的，例如，其可以包括GPU资源、CPU资源、存储器资源、磁盘I/O带宽资源、网络带宽资源等。

在步骤S330中，从所述应用服务器获取所述应用程序运行时的资源使用数据。具体的获取策略可以是实时获取，也可以是每隔设定时间获取一次。

在步骤S340中，根据所述资源使用数据重新确定所述应用程序的资源需求数据。

当根据资源需求数据确定应用服务器后，应用程序在应用服务器上运行。应用程序在运行过程中的资源使用数据可能是不断变化的，可能与原来获取的资源需求数据不符。在所获取到的资源使用数据长时间低于初始的资源需求数据的情况下，根据初始的资源需求数据分配给该应用程序的应用服务器的资源利用率较低。在本申请实施例中，根据所述资源使用数据重新确定所述应用程序资源需求数据，以便之后在为该应用程序分配应用服务器时能够基于该重新确定的资源需求数据，从而能够最大程度地利用应用服务器的资源。

举例来说，应用A配置的资源需求数据为10核CPU、50G内存，应用服务器1的资源配置为10核CPU、50G内存，应用服务器2的资源配置为10核CPU，24GB内存，于是根据应用A的资源需求数据，将应用A接入应用服务器，以供其运行，在实际运行过程中，获得应用A消耗的资源为6核CPU，24GB内存。因此，在基于之后的运行请求为应用A确定应用服务器时，可以根据获取的资源使用数据，将应用服务器2分配给应用A，以供其运行，这样可以最大化实现资源的合理分配。

在本申请实施例提供的技术方案中，通过获取所述应用程序的资源需求数据，确定与所述应用程序的资源需求数据相对应的应用服务器，从所述应用服务器获取所述应用程序运行时的资源使用数据，根据所述资源使用数据重新确定所述应用程序的资源需求数据，从而通过这样的反馈机制能准确地确定出应用程序所需的资源，从而使得根据准确的资源需求为应用程序分配合适的应用服务器以最大程度地利用服务器资源。

在一个实施例中，获取资源需求数据的方式可以是调度服务器在接收到应用程序的运行请求后，根据应用程序的信息(例如，应用程序的版本信息中所记载的所需配置信息)确定其资源需求数据。一般地，在测试应用程序之后，即为应用程序配置资源标准，例如，为一个应用程序配置10核CPU、50G内存等，然后该配置信息记载在发布该应用程序时的版本信息中，方便以后直接获取该数据。

在另一个实施例中，资源需求数据还可以预先保存在资源需求数据列表中。例如，可以根据例如应用程序的版本信息、历史运行信息、测试结果数据等预先评估或确定各个应用程序的资源需求数据，生成资源需求数据列表并保存在调度服务器可以访问的适当位置。例如，在资源需求列表中，每一条数据记录可以包括应用程序的标识以及该应用程序对应的资源需求数据。在一个实施例中，在根据获取的资源使用数据重新确定资源需求数据后，可以使用重新确定的资源需求数据更新该列表，例如，使用新资源需求数据覆盖相应的旧资源需求数据。

在该实施例中，如图4所示，步骤S310可以包括：

步骤S3101、从所述运行请求获取所述应用程序的标识；

步骤S3102、从预先保存的资源需求数据列表中获取与所述标识相对应的资源需求数据。

在步骤S3101中，所述应用程序的标识用于标识并区分该应用程序，可以是应用程序的名称、应用程序的授权编号、或者应用程序能够适配的设备类型，也可以是应用程序的进程ID(PID)，该PID是进程在启动时系统自动为其分配的ID。客户端在向调度服务器发送应用程序运行请求信息时，会将应用程序的标识同时发送给调度服务器。调度服务器在接收到运行请求时，即可从所述运行请求获取所述应用程序的标识。

步骤S3102，从预先保存的资源需求数据列表中获取与所述标识相对应的资源需求数据。

如上所述，在一实施例中，预先设置应用程序的标识与资源需求数据关系列表并保存，然后根据应用程序的标识，就可以查找与所述标识相对应的资源需求数据。由于该对应关系列表是预先设置的，因此，该实施例通过这种快速查表的方式，实现了对应用程序的资源需求数据的快速获取，提高了为应用程序进行资源分配的及时性和高效性。

一般情况下，应用服务器会有多个，因此出现满足所述应用程序的资源需求数据要求的应用服务器也可能有多个，当要运行应用程序时，可以从这多个候选应用服务器中选择一个进行连接。它的好处是，可以灵活地从众多的候选应用服务器中选择应用服务器连接，实现了对计算资源进行弹性处理，提高计算资源利用率。

在该实施例中，如图5所示，步骤S320包括：

步骤S3201、确定满足所述资源需求数据的应用服务器，作为所述应用程序的候选应用服务器；

步骤S3202、对于每个候选应用服务器，根据该候选应用服务器的负载信息和配置信息确定该候选应用服务器的相应的负载值和资源值；

步骤S3203、对于每个候选应用服务器，根据该候选应用服务器的负载值和资源值确定该候选应用服务器的可用值；

步骤S3204、确定所述候选应用服务器中可用值最大的应用服务器，作为与所述应用程序的资源需求数据相对应的应用服务器，将所述应用服务器分配给所述应用程序以运行所述应用程序。

在步骤S3202中，负载信息可以包括服务器的GPU占有率、CPU占有率、内存使用率、I/O使用率以及带宽使用率中的至少一种，配置信息可以包括服务器的内存容量、CPU频率、GPU频率和网络带宽中的至少一种。

候选应用服务器的负载信息和配置信息的获取可以包括两种情况，一种情况是调度服务器可以在到达预设时间时，向与其连接的各个候选应用服务器发送查询信息，所述候选应用服务器在接收到查询信息时可以根据自身的性能和实际负载情况，发送负载信息和配置信息。另一种情况是各个候选应用服务器可以在预设时间内主动将负载信息和配置信息发送给调度服务器。

在一个实施例中，步骤S3202中对于每个候选应用服务器，根据该候选应用服务器的负载信息和配置信息确定该候选应用服务器的相应的负载值和资源值，包括：

为每一个负载信息和每一个配置信息均设置一个权重值。

将所有负载信息与对应权重值的乘积相加得到负载值，并且将所有配置信息与对应权重值的乘积相加得到资源值。

实际中，在不同需要中，这两个指标的重要性是不同的。因此，在另一个实施例中，将负载值和资源值的加权和，确定为该候选应用服务器的可用值。举例来说，假设负载信息包括服务器的CPU占有率、内存使用率，配置信息包括服务器的内存容量、CPU频率，分别设CPU占有率A、内存使用率B、内存容量C和CPU频率D，各自权重值分别为0.4、0.3、0.5、0.2，则负载值＝0.4*A+B*0.3，资源值＝0.5*C+0.2*D，再设负载值和资源值的权重值均为0.5，则得到该候选应用服务器的可用值＝0.5((0.4*A+B*0.3)+(0.5*C+0.2*D))。可以理解的是，上述示例中各个值仅为示意性的，而不造成对本申请的限制，各个值的取值可以根据实际应用进行设置。

步骤S3204中，将计算得到的各个候选应用服务器的可用值按照从大到小的顺序进行排序。将运行请求发送给可用值最大的应用服务器，即将该应用服务器分配给该运行请求所针对的应用程序。

应用本申请实施例，可以根据应用服务器主动发送的负载信息和配置信息，转发访问情况，确定运行请求的目标应用服务器，降低算法的复杂度，提高运算速度，加快访问反馈速度，增强用户体验。

在一个实施例中，所述应用程序是提供游戏的应用程序，在该实施例中，步骤S330包括：

在游戏的场景、游戏画面的分辨率或质量的设置发生改变时，从所述应用服务器获取所述应用程序在运行时的资源使用数据。

随着应用程序的运行，会需要处理不同的内部运行场景，以游戏应用程序为例，游戏应用程序中的内部运行场景例如可以是团战场景、商城场景、启动场景等。不同的运行场景会导致应用程序的资源需求数据发生变化。同样当游戏画面在清晰或者模糊状态下，游戏应用的资源需求数据同样会发生变化。在一个实施例中，调度服务器可以在游戏的场景、游戏画面的分辨率或质量的设置发生改变时，从所述应用服务器获取所述应用程序在运行时的资源使用数据，因为在发生这些变化时，应用程序的资源使用数据很可能发生了变化。在一些实施例中，调度服务器仅在游戏的场景、游戏画面的分辨率或质量的设置发生改变时从应用服务器获取应用程序的资源使用数据，从而能够以较低的监测成本获得足够准确的资源使用数据变化。

应用服务器可以实时收集应用程序实际运行过程中的资源使用数据，并将资源使用数据反馈给调度服务器，调度服务器可以根据资源使用数据重新确定所述应用程序的资源需求数据，重新调整资源分配，既有利于提高应用程序的预设内部运行场景的运行性能，又有利于资源最大程度化的利用。

步骤S340有多种实施方式。

在一个实施例中，如图6所示，步骤S340包括：

步骤S3401、确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据中的最大值；

步骤S3402、将所述最大值作为所述应用程序的新的资源需求数据。

在一个实施例中，所述应用程序的一次的资源使用数据是指从应用程序开始运行起，一直持续到用户选择退出所述应用程序为止。在这个过程中，获取所述应用程序运行中的资源使用数据，当出现资源使用数据的峰值时，即将该峰值确定为资源使用数据中的最大值，将该峰值作为一次资源使用数据中的最大值。若用户持续了多个打开到退出的动作，也就是应用程序运行了多次，即可将最新一次获取的资源需求数据的峰值与历史获取的资源需求数据的峰值进行对比，将两者中的较大值作为所述应用程序多次资源使用数据中的最大值。

在另一实施例中，所述应用程序的一次的资源使用数据是指在应用程序运行中可以周期性地、非周期性地、或按照预设规则多次获取资源使用数据，每次获取的资源使用数据都是一次资源使用数据。

在另一个实施例中，如图7所示，步骤S340包括：

步骤S3401’、确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据的平均值；

步骤S3402’、将所述平均值作为所述应用程序的新的资源需求数据。

与步骤S3401不同在于，在步骤S3401’中，对一次或多次的资源使用数据求平均，得到资源使用数据的平均值。采用求平均值的方式避免了当所述应用程序并不是通过用户的操作正常退出时，此时，由于所述应用程序的非正常关闭的原因很可能是出现异常引起的退出或被强制关闭，这样所得到的所述资源使用数据一定不正确，很可能会非常大，该资源使用数据将被视作非正常数据，通过求平均值的方式更能反映出所述应用程序实际的资源使用情况，减少了数据的不准确。

在一个实施例中，在步骤S340之后，所述方法还包括：

根据重新确定的资源需求数据修改预先保存的资源需求数据列表，以将所述重新确定的资源需求数据作为所述资源需求数据列表中与所述应用程序相对应的资源需求数据。

由于所述应用程序在实际运行过程中所获得的资源使用数据可以更真实地反映出应用程序运行的资源需求，因此在获取资源使用数据后，可以重新确定资源需求数据，将重新确定的资源需求数据更新到与应用程序相关联的资源需求数据表中，为所述应用程序的运行提供了参考的基础数据，在下次启动所述应用程序前，先读取出所述资源需求数据，并根据其中的数据，向系统申请相应的资源，进而维持了系统运行的稳定性。

如图8所示，根据本申请的一个实施例，提供了一种确定应用程序的资源需求的装置800，所述装置800包括：

需求数据获取模块810，用于根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据；

分配模块820，用于确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以运行所述应用程序；

使用数据获取模块830，用于从所述应用服务器获取所述应用程序运行时的资源使用数据；

确定模块840，用于根据所述资源使用数据重新确定要所述应用程序的资源需求数据。

在一个实施例中，所述需求数据获取模块810进一步用于：

从所述运行请求获取所述应用程序的标识；

从预先保存的资源需求数据列表中获取与所述标识相对应的资源需求数据。

在一个实施例中，所述确定模块840进一步用于：

确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据中的最大值；

将所述最大值作为所述应用程序的新的资源需求数据。

在一个实施例中，所述确定模块840进一步用于：

确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据的平均值；

将所述平均值作为所述应用程序的新的资源需求数据。

在一个实施例中，所述装置还包括：

修改单元(未示出)，用于根据重新确定的资源需求数据修改预先保存的资源需求数据列表，以将所述重新确定的资源需求数据作为所述资源需求数据列表中与所述应用程序相对应的资源需求数据。

在一个实施例中，所述确定与所述应用程序的资源需求数据相对应的应用服务器包括：

确定满足所述资源需求数据的应用服务器，作为所述应用程序的候选应用服务器；

对于每个候选应用服务器，根据该候选应用服务器的负载信息和配置信息确定该候选应用服务器的相应的负载值和资源值；

对于每个候选应用服务器，根据该候选应用服务器的负载值和资源值确定该候选应用服务器的可用值；

确定所述候选应用服务器中可用值最大的应用服务器，作为与所述应用程序的资源需求数据相对应的应用服务器。

在一个实施例中，所述应用程序是提供游戏的应用程序，所述使用数据获取模块830进一步用于：

在游戏的场景、游戏画面的分辨率或质量的设置发生改变时，从所述应用服务器获取所述应用程序在运行时的资源使用数据。

上述各装置中各个单元/模块的功能和作用的实现过程以及相关细节具体详见上述方法实施例中对应步骤的实现过程，在此不再赘述。

以上各实施例中的各装置实施例可以通过硬件、软件、固件或其组合的方式来实现，并且其可以被实现为一个单独的装置，也可以被实现为各组成单元/模块分散在一个或多个计算设备中并分别执行相应功能的逻辑集成系统。以上各实施例中组成各装置的各单元/模块是根据逻辑功能而划分的，它们可以根据逻辑功能被重新划分，例如可以通过更多或更少的单元/模块来实现该装置。这些组成单元/模块分别可以通过硬件、软件、固件或其组合的方式来实现，它们可以是分别的独立部件，也可以是多个组件组合起来执行相应的逻辑功能的集成单元/模块。所述硬件、软件、固件或其组合的方式可以包括：分离的硬件组件，通过编程方式实现的功能模块、通过可编程逻辑器件实现的功能模块，等等，或者以上方式的组合。

根据一个示例性实施例，上述各装置实施例中的每个可被实现为一种电子设备，该电子设备包括存储装置和一个或多个处理器，所述存储装置中存储有计算机程序，所述计算机程序在被所述一个或多个处理器执行时，使得所述电子设备执行如上所述的方法各实施例中的任一个，或者，所述计算机程序在被所述处理器执行时使得该计算设备实现如上所述的各装置实施例的组成单元/模块所实现的功能。

上面的实施例中所述的处理器可以指单个的处理单元，如中央处理单元CPU，也可以是包括多个分散的处理单元/处理器的分布式处理器系统。

上面的实施例中所述的存储装置可以包括一个或多个存储器，其可以是电子设备的内部存储器，例如暂态或非暂态的各种存储器，也可以是通过存储器接口连接到计算设备的外部存储装置。

图9示出了这样的电子设备901的一个示例性实施例的示意组成框图。如图9所示，该电子设备可以包括但不限于：

至少一个处理单元910、至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元910执行，使得所述处理单元910执行本说明书上述示例性方法的描述部分中描述的根据本申请各种示例性实施方式的步骤。例如，所述处理单元910可以执行如图4中所示的各个步骤。

存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(ROM)9203。

存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：社交操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备901也可以与一个或多个外部设备900(例如键盘、指向设备、蓝牙设备等)通信，和/或与使得电子设备901能与一个或多个其它电子设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口950进行。并且，电子设备901还可以通过网络适配器960与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备901的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备901使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID(RedundantArraysofIndependent Drives，磁盘阵列)系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台电子设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。

在本申请的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本申请的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请实施例中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由所附的权利要求指出。

Claims (8)

1.一种确定应用程序的资源需求的方法，其特征在于，应用于调用服务器，包括：

根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据，其中，所述资源需求数据是根据应用程序的版本信息、历史运行信息和测试结果数据所确定的；所述应用程序为提供游戏的应用程序，采用容器虚拟化技术对游戏运行环境进行隔离，执行镜像时，所述应用程序运行在隔离环境中；

确定与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；

接收所述应用服务器实时收集的在游戏的运行场景、游戏画面的分辨率或质量的设置发生改变时所述应用程序在运行时的资源使用数据；

根据所述资源使用数据重新确定所述应用程序的资源需求数据，并根据重新确定的应用程序的资源需求数据分配合适的应用服务器；

所述确定与所述应用程序的资源需求数据相对应的应用服务器包括：

确定满足所述资源需求数据的应用服务器，作为所述应用程序的候选应用服务器；

对于每个候选应用服务器，为候选应用服务器的每一个负载信息和每一个配置信息均设置一个权重值，将所有负载信息与对应权重值的乘积相加得到负载值，并将所有配置信息与对应权重值的乘积相加得到资源值；

对于每个候选应用服务器，将该候选应用服务器的负载值和资源值的加权和，确定为该候选应用服务器的可用值；

确定所述候选应用服务器中可用值最大的应用服务器，作为与所述应用程序的资源需求数据相对应的应用服务器。

2.根据权利要求1所述的方法，其特征在于，所述根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据包括：

从所述运行请求获取所述应用程序的标识；

从预先保存的资源需求数据列表中获取与所述标识相对应的资源需求数据。

3.根据权利要求1所述的方法，其特征在于，所述根据所述资源使用数据重新确定所述应用程序的资源需求数据包括：

确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据中的最大值；

将所述最大值作为所述应用程序的新的资源需求数据。

4.根据权利要求1所述的方法，其特征在于，所述根据所述资源使用数据重新确定所述应用程序的资源需求数据包括：

确定从所述应用服务器获取的所述应用程序的一次或多次资源使用数据的平均值；

将所述平均值作为所述应用程序的新的资源需求数据。

5.根据权利要求1所述的方法，其特征在于，还包括：

根据重新确定的资源需求数据修改预先保存的资源需求数据列表，以将所述重新确定的资源需求数据作为所述资源需求数据列表中与所述应用程序相对应的资源需求数据。

6.一种确定应用程序的资源需求的装置，其特征在于，包括：

需求数据获取模块，用于根据所接收的应用程序的运行请求，获取所述应用程序的资源需求数据，其中，所述资源需求数据是根据应用程序的版本信息、历史运行信息和测试结果数据所确定的；所述应用程序为提供游戏的应用程序，所述应用程序运行在采用容器虚拟化技术隔离的运行环境；

分配模块，用于确定满足所述资源需求数据的应用服务器，作为所述应用程序的候选应用服务器；对于每个候选应用服务器，为候选应用服务器的每一个负载信息和每一个配置信息均设置一个权重值，将所有负载信息与对应权重值的乘积相加得到负载值，并将所有配置信息与对应权重值的乘积相加得到资源值；对于每个候选应用服务器，将该候选应用服务器的负载值和资源值的加权和，确定为该候选应用服务器的可用值；确定所述候选应用服务器中可用值最大的应用服务器，作为与所述应用程序的资源需求数据相对应的应用服务器，并将所述应用服务器分配给所述应用程序以供所述应用程序在运行时使用；

使用数据获取模块，用于接收所述应用服务器实时收集的在游戏的运行场景、游戏画面的分辨率或质量的设置发生改变时所述应用程序在运行时的资源使用数据；

确定模块，用于根据所述资源使用数据重新确定要所述应用程序的资源需求数据，并根据重新确定的应用程序的资源需求数据分配合适的应用服务器。

7.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个计算机程序，所述一个或多个计算机程序在被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至5中任一项所述的方法。

8.一种计算机可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序在被处理器执行时，使处理器执行如权利要求1-5中任一项所述的方法。