具体实施方式

下面结合说明书附图对本申请实施例做详细描述。

为便于理解本申请实施例，首先以图1中示出的系统架构为例详细说明本申请实施例适用于的系统。图1示出了适用于本申请实施例的公有云服务系统的架构示意图。如图1所示，包括资源池以及用于控制资源池的资源调度设备，其中资源池可以包括至少一个资源服务器。

租户通过公有云服务的资源调度设备中的控制台(图1中未示出)，从不同的服务接口分别提交针对不同类型的任务的调度请求消息给资源调度设备。资源调度设备根据不同类型的任务的调度请求消息从资源池中调度资源服务器，并从调度的资源服务器中调度相应的处理资源分配给租户使用。

上述本申请实施例描述的架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的系统架构同样适用。

结合上述应用场景，参见图2，为本申请实施例提供的一种资源调度方法流程示意图。

该方法包括：

步骤201：资源调度设备在获取到第一调度请求消息时，所述第一调度请求消息用于为第一类型的任务请求资源，资源调度设备根据所述第一调度请求消息所请求的第一数量的资源，从资源池中确定第一资源服务器，并在所述第一资源服务器中调度所述第一数量的资源。

这里任务类型指的是任务对应的业务类型，用于执行一类业务类型的任务可以称之为一种类型的任务。这里的资源包括但不限于处理器资源、存储资源、带宽资源等等。

步骤202：资源调度设备在获取到第二调度请求消息时，所述第二调度请求消息用于为第二类型的任务请求资源，若资源调度设备根据资源池当前的资源负载率确定为所述第二调度请求消息对应的任务调度资源时，则根据所述第二调度请求消息所请求的第二数量的资源，从所述资源池中确定第二资源服务器，并在所述第二资源服务器中调度第三数量的资源；其中所述第三数量小于或等于所述第二数量。

第一资源服务器与第二资源服务器可以为同一个资源服务器，也可以为两个不同的资源服务器，本申请实施例对此并不限定。

通过上述实施例，通过对两种不同类型的任务使用两种不同的调度方法，可以提高资源利用率，节省运营商的成本，并可避免对服务等级协议(service level agreement，SLA)敏感任务的影响。首先，通过在按资源请求量调度的系统中加入按资源实际使用量的调度方法，使得第一类型的任务和第二类型的任务可以被调度到同一台资源服务器，从而实现有效利用同一个资源服务器上被第一类型的任务申请但未被使用的资源，可有效避免公有云场景下的资源浪费。其次，由于第二类型的任务可以被调度到第一类型的任务空余出的资源，公有云运营商可以减少购置用于执行第二类型的任务的服务器等硬件资源，从而节省运营商的服务成本。

如图3所示，为适用于本申请实施例的公有云服务系统中资源调度设备的架构示意图。如图3所示，资源调度设备包括第一调度器、第二调度器、负载控制模块、等待队列、消息队列模块等模块。上述第一类型的任务的调度请求消息可以提交到第一调度器，将第二类型的任务的调度请求消息提交到第二调度器。

第一调度器用于获取第一类型的任务的调度请求消息，第二调度器用于获取第二类型的任务的调度请求消息。其中，所述第一类型的任务可以为基于资源请求量进行资源调度的任务；所述第二类型的任务可以为基于资源使用量进行资源调度的任务。本申请实施例中，第一类型的任务也可以称为服务等级协议(service level agreement，SLA)敏感型任务，第二类型的任务也可以称为SLA不敏感型任务。其中，SLA敏感型任务，在执行的过程当中，随时都能够根据其需求获取到不超过其资源请求量的资源。而SLA不敏感型任务在执行过程中，可以获得小于其资源请求量的资源，并且当资源池负载过高时，可以将其正在使用的资源回收，进而导致任务执行的中断。

本申请实施例中，预先为每个任务设置相应的类型，即第一类型和第二类型，每种类型的任务只能通过相应的调度器申请资源，从而可以通过第二类型的任务提升资源利用率，同时避免对第一类型的任务的影响。

第一调度器获取到第一类型的任务的调度请求消息之后，根据第一类型的任务的资源请求量，确保该类型的任务在任何时候都能够获取到等于其请求量的资源的数量。

第二调度器获取到第二类型的任务的调度请求消息之后，不会一开始就为其分配所请求的数量的资源，而是先将该任务的调度请求消息放入等待队列进行等待。当根据资源池的资源负载率确定为该类型的任务调度资源时，根据其实际资源使用量的情况，为其最多分配不大于其请求量的资源的数量。第二调度器可以通过负载控制模块对各资源服务器的实际资源使用进行监控和预测，当任务实际资源使用量的预测值增加时，及时关闭部分第二类型的任务，从而保障第一类型的任务可以有充足资源使用。

资源池中的每个资源服务器中包括一个代理(agent)模块，代理模块一方面负责执行调度器的资源分配决策，另一方面负责对其所在资源服务器的资源负载以及资源服务器中各任务的实际资源使用量进行监控。调度器在为任务执行选择了一台资源服务器之后，会将任务的相关数据和信息传送给该资源服务器上的代理模块。代理模块根据调度器的决策，在资源服务器中为将要执行的任务准备执行环境，分配其所需要的资源并创建任务实例。当调度器决定中断某台资源服务器上的部分SLA不敏感型任务后，将被中断任务的相关信息传递给该资源服务器上的代理模块，由代理模块中断任务的执行，并释放其所占用的资源。

本申请实施例中，每个资源服务器中的代理模块会定期读取资源服务器中各任务的资源实际使用数据，在分析和汇总之后，每个资源服务器中的代理模块会周期性的向消息队列模块发送监控数据。监控数据包括但不限于资源服务器的资源负载率、执行的每种任务实际的资源使用量、执行的每种任务的任务类型等。

举例来说，如图4所示，为本申请实施例提供的一种监控数据发送流程示意图。

步骤401，资源池包括的资源服务器1至资源服务器K，周期性的向消息队列模块发送监控数据。

步骤402，消息队列模块对各资源服务器所发送的监控数据进行分类和汇总，并最终提供给负载控制模块读取。

步骤403，负载控制模块定期地向消息队列模块发送监控数据请求消息，所示监控数据请求消息用于请求获取监控数据。

相应的，步骤404，消息队列模块向负载控制模块发送监控数据响应消息，所述监控数据响应消息中包括负载控制模块请求的监控数据。

负载控制模块读取消息队列模块中各代理模块的监控数据，基于读取到的监控数据，对未来一段时间内(如1小时)资源池的资源负载和租户任务的实际资源使用量进行预测分析，并基于预测结果进行两个方面的逻辑判断。一方面，该负载控制模块根据预测的结果判断是否选择请求队列中所缓存的任务进行执行。当预测的负载较低时，负载控制模块从等待队列中获取调度请求消息(尚执行或被中断执行的调度请求消息)，筛选其中适合执行的任务，并通过调度器为其分配计算资源。另一方面，负载控制模块还需要判断是否需要中断正在运行中的SLA不敏感型任务。当某台资源服务器预测的资源负载较高，存在任务实际资源使用量超过服务器资源容量的风险时，负载控制模型会将该资源服务器的信息传递给第二调度器并由第二调度器选择关闭该资源服务器上的部分SLA不敏感型任务，从而确保剩余的任务在执行时能够获取到充足的资源。需要说明的是，负载控制模块具体如何基于读取到的监控数据，对资源池的资源负载和租户任务的实际资源使用量进行预测分析，本申请实施例对此并不限定，在此不再赘述。

本申请实施例中，第一类型的任务的创建和关闭的流程，可以如图5所示。包括如下处理步骤：

步骤501：租户向资源调度设备的控制台发送第一调度请求消息。其中，所述第一调度请求消息用于为第一类型的任务请求第一数量的资源。第一调度请求消息中还可以包括租户的身份信息、对应的任务的信息等，本申请实施例对此并不限定，在此不再赘述。

步骤502：资源调度设备的控制台对租户的身份信息和第一调度请求消息的合法性进行验证。控制台具体如何进行验证，本申请实施例对此并不限定，在此不再赘述。控制台认证通过后，执行步骤503，否则拒绝租户的请求，下面以认证通过为例进行描述。

步骤503：资源调度设备的控制台将第一调度请求消息提交到第一调度器。

步骤504：第一调度器根据所述第一调度请求消息所请求的第一数量的资源，从资源池中确定第一资源服务器。第一调度器可以从所述资源池所包括的至少一个资源服务器中，选择一个空闲资源的数量大于所述第一数量的资源服务器作为第一资源服务器。

为了保证租户提交的第一类型的任务能够获得足够的资源，公有云的第一调度器可以根据任务资源请求量进行资源调度。如图6所示，假设租户依次提交任务1、任务2和任务3。第一调度器根据任务资源请求量进行资源调度，将任务1和任务2调度到资源服务器1上。而当租户提交任务3的执行请求时，若资源服务器1上仍然剩余了未被实际使用的资源，但剩余的资源量小于任务3的资源请求量时，第一调度器会将任务3调度到空闲的资源服务器2中。

步骤505：第一调度器向第一资源服务器发送任务创建请求，所述任务创建请求用于请求创建第一调度请求消息对应的任务，且请求为该任务调度第一数量的资源。

步骤506：第一资源服务器中的代理模块根据所述任务创建请求创建任务，并调度第一数量的资源。

步骤507：第一资源服务器向第一调度器发送任务创建响应，所述任务创建响应用于指示任务创建请求的请求结果。

步骤508：第一资源服务器向控制台发送任务创建通知消息，所述任务创建通知消息用于指示第一调度请求消息的请求结果。

步骤509：控制台根据任务创建通知消息向租户发送第一调度响应消息，所述第一调度响应消息用于指示第一调度请求消息的请求结果。

通过上述过程，实现根据租户的第一调度请求消息，为第一调度请求消息对应的任务调度资源，并创建任务。

进一步的，若确定所述资源池的资源负载率大于或等于第一阈值，则可以从所述至少一个资源服务器执行的多个任务中选择M个所述第二类型的任务，并释放所述M个所述第二类型的任务所占用的资源，M为大于0的整数。可选的，还可以将所述M个所述第二类型的任务放入等待队列中，等待后续被调用执行。

进一步的，本申请实施例中，一个资源服务器中可以同时执行第一类型的任务和第二类型的任务。第一调度器通过对每个资源服务器中各任务的使用的资源量，对每个资源服务器在未来一段时间内的资源负载进行分析和预测，当第一调度器确定所述第一资源服务器中空闲资源的数量小于第二阈值，或者第一资源服务器的负载率大于预设负载率，例如大于90％，则从所述第一资源服务器中选择至少一个第二类型的任务，并释放所述至少一个第二类型的任务所占用的资源。因此，本申请实施例对第一类型的任务进行按资源请求量调度，并通过对资源负载进行监控和预测分析，及时中断负载较高资源服务器上的第二类型的任务。可以避免第二类型的任务抢占第一类型的任务所需要的资源的情况发生，避免对第一类型的任务的资源使用造成影响。即通过上述方法，可以优先保证第一类型的任务的资源分配。

举例来说，如图7所示，假设租户依次提交任务1、任务2和任务3。任务1是第一类型的任务，任务2和任务3是第二类型的任务，第一调度器根据任务资源请求量进行资源调度，将任务1调度到资源服务器1上；第二调度器根据任务资源使用量进行资源调度，将任务2和任务3调度到资源服务器1上。其中，为任务1调度的资源量等于其资源请求量，为任务2和任务3调度的资源量均小于各自的资源请求量。随着时间变化，任务2和任务3的实际资源使用量逐渐增长并达到了各自的资源请求量，三个任务的实际资源使用量将要超过资源服务器1的资源总容量。此时，可能需要中断部分任务的执行，从而保证其他任务能够获得足够的计算资源。第一类型的任务在执行过程中发生中断将严重影响租户的体验，从而导致运营商的品牌和口碑受到损失。为此，可以将第二类型的任务强行中断，此时可以将任务2和任务3全部中断执行，并释放资源。进一步的，还可以将所述至少一个第二类型的任务重新放入等待队列中，等待后续被调用再次执行。

可选的，本申请实施例中，租户还可以主动请求关闭任务，请继续参照上述图5所示，具体可以参考下面的流程：

步骤510：租户向控制台发送任务关闭请求，所述任务关闭请求用于请求关闭第一调度请求消息对应的任务。

步骤511：控制台将所述任务关闭请求转发至第一资源服务器。

步骤512：第一资源服务器根据所述任务关闭请求，关闭第一调度请求消息对应的任务，并释放调度给该任务的资源。

步骤513：第一资源服务器向控制台发送任务关闭完成通知消息，所述任务关闭完成通知消息用于指示任务关闭的结果。

步骤514：控制台向租户转发任务关闭完成通知消息。

本申请实施例中，与第一类型的任务不同，第二类型的任务的调度请求消息并不能立即获得请求的资源，而是需要排队。具体的，第二类型的任务的创建和中断的流程，可以如图8所示。具体可以包括：

步骤801：租户向资源调度设备的控制台发送第二调度请求消息。其中，所述第二调度请求消息用于为第二类型的任务请求第二数量的资源。第二调度请求消息中还可以包括租户的身份信息、对应的任务的信息等，本申请实施例对此并不限定，在此不再赘述。

步骤802：资源调度设备的控制台对租户的身份信息和第二调度请求消息的合法性进行验证。控制台具体如何进行验证，本申请实施例对此并不限定，在此不再赘述。控制台认证通过后，执行步骤803，否则拒绝租户的请求，下面以认证通过为例进行描述。

步骤803：控制台将第二调度请求消息放入等待队列。

步骤804：控制台向租户发送排队通知消息，所述排队通知消息用于指示所述第二调度请求消息位于等待队列中。

步骤805：负载控制模块发送排队信息请求消息，所述排队信息请求消息用于请求获取等待队列中所有正在排队的调度请求消息。

步骤806：负载控制模块接收排队信息响应消息，所述排队信息响应消息中包括等待队列中所有正在排队的调度请求消息等信息。

步骤807：负载控制模块确定为所述第二调度请求消息对应的任务调度资源。需要说明的是，当负载控制模块预测到资源池的资源负载率小于第一阈值时，会对等待队列中正在排队的调度请求消息进行筛选。之后将筛选后的调度请求消息以及各资源服务器中的负载率一同作为任务调度请求向第二调度器提交。

举例来说，若确定所述资源池的资源负载率小于第一阈值，且所述第二调度请求消息对应的任务为：所述等待队列中请求的资源数量最小的任务或等待时间最长的任务，则可以确定为所述第二调度请求消息对应的任务调度资源。

步骤808：负载控制模块向第二调度器发送第二调度请求消息。

步骤809：第二调度器根据所述第二调度请求消息所请求的第二数量的资源，从资源池中确定第二资源服务器。第二调度器可以从所述资源池所包括的至少一个资源服务器中，选择一个空闲资源的数量大于第三数量的资源服务器作为第二资源服务器。

本申请实施例中，第三数量可以为第二调度请求消息对应的任务的实际资源使用量，也可以为第二数量与预算权重值的乘积，预设权重值为大于0且小于或等于1的数。

为了保证租户提交的第一类型的任务能够获得足够的资源，且提高资源利用率。公有云的第二调度器可以根据任务资源使用量进行资源调度。如图9所示，假设租户依次提交任务1、任务2和任务3。任务1是第一类型的任务，任务2和任务3是第二类型的任务，第一调度器根据任务资源请求量进行资源调度，将任务1调度到资源服务器1上；第二调度器根据任务资源使用量进行资源调度，将任务2调度到资源服务器1上。而当租户提交任务3的执行请求时，若资源服务器1上仍然剩余了未被实际使用的资源，但剩余的资源量小于任务3的资源请求量时，为了提高资源利用率，第二调度器仍然可以将任务3调度到资源服务器1中，从而可以有效的避免云数据中心中各资源服务器中的资源碎片(无法分配给租户云主机的资源)，从而保证较高的资源利用率。

步骤810：第二调度器向第二资源服务器发送任务创建请求，所述任务创建请求用于请求创建第二调度请求消息对应的任务，且请求为该任务调度第三数量的资源。

步骤811：第二资源服务器中的代理模块根据所述任务创建请求创建任务，并调度第三数量的资源。

步骤812：第二资源服务器向第二调度器发送任务创建响应，所述任务创建响应用于指示任务创建请求的请求结果。

步骤813：第二资源服务器向控制台发送任务创建通知消息，所述任务创建通知消息用于指示第二调度请求消息的请求结果。

步骤814：控制台根据任务创建通知消息向租户发送第二调度响应消息，所述第二调度响应消息用于指示第二调度请求消息的请求结果。

通过上述过程，实现根据租户的第二调度请求消息，为第二调度请求消息对应的任务调度资源，并创建任务。

进一步的，本申请实施例中，一个资源服务器中可以同时执行第一类型的任务和第二类型的任务。若确定所述第二资源服务器中空闲资源的数量小于第二阈值，则从所述第二资源服务器执行的多个任务中选择N个所述第二类型的任务，并释放所述N个所述第二类型的任务所占用的资源，N为大于0的整数。可选的，还可以将所述N个所述第二类型的任务放入等待队列中等待后续被调用执行。具体请继续参照图8所示，还可以包括下面的流程。

步骤815：负载控制模块预测到第二资源服务器中空闲资源的数量小于第二阈值时，向第二调度器发送资源释放请求。所述资源释放请求用于请求释放部分资源。

步骤816：第二调度器确定需要中断执行的至少一个第二类型的任务。第二调度器可以将资源使用量最多的M个第二类型的任务，确定为需要中断执行的任务，也可以根据其他方法确定需要中断执行的任务。下面以第二调度器确定中断第二调度请求消息对应的任务为例进行描述，其他情况不再赘述。

步骤817：第二调度器向第二资源服务器发送任务中断请求，所述任务中断请求用于请求中断执行第二调度请求消息对应的任务，并释放对应的资源。

步骤818：第二资源服务器根据所述任务中断请求，中断执行第二调度请求消息对应的任务，并释放调度给该任务的资源。

步骤819：第二资源服务器向第二调度器发送任务中断响应，所述任务中断响应用于指示任务中断的结果。

步骤820：第二资源服务器向控制台发送任务中断通知消息，所述任务中断通知消息用于指示第二调度请求消息对应的任务被中断执行。

步骤821：控制台向租户转发任务中断通知消息。

通过上述方法，本申请实施例中，根据公有云环境下租户任务的差异性，对SLA敏感型任务采用根据资源请求量优先调度的方法，保证每个SLA敏感型任务在执行过程中都能够获取到足够的资源。对SLA不敏感的任务，采用根据资源实际使用量的调度方法，在充分使用SLA敏感任务请求但未使用的资源的同时，通过负载监控和预测，动态控制SLA不敏感任务的创建与中断，避免对SLA敏感任务的资源使用造成影响。

如图10所示，为本申请实施例提供的一种资源调度装置结构示意图。该装置1000包括：通信模块1001、处理器1002、存储器1003等。

本申请实施例中的通信模块1001可以为具有有线或无线通信能力的通信芯片，比如可以为射频收发器，也可以为网线接口等，用于执行上述方法流程中获取第一调度请求消息和第二调度请求消息的处理等。

本申请实施例中的处理器1002可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以实现上述过程中的确定是否调度资源服务器，并在确定的资源服务器中为相应的调度请求消息调度相应的资源等操作，还可以选择需要释放资源的任务，将为选择的任务释放占用的服务器资源等。

本申请实施例中的存储器1003可以为随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。处理器1002读取存储器1003中的信息，结合其硬件可以完成上述方法的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。