CN110377415A

CN110377415A - 一种请求处理方法和服务器

Info

Publication number: CN110377415A
Application number: CN201810327441.0A
Authority: CN
Inventors: 杨宏义; 赵清伟
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-04-12
Filing date: 2018-04-12
Publication date: 2019-10-25

Abstract

本申请实施例公开了一种请求处理方法和服务器，用于对SLA性能进行精确控制。本申请实施例提供一种请求处理方法，包括：调度服务器根据客户端发送的请求消息识别出租户；所述调度服务器根据历史请求资源用量确定出所述请求消息对应的资源需求量；所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期；所述调度服务器根据所述租户的租户资源配额和所述资源需求量为所述请求消息分配请求资源配额；所述调度服务器在所述调度周期内向所述应用服务器发送执行命令，所述执行命令用于指示所述应用服务器根据所述请求资源配额执行所述请求消息。

Description

一种请求处理方法和服务器

技术领域

本申请涉及计算机领域，尤其涉及一种请求处理方法和服务器。

背景技术

软件即服务(Software as a Service，SaaS)是一种通过互联网(Internet)提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商租用所需的应用软件服务，按租用的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务，消除了客户购买、构建和维护基础设施和应用程序的需要。

目前的SaaS解决方案都是基于多租户架构，且一般采用逻辑多租的多租户技术，多个租户完全共享同一个应用软件实例，依赖应用的逻辑来支持租户之间的隔离，从而实现多租。采用逻辑多租的SaaS系统，多个租户之间相互竞争使用资源，存在租户之间服务等级协议(Service Level Agreement，SLA)性能干扰现象，严重时导致部分租户无资源可用。

现有技术提出了多租户应用系统中的一种资源使用控制方法，其核心思想是基于控制周期，在控制周期内不断循环，每次循环时选取优先级最高的租户的入队最早的请求进行调度。主要包括如下过程：

步骤1：租户排序。根据控制周期内租户已获得的资源保障率P对租户请求优先级进行排序。

步骤2：发送1个请求。从请求优先级最高(即P值最小)的租户的请求队列中选取最早入队的一个请求，发送到应用服务器进行处理，并将该请求从请求队列中删除。

步骤3：处理资源需求。根据资源需求评估结果获取本次发送请求的资源需求，并将其累加到该租户已消耗资源量。

其中，资源需求评估过程如下：周期性的统计所有请求类型的总资源利用率、每种请求类型的响应时长、每种请求类型的吞吐量，根据这些统计数据计算每种请求类型的资源利用率。

上述现有技术至少存在如下缺点：当请求阻塞时，请求的响应时长并不是服务器处理请求任务对资源真实的占用时长，因此现有技术提供的前述方案中资源需求评估不准确，导致优先级计算存在偏差，SLA性能控制不准确。

发明内容

本申请实施例提供了一种请求处理方法和服务器，用于对SLA性能进行精确控制。

为解决上述技术问题，本申请实施例提供以下技术方案：

第一方面，本申请实施例提供一种请求处理方法，包括：调度服务器根据客户端发送的请求消息识别出租户；所述调度服务器根据历史请求资源用量确定出所述请求消息对应的资源需求量；所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期；所述调度服务器根据所述租户的租户资源配额和所述资源需求量为所述请求消息分配请求资源配额；所述调度服务器在所述调度周期内向所述应用服务器发送执行命令，所述执行命令用于指示所述应用服务器根据所述请求资源配额执行所述请求消息。

在本申请实施例中，调度服务器根据客户端发送的请求消息识别出租户，调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量，调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期，调度服务器根据租户的租户资源配额和资源需求量为请求消息分配请求资源配额，调度服务器在调度周期内向应用服务器发送执行命令，执行命令用于指示应用服务器根据请求资源配额执行请求消息。本申请实施例中调度服务器基于历史请求资源用量为每个请求消息确定出资源需求量，并根据每个请求消息的资源需求量以及应用服务器的总量获取到调度周期，针对每个租户设置租户资源配额，进而为每个请求消息分配请求资源配额，每个请求消息可以根据相应的请求资源配额实现调度，因此本申请实施例可以准确评估请求资源需求，精确控制每个租户的SLA性能。

在第一方面的一种可能设计中，所述方法还包括：所述调度服务器接收所述应用服务器发送的执行结果，所述执行结果包括：所述请求消息所占用的资源使用总量和是否执行成功的信息；所述调度服务器向所述客户端发送所述是否执行成功的信息。本申请实施例中应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息，应用服务器向调度服务器发送执行结果，调度服务器可以根据该执行结果确定出资源使用总量，调度服务器还可以向客户端转发请求消息是否执行成功的信息，使得客户端可以确定该请求消息是否执行成功。

在第一方面的一种可能设计中，所述方法还包括：所述调度服务器记录所述资源使用总量，并将所述资源使用总量更新到所述历史请求资源用量中。本申请实施例中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，调度服务器将资源使用总量更新到历史请求资源用量中，从而不断的维护历史请求资源用量，使得历史请求资源用量可以更准确的评估出各种请求类型对资源的实际需求量。

在第一方面的一种可能设计中，所述调度服务器根据历史请求资源用量确定出所述请求消息对应的资源需求量，包括：所述调度服务器获取所述请求消息对应的请求类型；所述调度服务器获取与所述请求类型的类型相同的最近N次的历史请求资源用量，所述N的取值为正整数；所述调度服务器根据所述最近N次的历史请求资源用量确定历史请求资源用量趋势信息；所述调度服务器根据所述历史请求资源用量趋势信息确定出所述资源需求量。本申请实施例中调度服务器根据该历史请求资源用量趋势来确定资源需求量。如果历史请求资源用量呈单调上升趋势，则需要在历史请求资源用量的基础上增加一些资源量作为资源需求量，如果历史请求资源用量呈无变化趋势，则可以将在历史请求资源用量作为资源需求量，如果历史请求资源用量呈单调下降趋势，则需要在历史请求资源用量的基础上减少一些资源量作为资源需求量，对于增加或者减少的资源量不做限定，取决于应用场景。

在第一方面的一种可能设计中，所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期，包括：所述调度服务器将所述请求消息、所述租户和所述资源需求量插入到请求列表中；所述调度服务器获取所述请求列表中所有请求消息对应的资源需求总量；所述调度服务器根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度。其中，调度服务器对于请求消息使用请求列表来统一管理，在每计算出一个请求消息的资源需求量之后都加入到请求列表中，则在请求列表中会存在多个请求消息，通过所有请求消息对应的资源需求量进行求和，可以得到一个资源需求总量，则基于资源需求总量和应用服务器处理请求的资源总量获取调度周期的长度。

在第一方面的一种可能设计中，所述调度服务器根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度，包括：当所述请求消息需要使用多种资源类型时，所述调度服务器针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为所述请求消息当前所处的调度周期。其中，若请求消息需要多种资源类型，则可以针对所需求的资源类型分别计算出一个调度周期，则对应于每种资源类型，都可以计算出一个调度周期，则从所有调度周期中确定出最大值，作为请求消息当前所处的调度周期，通过该最大值的调度周期作为请求消息当前所处的调度周期，从而可以保证应用服务器所使用的每种资源都可以在该调度周期内被正常使用。

在第一方面的一种可能设计中，所述方法还包括：当所述请求列表中所有请求消息在所述调度周期到达之前已经调度完成时，所述调度服务器将所述请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。其中，调度服务器可以对请求列表中所有的请求消息进行调度，请求列表中所有请求消息在调度周期到达之前已经调度完成时，说明当前的调度周期已经可以提前结束，此时以请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻，从而保证在下一个调度周期能够尽快开始调度，减少请求消息的调度时延。

在第一方面的一种可能设计中，当所述资源总量与时长无关时，所述应用服务器处理请求的资源总量为所述应用服务器所拥有的资源量；或，当所述资源总量与时长有关时，所述应用服务器处理请求的资源总量为所述应用服务器在单位时长内能够提供的资源量。其中，资源总量是应用服务器处理请求时所能提供的总的资源大小，根据资源类型的不同，可以分为与时长无关的资源总量，和与时长有关的资源总量，例如，CPU资源是与时长有关的资源类型，磁盘读写资源也是与时长有关的资源类型，而内存资源是与时长无关的资源类型。单位时长是应用服务器对资源的最小粒度划分，例如该单位时长可以是毫秒，或者更小的资源单位。

在第一方面的一种可能设计中，所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期之后，所述方法还包括：当所述资源总量与时长无关时，所述调度服务器根据所述应用服务器所拥有的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额；或，当所述资源总量与时长有关时，所述调度服务器根据所述调度周期的长度、所述应用服务器在单位时长内能够提供的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额。其中，若资源总量与时长无关，则只需要根据应用服务器所拥有的资源量和租户的租户资源权重就可以计算出租户的租户资源配额。若资源总量与时长有关，则需要根据调度周期的长度、应用服务器在单位时长内能够提供的资源量和租户的租户资源权重，计算出租户的租户资源配额。针对资源总量是否与时长有关，可以采用不同的方式计算租户资源配额，具体结合资源类型来确定租户资源配额的确定方式。

在第一方面的一种可能设计中，所述调度服务器在所述调度周期内向所述应用服务器发送执行命令之后，所述方法还包括：所述调度服务器从所述应用服务器获取正在执行的所述请求消息的资源已使用量；所述调度服务器确定所述资源已使用量是否超过使用量阈值；当所述资源已使用量没有超过所述使用量阈值、且所述请求消息使用的资源总量与时长无关时，所述调度服务器根据所述资源已使用量对所述资源需求量进行更新，得到更新后的资源需求量；所述调度服务器使用所述更新后的资源需求量重新获取所述请求消息当前所处的调度周期。其中，调度服务器还可以监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，该使用量阈值可以根据实际场景来确定。针对资源总量与时长无关的资源类型，调度服务器还可以更新资源需求，例如当资源已使用量没有超过使用量阈值、且请求消息使用的资源总量与时长无关时，调度服务器根据资源已使用量对资源需求量进行更新，得到更新后的资源需求量，接下来还可以使用更新后的资源需求量重新计算调度周期长度，另外，本申请实施例中还可以为请求重新分配资源配额。本申请实施例中通过对调度周期以及资源配额的实时计算，可以动态更新对请求消息的调度，解决周期长度难以确定的问题。

在第一方面的一种可能设计中，所述方法还包括：当所述资源已使用量超过所述使用量阈值时，所述调度服务器停止对所述请求消息的调度，并发送终止执行指令给所述应用服务器，以终止执行所述请求消息。其中，调度服务器监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，当资源已使用量超过使用量阈值时，调度服务器限制请求执行时对资源的占用，通知应用服务器及时终止资源使用量超过阈值的请求消息，用于解决请求过度占用资源问题。

在第一方面的一种可能设计中，所述调度服务器根据所述租户资源配额和所述资源需求量为所述请求消息分配请求资源配额，包括：所述调度服务器确定在前一个调度周期内所述租户是否存在未执行完成的请求消息；当存在未执行完成的请求消息时，所述调度服务器从所述租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。其中，调度服务器在为请求消息分配资源配额时，可以采用如下的资源配额分配方法，优先将资源配额分配给其上个调度周期未执行完的请求消息，再分配给未执行的请求消息，该未执行的请求消息指的是在本调度周期新加入的请求消息，以使得上个调度周期未执行完的请求消息能够被优先分配到资源配额，从而保证未执行完成的请求消息能够被优先调度，减少请求消息的处理时延。

在第一方面的一种可能设计中，所述方法还包括：当所述调度服务器为所述未执行完成的请求消息以及所述未执行的请求消息都分配过请求资源配额之后，所述租户资源配额还存在剩余配额时，所述调度服务器从所述剩余配额中为除所述租户之外的其它租户对应的请求消息分配请求资源配额。其中，调度服务器在为请求消息分配资源配额时，可以采用如下的资源配额分配方法，以某个租户为例，该租户的所有请求消息都分配到请求资源配额后，如果该租户的租户资源配额仍存在剩余配额，则将剩余配额分配给其他租户的请求消息，其它租户是不同于已经分配过请求资源配额的租户，使得其他租户的请求消息也可以分配到资源配额，从而保证其他租户的请求消息能够被调度，减少请求消息的处理时延。

第二方面，本申请实施例提供一种请求处理方法，包括：应用服务器接收调度服务器在调度周期内发送的执行命令，所述执行命令包括：客户端发送的请求消息和所述调度服务器为所述请求消息分配的请求资源配额；所述应用服务器根据所述请求资源配额从所述应用服务器处理请求的资源总量中为所述请求消息分配资源；所述应用服务器使用所述资源执行所述请求消息，并按照所述请求资源配额对所述请求消息在执行过程中所占用的资源进行限额控制。本申请实施例中应用服务器可以按照调度服务器确定的请求资源配额来为请求消息分配资源，并且还可以按照请求资源配额对请求消息在执行过程中所占用的资源进行限额控制，因此本申请实施例可以准确评估请求资源需求，精确控制每个租户的SLA性能。

在第二方面的一种可能设计中，所述方法还包括：所述应用服务器在执行所述请求消息的过程中度量所述请求消息所使用的资源，并生成资源使用总量，以及生成所述请求消息是否执行成功的信息；所述应用服务器向所述调度服务器发送执行结果，所述执行结果包括：所述资源使用总量和所述是否执行成功的信息。其中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息。资源使用总量是请求消息在实际执行过程中所使用的实际资源，应用服务器存储该资源使用总量到历史请求资源用量中，以便评估同类型请求的资源需求量。请求消息是否执行成功的信息指示了应用服务器执行请求消息是否成功。

在第二方面的一种可能设计中，所述方法还包括：所述应用服务器获取正在执行的所述请求消息的资源已使用量；所述应用服务器向所述调度服务器发送所述资源已使用量。其中，应用服务器可以实时统计每个请求消息的资源已使用量，并及时向调度服务器反馈，则调度服务器可以监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，该使用量阈值可以根据实际场景来确定。

在第二方面的一种可能设计中，所述方法还包括：所述应用服务器接收所述调度服务器通知的终止执行指令，并根据所述终止执行指令终止执行所述请求消息。其中，调度服务器监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，当资源已使用量超过使用量阈值时，调度服务器限制请求执行时对资源的占用，调度服务器限制请求执行时对资源的占用，通知应用服务器及时终止资源使用量超过阈值的请求消息，用于解决请求过度占用资源问题。

第三方面，本申请实施例提供一种调度服务器，包括：

处理模块，用于根据客户端发送的请求消息识别出租户；

所述处理模块，还用于根据历史请求资源用量确定出所述请求消息对应的资源需求量；

所述处理模块，还用于根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期；

所述处理模块，还用于根据所述租户的租户资源配额和所述资源需求量为所述请求消息分配请求资源配额；

发送模块，用于在所述调度周期内向所述应用服务器发送执行命令，所述执行命令用于指示所述应用服务器根据所述请求资源配额执行所述请求消息。

在第三方面的一种可能设计中，所述调度服务器还包括：

接收模块，用于接收所述应用服务器发送的执行结果，所述执行结果包括：所述请求消息所占用的资源使用总量和是否执行成功的信息；

所述发送模块，还用于向所述客户端发送所述是否执行成功的信息。

在第三方面的一种可能设计中，所述处理模块，还用于记录所述资源使用总量，并将所述资源使用总量更新到所述历史请求资源用量中。

在第三方面的一种可能设计中，所述处理模块，具体用于获取所述请求消息对应的请求类型；获取与所述请求类型的类型相同的最近N次的历史请求资源用量，所述N的取值为正整数；根据所述最近N次的历史请求资源用量确定历史请求资源用量趋势信息；根据所述历史请求资源用量趋势信息确定出所述资源需求量。

在第三方面的一种可能设计中，所述处理模块，具体用于将所述请求消息、所述租户和所述资源需求量插入到请求列表中；获取所述请求列表中所有请求消息对应的资源需求总量；根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度。

在第三方面的一种可能设计中，所述处理模块，具体用于当所述请求消息需要使用多种资源类型时，针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为所述请求消息当前所处的调度周期。

在第三方面的一种可能设计中，所述处理模块，还用于当所述请求列表中所有请求消息在所述调度周期到达之前已经调度完成时，将所述请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。

在第三方面的一种可能设计中，当所述资源总量与时长无关时，所述应用服务器处理请求的资源总量为所述应用服务器所拥有的资源量；或，当所述资源总量与时长有关时，所述应用服务器处理请求的资源总量为所述应用服务器在单位时长内能够提供的资源量。

在第三方面的一种可能设计中，所述处理模块，具体用于根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期之后，当所述资源总量与时长无关时，根据所述应用服务器所拥有的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额；或，当所述资源总量与时长有关时，根据所述调度周期的长度、所述应用服务器在单位时长内能够提供的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额。

在第三方面的一种可能设计中，所述处理模块，还用于在所述调度周期内向所述应用服务器发送执行命令之后，从所述应用服务器获取正在执行的所述请求消息的资源已使用量；确定所述资源已使用量是否超过使用量阈值；当所述资源已使用量没有超过所述使用量阈值、且所述请求消息使用的资源总量与时长无关时，根据所述资源已使用量对所述资源需求量进行更新，得到更新后的资源需求量；使用所述更新后的资源需求量重新获取所述请求消息当前所处的调度周期。

在第三方面的一种可能设计中，所述处理模块，还用于当所述资源已使用量超过所述使用量阈值时，停止对所述请求消息的调度；

所述发送模块，还用于发送终止执行指令给所述应用服务器，以终止执行所述请求消息。

在第三方面的一种可能设计中，所述处理模块，具体用于确定在前一个调度周期内所述租户是否存在未执行完成的请求消息；当存在未执行完成的请求消息时，从所述租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。

在第三方面的一种可能设计中，所述处理模块，还用于当为所述未执行完成的请求消息以及所述未执行的请求消息都分配过请求资源配额之后，所属租户资源配额还存在剩余配额时，从所述剩余配额中为除所述租户之外的其它租户对应的请求消息分配请求资源配额。

在本申请的第三方面中，应用服务器的组成模块还可以执行前述第一方面以及各种可能的实现方式中所描述的步骤，详见前述对第一方面以及各种可能的实现方式中的说明。

第四方面，本申请实施例提供一种应用服务器，包括：

接收模块，用于接收调度服务器在调度周期内发送的执行命令，所述执行命令包括：客户端发送的请求消息和所述调度服务器为所述请求消息分配的请求资源配额；

处理模块，用于根据所述请求资源配额从所述应用服务器处理请求的资源总量中为所述请求消息分配资源；

所述处理模块，还用于使用所述资源执行所述请求消息，并按照所述请求资源配额对所述请求消息在执行过程中所占用的资源进行限额控制。

在第四方面的一种可能设计中，所述应用处理器，还包括：发送模块，其中，

所述处理模块，还用于在执行所述请求消息的过程中度量所述请求消息所使用的资源，并生成资源使用总量，以及生成所述请求消息是否执行成功的信息；

所述发送模块，用于向所述调度服务器发送执行结果，所述执行结果包括：所述资源使用总量和所述是否执行成功的信息。

在第四方面的一种可能设计中，所述应用服务器，还包括：发送模块，其中，

所述处理模块，还用于获取正在执行的所述请求消息的资源已使用量；

所述发送模块，还用于向所述调度服务器发送所述资源已使用量。

在第四方面的一种可能设计中，所述接收模块，还用于接收所述调度服务器通知的终止执行指令；

所述处理模块，还用于根据所述终止执行指令终止执行所述请求消息。

在本申请的第四方面中，应用服务器的组成模块还可以执行前述第二方面以及各种可能的实现方式中所描述的步骤，详见前述对第二方面以及各种可能的实现方式中的说明。

第五方面，本申请实施例提供一种服务器，所述服务器为调度服务器或者应用服务器，所述服务器包括：处理器，存储器；所述处理器、所述存储器进行相互的通信；

所述存储器，用于存储指令；

所述处理器，用于执行所述存储器中的所述指令，执行前述第一方面或第二方面中的任一项所述的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

第七方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

第八方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于支持调度服务器或者应用服务器实现上述方面中所涉及的功能，例如，例如发送或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存调度服务器或者应用服务器必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。

附图说明

图1为本申请实施例提供的一种请求处理方法所应用的系统内的连接结构示意图；

图2为本申请实施例提供的客户端、调度服务器和应用服务器之间的一种交互流程示意图；

图3为本申请实施例提供的一种请求处理方法的流程方框示意图；

图4为本申请实施例提供的另一种请求处理方法的流程方框示意图；

图5为本申请实施例提供的请求处理方法所应用的系统内的各个组成部分示意图；

图6为本申请实施例提供的客户端、调度服务器和应用服务器之间的另一种交互流程示意图；

图7为本申请实施例提供的资源需求评估流程示意图；

图8为本申请实施例提供的未执行完请求的处理流程示意图；

图9为本申请实施例提供的当前调度周期提前结束的示意图；

图10为本申请实施例提供的租户资源配额的分配流程示意图；

图11为本申请实施例提供的一种调度服务器的组成结构示意图；

图12为本申请实施例提供的一种应用服务器的组成结构示意图；

图13为本申请实施例提供的另一种调度服务器的组成结构示意图；

图14为本申请实施例提供的另一种应用服务器的组成结构示意图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

请参阅图1所示，为本申请实施例提供的一种请求处理方法所应用的系统内的连接结构示意图。该系统可以包括：客户端、调度服务器和系统服务器，其中客户端和调度服务器之间可以进行通信，例如采用无线或者有线的方式，客户端有请求需要执行时，向调度服务器发送请求消息，调度服务器可以调度该请求消息。本申请实施例中，调度服务器可以基于请求执行过程中实际度量的资源用量，评估请求资源需求，请求执行过程时，根据请求资源配额为请求分配资源，限制请求对资源的占用。调度服务器采用动态调度周期，基于调度周期为租户分配资源配额，并根据租户资源配额和请求资源需求为请求分配资源配额。调度服务器和应用服务器之间建立有通信连接，该应用服务器提供处理请求的资源，该资源具体可以包括：中央处理器(Central Processing Unit，CPU)资源、内存资源、磁盘输入/输出(Input/Output，I/O)资源、网络I/O资源，在请求消息执行之后，应用服务器向调度服务器发送分配响应，调度服务器再向客户端发送请求消息的执行结果。

请求参阅图2所示，为本申请实施例提供的客户端、调度服务器和应用服务器之间的一种交互流程示意图，主要包括如下流程：

S01、客户端向调度服务器发送请求消息。

其中，客户端需要执行请求时，客户端生成请求消息，若有多个请求需要执行，客户端发送每个请求消息，则调度服务器可以接收到多个请求消息。以客户端发送的某个请求消息为例，调度服务器可以从客户端接收到该请求消息，不限定的是，调度服务器还可以接收到其它的请求消息。

S02、调度服务器根据客户端发送的请求消息识别出租户。

其中，调度服务器收到请求消息之后，可以识别出该请求消息所属的租户。

S03、调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量。

其中，历史请求资源用量由应用服务器度量之前的调度周期内的请求资源实际用量来确定，调度服务器可以根据应用服务器度量的历史请求资源用量，计算出请求消息执行过程中所需的资源，即计算出请求消息所需要的资源量，该资源需求量是对请求消息所需要的资源进行评估后得到的结果。

S04、调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期。

其中，调度服务器为请求消息评估出资源需求量之后，调度服务器再计算出同时收到的每个请求消息对应的资源需求量，调度服务器根据每个请求消息对应的资源需求量以及应用服务器处理请求的资源总量获取调度周期，该调度周期是指对于截止当前时间点收到的所有尚未处理的请求消息被执行完成所需要的时间长度。其中，应用服务器处理请求的资源总量，是指应用服务器所具有的实际资源数量，请求消息只有在应用服务器为其分配资源时才能被执行完成，例如有的请求消息需要分配CPU资源才能执行完成，有的请求消息需要分配I/O资源才能执行完成，具体结合应用场景来确定。

在本申请的一些实施例中，调度服务器除了执行前述步骤之外，还可以包括如下步骤：调度服务器根据应用服务器处理请求的资源总量和预配置的租户资源权重获取租户的租户资源配额。

其中，调度服务器识别出每个请求消息所属的租户之后，根据不同租户的租户资源权重以及应用服务器处理请求的资源总量，为每个租户计算出租户资源配额，即对每个租户设置一个租户资源配额，该租户下的所有请求所分配的资源总和不能超过租户资源配额，以保证各个租户是相互隔离，避免各个租户的SLA性能受到相互影响。租户资源权重可以根据实际场景确定，例如某个租户的优先级高，那么该租户的租户资源权重就大，该租户可以分配到的租户资源配额就越多。

S05、调度服务器根据租户资源配额和资源需求量为请求消息分配请求资源配额。

其中，调度服务器确定出租户的租户资源配额以及该资源需求量之后，对于请求消息，其所分配的资源配额等于其所需的资源需求量，例如为请求消息分配到请求资源配额，该请求资源配额是分配给请求消息的资源量，因此在调度请求消息时按照该请求资源配额来调度，即为请求消息调度的资源量不会超过该请求资源配额，从而可以控制请求消息对资源的实际占用量，达到限制请求对资源的占用的目的。

S06、调度服务器在调度周期内向应用服务器发送执行命令，执行命令用于指示应用服务器根据请求资源配额执行所述请求消息。

其中，调度服务器为请求消息分配了请求资源配额之后，调度服务器还需要请求应用服务器来执行该请求消息，并且调度服务器发送的执行命令中需要携带请求消息和请求资源配额，从而应用服务器可以根据该请求资源配额来限制请求消息对资源的占用，避免过量占用资源。

S07、应用服务器根据请求资源配额从应用服务器处理请求的资源总量中为请求消息分配资源。

其中，应用服务器可以根据调度服务器确定的请求资源配额为请求消息分配资源，该资源是从应用服务器处理请求的资源总量中分配给请求消息。

S08、应用服务器使用资源执行请求消息，并按照请求资源配额对请求消息在执行过程中所占用的资源进行限额控制。

其中，应用服务器为请求消息分配了资源之后，该资源可以用于执行请求消息，从而保证请求消息的执行。应用服务器还需要按照请求资源配额对请求消息在执行过程中所占用的资源进行限额控制，以避免过量占用资源。

S09、应用服务器向调度服务器发送执行结果，执行结果包括：请求消息所使用的资源使用总量和请求消息是否执行成功的信息。

其中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息。资源使用总量是请求消息在实际执行过程中所使用的实际资源，应用服务器存储该资源使用总量到历史请求资源用量中，以便评估同类型请求的资源需求量。执行请求消息的执行结果可以是执行请求消息是否成功，或者是执行请求消息的反馈结果等。

S10、调度服务器向客户端发送是否执行成功的信息。

在本申请实施例中，调度服务器从应用服务器获取到请求消息是否执行成功的信息之后，调度服务器向客户端转发是否执行成功的信息，从而客户端通过该是否执行成功的信息可以确定出请求消息是否执行成功。

通过前述实施例对本申请的举例说明可知，调度服务器根据客户端发送的请求消息识别出租户，调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量，调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期，调度服务器根据租户资源配额和资源需求量为请求消息分配请求资源配额，调度服务器在调度周期内向应用服务器发送执行命令，执行命令用于指示应用服务器根据请求资源配额执行请求消息。本申请实施例中调度服务器基于历史请求资源用量为每个请求消息确定出资源需求量，并根据每个请求消息的资源需求量以及应用服务器的总量获取到调度周期，针对每个租户设置租户资源配额，进而为每个请求消息分配请求资源配额，每个请求消息可以根据相应的请求资源配额实现调度，因此本申请实施例可以准确评估请求资源需求，精确控制每个租户的SLA性能。

接下来从调度服务器和应用服务器的角度分别描述本申请实施例提供的请求处理方法，首先请参阅图3所示，本申请实施例提供一种请求处理方法，包括：

301、调度服务器根据客户端发送的请求消息识别出租户。

其中，调度服务器收到请求消息之后，可以识别出该请求消息所属的租户，例如通过该请求消息确定出用户标识，根据该用户标识确定出租户为租户。

需要说明的是，客户端可以发送多个请求消息，本实施例中以一个请求消息的执行过程为例，不限定的是，客户端还可以发送其它请求消息，那么调度服务器需要识别出每个请求消息对应的租户。

302、调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量。

在本申请的一些实施例中，步骤302调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量，包括：

调度服务器获取请求消息对应的请求类型；

调度服务器获取与请求类型的类型相同的最近N次的历史请求资源用量，N的取值为正整数；

调度服务器根据最近N次的历史请求资源用量确定历史请求资源用量趋势信息；

调度服务器根据历史请求资源用量趋势信息确定出资源需求量。

其中，请求消息的类型可以有多种，例如根据请求消息对应的请求类型，选择同类型的最近N次的历史请求资源用量，N的取值为正整数，例如N的取值为5。通过分析最近N次的历史请求资源用量来分析历史请求资源用量趋势，最后根据该历史请求资源用量趋势来确定资源需求量。举例说明，如果历史请求资源用量呈单调上升趋势，则需要在历史请求资源用量的基础上增加一些资源量作为资源需求量，如果历史请求资源用量呈无变化趋势，则可以将在历史请求资源用量作为资源需求量，如果历史请求资源用量呈单调下降趋势，则需要在历史请求资源用量的基础上减少一些资源量作为资源需求量，对于增加或者减少的资源量不做限定，取决于应用场景。

303、调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期。

其中，调度服务器为请求消息评估出资源需求量之后，调度服务器再计算出同时收到的每个请求消息对应的资源需求量，调度服务器根据每个请求消息对应的资源需求量以及应用服务器处理请求的资源总量获取调度周期，该调度周期是指对于截止当前时间点收到的所有尚未处理的请求消息被执行完成所需要的时间长度，当每个请求消息对资源的需求不相同时，需要计算出实时的调度周期。其中，应用服务器处理请求的资源总量，是指应用服务器所具有的实际资源数量，请求消息只有在应用服务器为其分配资源时才能被执行完成，例如有的请求消息需要分配CPU资源才能执行完成，有的请求消息需要分配I/O资源才能执行完成，具体结合应用场景来确定。

在本申请的一些实施例中，步骤303调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期，包括：

调度服务器将请求消息、租户和资源需求量插入到请求列表中；

调度服务器获取请求列表中所有请求消息对应的资源需求总量；

调度服务器根据资源需求总量和应用服务器处理请求的资源总量获取调度周期的长度。

其中，调度服务器对于请求消息使用请求列表来统一管理，在每计算出一个请求消息的资源需求量之后都加入到请求列表中，则在请求列表中会存在多个请求消息，通过所有请求消息对应的资源需求量进行求和，可以得到一个资源需求总量，则基于资源需求总量和应用服务器处理请求的资源总量获取调度周期的长度。举例说明如下：调度周期的长度＝请求列表中所有请求的资源需求总量/应用服务器每毫秒的资源总量。通过实时计算，针对请求列表中的不同请求消息，都可以动态的计算出在当前的处理过程中所需要的调度周期的长度。

在本申请的一些实施例中，调度服务器根据资源需求总量和应用服务器处理请求的资源总量获取调度周期的长度，包括：

当请求消息需要使用多种资源类型时，调度服务器针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为请求消息当前所处的调度周期。

其中，若请求消息需要多种资源类型，例如需要使用CPU资源，也需要使用内存资源，则可以针对所需求的资源类型分别计算出一个调度周期，则对应于每种资源类型，都可以计算出一个调度周期，则从所有调度周期中确定出最大值，作为请求消息当前所处的调度周期，通过该最大值的调度周期作为请求消息当前所处的调度周期，从而可以保证应用服务器所使用的每种资源都可以在该调度周期内被正常使用。

进一步的，在本申请的一些实施例中，本申请实施例提供的请求处理方法还包括：

当请求列表中所有请求消息在调度周期到达之前已经调度完成时，调度服务器将请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。

其中，调度服务器可以对请求列表中所有的请求消息进行调度，请求列表中所有请求消息在调度周期到达之前已经调度完成时，说明当前的调度周期已经可以提前结束，此时以请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻，从而保证在下一个调度周期能够尽快开始调度，减少请求消息的调度时延。

在本申请的一些实施例中，当资源总量与时长无关时，应用服务器处理请求的资源总量为应用服务器所拥有的资源量；或，当资源总量与时长有关时，应用服务器处理请求的资源总量为应用服务器在单位时长内能够提供的资源量。

其中，资源总量是应用服务器处理请求时所能提供的总的资源大小，根据资源类型的不同，可以分为与时长无关的资源总量，和与时长有关的资源总量，例如，CPU资源是与时长有关的资源类型，磁盘读写资源也是与时长有关的资源类型，而内存资源是与时长无关的资源类型。单位时长是应用服务器对资源的最小粒度划分，例如该单位时长可以是毫秒，或者更小的资源单位。

在本申请的一些实施例中，调度服务器除了执行前述步骤之外，还可以包括如下步骤：

调度服务器根据应用服务器处理请求的资源总量和预配置的租户资源权重获取租户的租户资源配额。

其中，调度服务器识别出每个请求消息所属的租户之后，根据不同租户的租户资源权重以及应用服务器处理请求的资源总量，为每个租户计算出租户资源配额，即对每个租户设置一个租户资源配额，该租户下的所有请求所分配的资源总和不能超过租户资源配额，以保证各个租户是相互隔离，避免各个租户的SLA性能受到相互影响。租户资源权重可以根据实际场景确定，例如某个租户的优先级高，那么该租户的租户资源权重就大，该租户可以分配到的租户资源配额就越多。例如，根据请求消息所属的租户确定出该租户的租户资源配额。

进一步的，在本申请的一些实施例中，调度服务器根据应用服务器处理请求的资源总量和预配置的租户资源权重获取租户的租户资源配额，包括：

当资源总量与时长无关时，调度服务器根据应用服务器所拥有的资源量和租户的租户资源权重，获取租户的租户资源配额；或，

当资源总量与时长有关时，调度服务器根据调度周期的长度、应用服务器在单位时长内能够提供的资源量和租户的租户资源权重，获取租户的租户资源配额

其中，若资源总量与时长无关，则只需要根据应用服务器所拥有的资源量和租户的租户资源权重就可以计算出租户的租户资源配额，例如，对于与时长无关的资源类型，租户资源配额＝应用服务器资源总量*租户资源权重，*表示相乘。若资源总量与时长有关，则需要根据调度周期的长度、应用服务器在单位时长内能够提供的资源量和租户的租户资源权重，计算出租户的租户资源配额。例如，对于与时长有关的资源类型，租户资源配额＝应用服务器每毫秒的资源总量*调度周期长度*租户资源权重，*表示相乘。

304、调度服务器根据租户的租户资源配额和资源需求量为请求消息分配请求资源配额，并根据请求资源配额对请求消息进行调度。

其中，调度服务器确定出租户的租户资源配额以及该资源需求量之后，对于请求消息，其所分配的资源配额等于其所需的资源需求量，例如为请求消息分配到请求资源配额，该请求资源配额是分配给请求消息的资源量，因此应用服务器在处理该请求消息时按照该请求资源配额来进行处理，即为请求消息分配的资源不会超过该请求资源配额，从而可以控制请求消息对资源的实际占用量，达到限制请求对资源的占用的目的。

举例说明，对于每一个请求消息，其所分配的资源配额等于其所需的资源需求。如：请求1的CPU时长需求为100ms，则其所分配的CPU时长配额也为100ms。

在本申请的一些实施例中，步骤304调度服务器根据租户资源配额和资源需求量为请求消息分配请求资源配额，包括：

调度服务器确定在前一个调度周期内租户是否存在未执行完成的请求消息；

当存在未执行完成的请求消息时，调度服务器从租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。

其中，调度服务器在为请求消息分配资源配额时，可以采用如下的资源配额分配方法，优先将资源配额分配给其上个调度周期未执行完的请求消息，再分配给未执行的请求消息，该未执行的请求消息指的是在本调度周期新加入的请求消息，以使得上个调度周期未执行完的请求消息能够被优先分配到资源配额，从而保证未执行完成的请求消息能够被优先调度，减少请求消息的处理时延。

进一步的，在本申请的一些实施例中，本申请实施例提供的请求处理方法还可以包括如下步骤：

当调度服务器为未执行完成的请求消息以及未执行的请求消息都分配过请求资源配额之后，租户资源配额还存在剩余配额时，调度服务器从剩余配额中为除租户之外的其它租户对应的请求消息分配请求资源配额。

其中，调度服务器在为请求消息分配资源配额时，可以采用如下的资源配额分配方法，以某个租户为例，该租户的所有请求消息都分配到请求资源配额后，如果该租户的租户资源配额仍存在剩余配额，则将剩余配额分配给其他租户的请求消息，其它租户是不同于已经分配过请求资源配额的租户，使得其他租户的请求消息也可以分配到资源配额，从而保证其他租户的请求消息能够被调度，减少请求消息的处理时延。

305、调度服务器在调度周期内向应用服务器发送执行命令，执行命令用于指示应用服务器根据请求资源配额执行请求消息。

在本申请的一些实施例中，本申请实施例提供的请求处理方法还包括：

调度服务器接收应用服务器发送的执行结果，执行结果包括：请求消息所占用的资源使用总量和是否执行成功的信息；

调度服务器向客户端发送是否执行成功的信息。

其中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息，应用服务器向调度服务器发送执行结果，调度服务器可以根据该执行结果确定出资源使用总量，调度服务器还可以向客户端转发请求消息是否执行成功的信息，使得客户端可以确定该请求消息是否执行成功。

可选的，在本申请的一些实施例中，本申请实施例提供的请求处理方法还包括：

调度服务器记录资源使用总量，并将资源使用总量更新到历史请求资源用量中。

其中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，调度服务器将资源使用总量更新到历史请求资源用量中，从而不断的维护历史请求资源用量，使得历史请求资源用量可以更准确的评估出各种请求类型对资源的实际需求量。

调度服务器从应用服务器获取正在执行的请求消息的资源已使用量；

调度服务器确定资源已使用量是否超过使用量阈值；

当资源已使用量没有超过使用量阈值、且请求消息使用的资源总量与时长无关时，调度服务器根据资源已使用量对资源需求量进行更新，得到更新后的资源需求量；

调度服务器使用更新后的资源需求量重新获取请求消息当前所处的调度周期。

其中，调度服务器还可以监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，该使用量阈值可以根据实际场景来确定。针对资源总量与时长无关的资源类型，调度服务器还可以更新资源需求，例如当资源已使用量没有超过使用量阈值、且请求消息使用的资源总量与时长无关时，调度服务器根据资源已使用量对资源需求量进行更新，得到更新后的资源需求量，接下来还可以使用更新后的资源需求量重新计算调度周期长度，另外，本申请实施例中还可以为请求重新分配资源配额。本申请实施例中通过对调度周期以及资源配额的实时计算，可以动态更新对请求消息的调度，解决周期长度难以确定的问题。

当资源已使用量超过使用量阈值时，调度服务器停止对请求消息的调度，并发送终止执行指令给应用服务器，以终止执行请求消息。

其中，调度服务器监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，当资源已使用量超过使用量阈值时，调度服务器限制请求执行时对资源的占用，通知应用服务器及时终止资源使用量超过阈值的请求消息，用于解决请求过度占用资源问题。

通过前述实施例对本申请的举例说明可知，调度服务器根据客户端发送的请求消息识别出租户，调度服务器根据历史请求资源用量确定出请求消息对应的资源需求量，调度服务器根据资源需求量和应用服务器处理请求的资源总量获取请求消息当前所处的调度周期，调度服务器根据租户资源配额和资源需求量为请求消息分配请求资源配额，调度服务器在调度周期内向应用服务器发送执行命令。本申请实施例中调度服务器基于历史请求资源用量为每个请求消息确定出资源需求量，并根据每个请求消息的资源需求量以及应用服务器的总量获取到调度周期，针对每个租户设置租户资源配额，进而为每个请求消息分配请求资源配额，每个请求消息可以根据相应的请求资源配额实现调度，因此本申请实施例可以准确评估请求资源需求，精确控制每个租户的SLA性能。

前述实施例从调度服务器说明了本申请实施例提供的请求处理方法，接下来从应用服务器一侧来说明本申请实施例提供的请求处理方法，请参阅图4所示，本申请实施例提供的请求处理方法，包括：

401、应用服务器接收调度服务器在调度周期内发送的执行命令，执行命令包括：客户端发送的请求消息和调度服务器为请求消息分配的请求资源配额。

在本申请实施例中，调度服务器用于对客户端发送的请求消息进行请求资源配额的确定和请求消息的调度，应用服务器用于对请求消息进行资源分配以及限额控制，例如以某个请求消息的处理过程为例，调度服务器发送执行命令，该执行命令包括：客户端发送的请求消息和调度服务器为请求消息分配的请求资源配额，则应用服务器通过该执行命令可以获取到请求消息和请求资源配额。

402、应用服务器根据请求资源配额从应用服务器处理请求的资源总量中为请求消息分配资源。

其中，应用服务器可以根据调度服务器确定的请求资源配额为请求消息分配资源，将分配给请求消息的资源定义为资源，该资源是从应用服务器处理请求的资源总量中分配给请求消息。应用服务器为请求消息分配的资源类型不做限定，具体结合具体场景。

403、应用服务器使用资源执行请求消息，并按照请求资源配额对请求消息在执行过程中所占用的资源进行限额控制。

应用服务器在执行所述请求消息的过程中度量所述请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息；

应用服务器向调度服务器发送执行结果，执行结果包括：资源使用总量和是否执行成功的信息。

其中，应用服务器在执行请求消息的过程中度量请求消息所使用的资源，并生成资源使用总量，以及生成请求消息是否执行成功的信息。资源使用总量是请求消息在实际执行过程中所使用的实际资源，应用服务器存储该资源使用总量到历史请求资源用量中，以便评估同类型请求的资源需求量。请求消息是否执行成功的信息指示了应用服务器执行请求消息是否成功。

应用服务器获取正在执行的请求消息的资源已使用量；

应用服务器向调度服务器发送资源已使用量。

其中，应用服务器可以实时统计每个请求消息的资源已使用量，并及时向调度服务器反馈，则调度服务器可以监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，该使用量阈值可以根据实际场景来确定。

应用服务器接收调度服务器通知的终止执行指令，并根据终止执行指令终止执行请求消息。

其中，调度服务器监控每个请求消息的调度，判断资源已使用量是否超过使用量阈值，当资源已使用量超过使用量阈值时，调度服务器限制请求执行时对资源的占用，调度服务器限制请求执行时对资源的占用，通知应用服务器及时终止资源使用量超过阈值的请求消息，用于解决请求过度占用资源问题。

通过前述实施例对本申请的举例说明可知，本申请实施例中应用服务器可以按照调度服务器确定的请求资源配额来为请求消息分配资源，并且还可以按照请求资源配额对请求消息在执行过程中所占用的资源进行限额控制，因此本申请实施例可以准确评估请求资源需求，精确控制每个租户的SLA性能。

为便于更好的理解和实施本申请实施例的上述方案，下面举例相应的应用场景来进行具体说明。

本申请实施例提供的请求处理方法中，基于请求执行过程中实际度量的资源用量，评估请求资源需求。根据请求资源需求，设置请求资源配额。请求执行过程时，根据请求资源配额为请求分配资源，限制请求对资源的占用。采用动态调度周期，基于调度周期为租户分配资源配额，并根据租户资源配额和请求资源需求为请求分配资源配额。

本申请实施例主要涉及三类网元：客户端、调度服务器与应用服务器。如图5所示，本申请实施例中系统内的主要构成模块及其功能如下。

客户端用于产生和发送请求消息，并接收响应消息。客户端可以是电脑、手机、机顶盒或其它任何支持用户与服务器间通讯的设备。客户端发送的请求消息的个数可以是多个，或者多个客户端中每个客户端都发送至少一个请求消息，后续实施例中将请求消息简称为请求。

调度服务器用于将客户端的请求消息转发给应用服务器，计算每个租户的配额，然后给每个请求分配资源量，并将应用服务器的响应消息转发给客户端。调度服务器可以是物理集群或者虚拟云等。调度服务器可以包括：数据存储模块、请求接收模块、请求调度模块。

应用服务器用于执行由调度服务器转发来的请求消息，并返回响应消息。应用服务器可以是物理集群或者虚拟云等。应用服务器可以包括：请求资源控制模块。

接下来首先对调度服务器中的各个模块进行说明，数据存储模块位于调度服务器。用于保存请求接收或调度所依赖的数据。该数据存储模块中存储了如下信息：

1)、租户资源权重。

保存每个租户每种资源类型的权重，即应用服务器应分配给每个租户每种资源的数量占应用服务器该资源总数量的百分比，所有租户同一资源类型的权重之和应为100％。例如：租户1的CPU时长权重为50％，租户2的CPU时长权重为30％，租户3的CPU时长权重为20％。本申请实施例中，应用服务器的资源，除了指CPU资源，还可以是内存资源、I/O资源。

租户资源权重可根据SLA定义的每个租户SLA性能指标计算获得，具体计算此处不再赘述。

2)、历史请求数据。

该历史请求数据中保存之前一段时间内每一个请求消息的相关数据，例如：请求所属租户、请求类型、请求开始执行时间、请求结束执行时间、请求消息资源用量。其中，

请求类型可表示具有对同类型资源需求相同或接近的一类请求。例如：请求R1执行时需占用CPU时长100ms、内存10435字节(Byte)，请求R2执行时需占用CPU时长100ms、内存10440Byte，则可以将R1和R2划分为相同的请求类型。一般根据租户、请求消息(如：HTTP消息的方法、URL、参数、请求消息头、请求消息体等)等确定请求类型。

请求消息资源用量：应用服务器在执行请求消息过程中，度量的每种资源实际使用量，通过响应消息返回给调度服务器。

3)、当前请求列表。

该当前请求列表中保存调度服务器当前接收到的所有请求消息。

接下来对请求接收模块进行举例说明，请求接收模块位于调度服务器，用于接收客户端发送的每个请求消息，识别请求消息所属租户，评估请求资源需求，并将请求消息及其资源需求插入请求列表，等待请求调度模块统一调度。

该请求接收模块，可以包括：租户识别单元和资源需求评估单元。

其中，租户识别单元，用于识别每个请求消息所属租户。

资源需求评估单元，用于根据应用服务器度量的历史请求资源用量，计算出请求消息执行过程中所需的资源。例如：CPU时长、内存大小、I/O次数等。

接下来对请求调度模块进行说明，该请求调度模块位于调度服务器，用于对当前请求列表中的请求进行统一调度，为每个请求设置资源配额，并将请求发送到应用服务器处理。包括：调度周期长度计算、租户资源配额计算、请求资源配额分配、与应用服务器交互请求和记录请求数据。这里租户资源配额分配具体就是将租户的资源配额分配给请求。比如：租户资源配额为100，请求1的资源需求为10，请求2的资源需求为30，请求3的资源需求为60，将租户资源配额分配给请求1～3后，租户剩余资源配额为0，请求1分配到资源配额为10，请求2分配到资源配额为30，请求3分配到资源配额为60。

该请求调度模块，可以包括：调度周期计算单元、租户配额计算单元、租户配额分配单元、请求交互和记录单元。

其中，调度周期计算单元用于根据当前所有请求资源需求总量和应用服务器每毫秒资源总量，自动计算每一个调度周期长度。这里的当前所有请求是截止当前时间点，调度服务收到的所有尚未处理的请求。

租户配额计算单元用于根据调度周期长度、应用服务器每毫秒资源总量和租户资源权重，自动计算调度周期内每一个租户的资源配额。每个调度周期中，在计算完调度周期长度后，都需要计算每个租户的资源配额。

租户配额分配单元用于根据请求资源需求，将租户资源配额分配给每一个请求。对于每一个请求，其所分配的资源配额等于其所需的资源需求。如：请求1的CPU时长需求为100ms，则其所分配的CPU时长配额也为100ms。

请求交互和记录单元用于向应用服务器发送请求消息，请求消息中增加请求资源配额；从应用服务器接收响应消息，并记录响应消息中的请求资源用量。

请求资源控制模块位于应用服务器。请求资源控制模块包括：资源分配单元、请求执行单元、资源度量单元。

其中，资源分配单元用于根据请求消息中的请求资源配额为请求分配资源。

请求执行单元用于启动线程执行请求，并根据分配的资源，限制请求对资源的使用。

资源度量单元用于在请求执行过程中，度量资源实际使用量，并将其增加到响应消息中。

调度服务器分配给请求的资源量，实际上是根据评估的资源需求，为请求分配的资源配额，即预估资源量，而资源实际用量是请求执行过程中，实际使用的资源量。随着业务变化(如数据量增大或者减小)，实际资源量会随之变化，而预估资源量也会相应调整。

请参阅图6所示，为本申请实施例提供的客户端、调度服务器和应用服务器之间的另一种交互流程示意图，以下对每个步骤分别进行详细说明：

步骤1：租户识别。

调度服务器收到客户端的请求消息后，根据请求消息识别出租户。例如：从HTTP的请求消息的参数tenant＝hwxxx或消息头tenant:hwxxx或消息体<tenant>hwxxx<\tenant>中识别出租户为hwxxx。

步骤2：资源需求评估。

调度服务器识别出租户后，根据应用服务器度量的历史请求资源用量，评估请求消息执行过程中所需的资源(如：CPU时长、内存大小、I/O次数等)，并将请求连同其所属租户和资源需求一起插入请求列表中。

需要说明的是，同一类型的历史资源用量没有产生时，可以采取通过预先配置缺省资源量的方式确定历史请求资源用量。例如将真实环境中总结的历史经验数据或模拟环境中的测试数据(各种请求类型资源量)，预先配置到配置文件中，在没有产生历史资源用量时，直接从配置文件中获取请求类型资源量。请问应用服务器每毫秒的资源总量，就是每毫秒的处理能力。

资源需求评估方法：分析请求类型最近n次历史请求资源用量趋势，根据趋势计算请求类型的资源变化量，并在最近一次请求资源用量基础上增加资源变化量，作为当前请求的资源需求量。资源变化量是指资源的变化数量。

如图7所示，资源需求评估流程如下：

输入：请求和历史请求资源用量。

处理：

步骤2.1、根据当前请求查询请求类型最近n次历史请资源用量。

步骤2.2、判断历史请求资源用量趋势，如：单调上升或无变化或单调下降等。

步骤2.3、如果历史请求资源用量呈单调上升趋势，则当前请求的资源需求量R＝U1+(U1-Un)/(n-1)，其中：

U1：最近一次的请求资源用量。

Un：最近第n次的请求资源用量。

说明：资源变化量为(U1-Un)/(n-1)，由于呈单调上升趋势，所以值为正数。

步骤2.4、如果历史请求资源用量呈无变化趋势，则当前请求的资源需求量R＝U1，其中：

U1：最第1次的请求资源用量。

说明：资源变化量为0。

步骤2.5、如果历史请求资源用量呈单调下降趋势，则当前请求的资源需求量R＝U1+(U1-Un)/(n-1)，其中：

U1：最近第1次的请求资源用量。

Un：最近第n次的请求资源用量。

说明：资源变化量为(U1-Un)/(n-1)，由于呈单调下降趋势，所以值为负数。

输出：

当前请求资源需求。

例如：当前租户、当前请求类型最近3次请求资源用量如下表1所示：

通过表1的举例说明，可以评估当前请求资源需求为：

CPU时长＝12+(12-10)/(3-1)＝13ms。

内存大小＝102400+(102400-102420)/(3-1)＝102390Byte。

磁盘读写＝3次。

步骤3：调度周期计算。

每个调度周期执行请求调度前，基于本调度周期正好能处理完请求列表中所有请求的原则，根据请求列表中所有请求资源需求总量和应用服务器每毫秒的处理能力，自动计算调度周期长度。每个调度周期的长度根据请求列表中所有请求资源需求总量动态变化。

调度周期长度计算公式是为了满足在调度周期内正好处理完所有请求的，这是理想情况。实际上可能会出现以下两种特殊情况：特殊情况1、业务复杂度变小，导致调度周期内提前执行完所有请求。特殊情况2、业务复杂度变大，导致调度周期内没有执行完所有请求。

调度周期长度计算方法如下：

计算公式：调度周期长度＝请求列表中所有请求资源需求总量/应用服务器每毫秒的资源总量。

如需考虑多种资源类型，则每种资源类型都分别计算调度周期长度，选择最大值作为最终的调度周期长度。

某些资源类型，其资源总量与时长无关，则为其预先设定一个缺省的较小的调度周期长度值。如：内存大小与时长无关，可设定其调度周期长度为10ms。

若调度周期内所有请求都提前执行完，则提前启动下一调度周期，以提高调度效率和资源利用率。

若调度周期结束后存在未执行完的请求，由于已经发送到应用服务器执行，已经使用了部分资源，则在下一调度周期进行调度周期长度计算前，需对这些请求进行如下处理：

1)、重新评估资源需求，即核减掉请求已经使用的资源量，使这些请求不会过多占用本调度周期资源配额，可提高调度效率和资源利用率。说明：对于资源总量与时长无关的资源类型，无需重新评估资源需求。在“步骤6：向应用服务器发送请求”中已经发送过请求了，后续每个调度周期结束时，只是再监控该请求是否执行完毕；当未执行完毕时，该请求已使用的资源量不能再用来计算下一调度周期的长度。如：请求1的资源需求为100。第1个调度周期为请求1分配资源配额100，在第1个调度周期中向应用服务器发送请求1(携带资源配额为100)。在第1个调度周期结束时，请求1未执行完毕，而此时应用服务器度量出请求1已使用资源量为60，计算出请求1的剩余资源需求为100-60＝40。在第2个调度周期中，计算调度周期长度时，请求列表中所有请求资源需求总量中，包含请求1的资源需求为40。

2)、采用终止资源使用量超过阈值的请求的方式，防止出现资源被单个请求长时间占用，而其他请求分配不到资源的情况。

应用服务器每毫秒的资源总量指在每1毫秒内，应用服务器可提供的该资源数量。对于与运行时长无关的资源类型，其应用服务器每毫秒资源总量直接与应用服务器资源总量相等。如下表2所示：

资源类型	应用服务器规格	与运行时长有关	应用服务器每毫秒的资源总量
				CPU时长	8个CPU	是	8ms
内存大小	32G	否	32G
				磁盘读写	2000IOPS	是	2次
…	…	…	…

如图8所示，未执行完请求的处理流程如下：

流程说明：阈值的处理在调度服务器，阈值的设定方式不做限制。图6中所有涉及“资源”的处理步骤，都应该遍历所有资源类型。另外，步骤3.4应该是“仅针对资源总量与时长有关的资源类型”

输入：请求列表。

处理：

步骤3.1、从应用服务器获取正在执行的每个请求的已使用资源用量。

步骤3.2、遍历当前请求列表中每一个未执行完的请求：如果获取到一个请求，进入下一步；否则，进入步骤3.5。

步骤3.3、判断当前请求已使用资源用量是否超过阈值：如果超过，则返回步骤3.2；否则，进入下一步。

对于阈值判断，可以采用如下方法之一：

方法1：绝对资源量。如：当前请求已使用CPU时长超过10s。

方法2：相对于请求资源配额的比例值。如：当前请求已使用CPU时长超过其配额的10倍。

方法3：方法1和方法2同时满足。如：当前请求已使用CPU时长超过10s、并且当前请求已使用CPU时长超过其配额的10倍。

步骤3.4重新评估未执行完请求的资源需求，即更新当前请求资源需求为当前请求最初资源需求减去当前请求已使用资源用量。

需要说明的是，当前请求最初资源需求，指“步骤2：资源需求评估”时评估的值。仅针对资源总量与时长无关的资源类型更新资源需求。后续将以更新后的请求资源需求计算调度周期长度，以及为请求分配资源配额。

步骤3.5将所有已使用资源用量超过阈值的请求从请求列表中删除。

步骤3.6通知应用服务器终止所有已使用资源用量超过阈值的请求的执行。

输出：请求列表及未执行完请求重新评估的资源需求。

如图9所示，调度周期提前结束，举例说明如下：

预期下一调度周期开始时间为T3＝本调度周期开始时间T1+根据计算获得的调度周期长度。但在T3还未到达时的时间点T2，所有请求都执行完，则实际下一调度周期开始时间为T2。

下面以仅考虑CPU时长为例说明调度周期长度计算：

应用服务器有8个CPU，则：每毫秒CPU时长＝8ms。

当前请求列表中存在以下请求：

租户1有50个请求，租户1每个请求资源需求为：CPU时长40ms，

租户2有30个请求，租户2每个请求资源需求为：CPU时长30ms，

租户3有10个请求，租户3每个请求资源需求为：CPU时长20ms。

当前应用服务器正在执行的请求：

租户1有10个请求，每个请求已使用资源用量为：CPU时长20ms，

租户2有5个请求，每个请求已使用资源用量为：CPU时长10ms，

租户3有2个请求，每个请求已使用资源用量为：CPU时长10ms。

可计算出：

租户1正在执行的10个请求的剩余资源需求均为：CPU时长20ms，

租户2正在执行的5个请求的剩余资源需求均为：CPU时长20ms，

租户3正在执行的2个请求的剩余资源需求均为：CPU时长10ms。

最终：

调度周期长度Tc＝(40*40+10*20+25*30+5*20+8*20+2*10)/8＝354ms。

例如，租户1剩余的40个请求，每个请求所需资源为40，则40*40指的是租户1剩余的所有请求所需要的资源量，公式中其余相乘式与此类似，不再解释。

下面以同时考虑CPU时长和磁盘读写为例说明调度周期长度计算：

应用服务器有8个CPU、磁盘每秒进行读写(I/O)操作的次数(Input/OutputOperations Per Second，I/OPS)为2000，则：

每毫秒CPU时长容量为：8ms，

每毫秒磁盘读写容量为：2次。

当前请求列表中存在以下请求：

租户1有50个请求，租户1每个请求资源需求为：CPU时长40ms、磁盘读写20次，

租户2有30个请求，租户2每个请求资源需求为：CPU时长30ms、磁盘读写10次，

租户3有10个请求，租户3每个请求资源需求为：CPU时长20ms、磁盘读写30次，

当前应用服务器正在执行的请求：

租户1有10个请求，每个请求已使用资源用量为：CPU时长20ms、磁盘读写10次，

租户2有5个请求，每个请求已使用资源用量为：CPU时长10ms、磁盘读写5次，

租户3有2个请求，每个请求已使用资源用量为：CPU时长10ms、磁盘读写15次，

可计算出：

租户1正在执行的10个请求的剩余资源需求均为：CPU时长20ms，磁盘读写10次，

租户2正在执行的5个请求的剩余资源需求均为：CPU时长20ms，磁盘读写5次，

租户3正在执行的2个请求的剩余资源需求均为：CPU时长10ms，磁盘读写15次，

对于CPU时长，Tc1＝(40*40+10*20+25*30+5*20+8*20+2*10)/8＝354ms。

对于磁盘读写，Tc2＝(40*20+10*10+25*10+5*5+8*30+2*15)/2＝723ms。

最终：

调度周期长度Tc＝MAX(Tc1，Tc2)＝MAX(354，723)＝723ms。

步骤4：租户配额计算。

调度周期长度计算完成后，调度服务器自动计算调度周期内每个租户的资源配额。租户资源配额，指在调度周期内系统分配给该租户的供其请求使用的资源量。

租户资源配额计算方法：

对于与时长有关的资源类型，租户资源配额＝应用服务器每毫秒资源总量*调度周期长度*租户资源权重。

对于与时长无关的资源类型，租户资源配额＝应用服务器资源总量*租户资源权重。

下面以仅考虑CPU时长为例说明租户资源配额计算：

应用服务器有8个CPU，则：每毫秒CPU时长Rms＝8ms。

当前请求列表中存在以下请求：

租户1有50个请求，租户1每个请求资源需求为：CPU时长40ms，

租户2有30个请求，租户2每个请求资源需求为：CPU时长30ms，

租户3有10个请求，租户3每个请求资源需求为：CPU时长20ms，

SLA定义每个租户CPU时长权重为：

租户1的CPU时长权重为50％，

租户2的CPU时长权重为37.5％，

租户3的CPU时长权重为12.5％，

可计算出：

调度周期长度Tc＝(50*40+30*30+10*20)/8＝388ms，

调度周期内租户1的CPU时长配额Qt1＝50％*8*388＝1552ms，

调度周期内租户2的CPU时长配额Qt2＝37.5％*8*388＝1164ms，

调度周期内租户3的CPU时长配额Qt3＝12.5％*8*388＝388ms。

下面以同时考虑CPU时长、内存大小和磁盘读写为例说明租户资源配额计算：

应用服务器有8个CPU、32G内存、磁盘I/OPS为2000，则：

每毫秒CPU时长容量为：8ms，

每毫秒磁盘读写容量为：2次，

当前请求列表中存在以下请求：

租户1有50个请求，租户1每个请求资源需求为：CPU时长40ms、磁盘读写20次，租户2有30个请求，租户2每个请求资源需求为：CPU时长30ms、磁盘读写10次，租户3有10个请求，租户3每个请求资源需求为：CPU时长20ms、磁盘读写30次，SLA定义每个租户CPU时长权重为：

租户1的CPU时长权重为50％，

租户2的CPU时长权重为37.5％，

租户3的CPU时长权重为12.5％，

SLA定义每个租户内存大小权重为：

租户1的内存大小权重为33.333％，

租户2的内存大小权重为33.333％，

租户3的内存大小权重为33.333％，

SLA定义每个租户磁盘读写权重为：

租户1的磁盘读写权重为20％，

租户2的磁盘读写权重为40％，

租户3的磁盘读写权重为40％，

可计算出：

调度周期长度：

对于CPU时长，Tc1＝(50*40+30*30+10*20)/8＝388ms，

对于内存大小，Tc2＝10ms，

对于磁盘读写，Tc3＝(50*20+30*10+10*30)/2＝800ms，

最终，Tc＝MAX(Tc1，Tc2，Tc3)＝MAX(388，20，800)＝800ms，

对于租户1，调度周期内：

CPU时长配额Qt11＝50％*8*800＝3200ms，

内存大小配额Qt12＝33.3％*32＝10.667G，

磁盘读写配额Qt13＝20％*2*800＝320次，

对于租户2，调度周期内：

CPU时长配额Qt21＝37.5％*8*800＝2400ms，

内存大小配额Qt22＝33.3％*32＝10.667G，

磁盘读写配额Qt23＝40％*2*800＝640次，

对于租户3，调度周期内：

CPU时长配额Qt3＝12.5％*8*800＝800ms，

内存大小配额Qt32＝33.3％*32＝10.667G，

磁盘读写配额Qt33＝40％*2*800＝640次。

步骤5：租户配额分配

租户配额计算完成后，调度服务器按照请求先后顺序，将租户资源配额分配给请求列表中的每一个请求。

租户资源配额分配方法如下：

对于每一个租户，优先将资源配额分配给其上个调度周期未执行完的请求，再分配给其本调度周期新加入的请求。

对于每一个租户，其所有请求都分配到资源配额后，如果仍存在剩余资源配额，则将其分配给其他租户的请求。是指请求列表中包含的其他租户

对于每一个请求，其所分配的资源配额等于其所需的资源需求。如：请求1的CPU时长需求为100ms，则其所分配的CPU时长配额也为100ms。

请参阅图10所示，租户资源配额分配流程如下：

输入：租户资源配额和请求列表。

处理：

步骤5.1、遍历每一个租户：如果获取到一个租户，则进入下一步；否则，进入步骤5.4。

步骤5.2、如果当前租户存在上个调度周期未执行完的请求，则将当前租户的资源配额分配给这些未执行完的请求。

步骤5.3、如果当前租户存在本调度周期新加入的请求，则将当前租户的资源配额分配给这些新加入的请求。返回步骤5.1。

步骤5.4、判断是否某些租户存在剩余资源配额、且某些租户存在未分配到资源配额的请求：如果是，则进入下一步；否则，租户资源配额分配结束。

步骤5.5、将所有租户的剩余资源配额分配给所有未分配到资源配额的请求。租户资源配额分配结束。每个租户的资源配额，优先分配给该租户的请求；当租户资源配额小于该租户所有请求资源需求之和时，则该租户将存在“未分配到资源配额的请求”。如：举例中的租户1和租户2。

输出：请求列表及每个请求分配的资源配额。

下面以仅考虑CPU时长为例，说明租户资源配额分配。

当前请求列表中存在以下请求：

租户1有50个本周期新加入的请求，每个请求资源需求为：CPU时长40ms，

租户2有30个本周期新加入的请求，每个请求资源需求为：CPU时长30ms，

租户3有10个本周期新加入的请求，每个请求资源需求为：CPU时长20ms，

租户1有10个上周期未执行完的请求，每个请求资源需求为：CPU时长10ms，

租户2有5个上周期未执行完的请求，每个请求资源需求为：CPU时长10ms，

租户3有0个上周期未执行完的请求。

租户资源配额数量：

租户1的资源配额为：CPU时长2000ms。

租户2的资源配额为：CPU时长750ms。

租户2的资源配额为：CPU时长500ms。

资源分配过程：

为租户1上周期未执行完的请求分配资源配额：租户1所有上周期未执行完的请求均分配到资源配额；租户1剩余资源配额为：CPU时长＝2000-10*10＝1900ms。

为租户1本周期新加入的请求分配资源配额：租户1本周期新加入的47个请求分配到资源配额；租户1剩余资源配额为：CPU时长＝1900-47*40＝20ms。这里租户1的剩余资源配额1900ms，仅能够分配给其本周期新加入的47个请求，也就是说，至此，其本周期新加入的3个请求未分配资源配额。

为租户2上周期未执行完的请求分配资源配额：租户2所有上周期未执行完的请求均分配到资源配额；租户2剩余资源配额为：CPU时长＝750-5*10＝700ms。

为租户2本周期新加入的请求分配资源配额：租户2本周期新加入的23个请求分配到资源配额；租户2剩余资源配额为：CPU时长＝700-23*30＝10ms。

为租户3本周期新加入的请求分配资源配额：租户3所有本周期新加入的请求分配到资源配额；租户3剩余资源配额为：CPU时长＝500-10*20＝300ms。

所有租户剩余资源配额为：CPU时长＝20+10+300＝330ms。

所有租户未分配到资源配额的请求：租户1本周期新加入的3个请求共需资源需求：CPU时长＝3*40＝120ms；租户2本周期新加入的7个请求共需资源需求：CPU时长＝7*30＝210ms。

将所有租户剩余资源配额分配给所有租户未分配到资源配额的请求，资源配额分配完毕。

步骤6：向应用服务器发送请求。

租户配额分配完成后，调度服务器在调度周期内向应用服务器发送请求消息，请求消息中增加当前请求资源配额。如：http request header携带资源配额{cpu＝100，I/O＝10，memory＝5}。

步骤7：请求执行及资源分配和度量。

应用服务器收到请求消息，为请求分配资源，启动线程执行请求，并度量资源实际用量。

资源分配和度量方法如下：

从请求消息中获取当前请求资源配额，根据请求资源配额为请求分配资源。如：使用cgroups(control groups)，并设置cgroups资源策略为资源需求。Cgroups是Linux内核提供的一种可以限制、记录、隔离进程组(process groups)所使用的物理资源(如：cpu，memory，I/O等等)的机制。本申请实施例中可以对Cgroups进行监控，禁止Cgroups控制下的进程访问某些资源，还可以在一个运行中的系统中对Cgroups动态地进行配置。

在线程执行请求时，根据分配的资源限制请求对资源的使用。

在请求执行过程中，度量资源实际用量。如：使用cgroups可准确度量资源使用量。

步骤8：向调度服务器返回响应。

请求执行完成后，应用服务器向调度服务器返回响应消息，响应消息中增加当前请求资源用量。如：http response header携带资源用量{cpu＝100，I/O＝10，memory＝5}。

步骤9：记录请求资源用量。

调度服务器收到响应消息后，向客户端返回该响应消息，并且将响应消息中的请求资源用量等信息记录到历史请求数据中，为后续资源需求评估提供准确的基础数据。

本申请的前述实施例中，请求资源需求评估的过程可包括：

应用服务器度量请求资源用量，并将请求资源用量发送给调度服务器；

调度服务器根据历史请求资源用量及其趋势计算请求资源需求。

对于上周期未执行完的请求，调度服务器根据请求已使用资源量重新评估请求资源需求。

请求资源使用控制的过程主要包括：

调度服务器将请求资源配额发送给应用服务器；

应用服务器根据请求资源配额限制请求执行时对资源的占用；

调度服务器通知应用服务器终止资源使用量超过阈值的请求。

采用动态调度周期控制租户请求调度的过程主要包括：

调度服务器根据请求资源需求总量和应用服务器每毫秒的处理能力，计算调度周期长度。

调度服务器根据应用服务器每毫秒的资源总量、调度周期长度和租户资源权重，计算租户资源配额。

调度服务器根据租户资源配额和请求资源需求为请求分配资源配额，并对分配到资源配额的请求进行调度。

如果调度周期内所有请求都提前执行完，则立即启动下一调度周期。

计算调度周期长度的过程主要包括：

在考虑多种资源类型时，每种资源类型都分别计算调度周期长度，符合本调度周期正好能处理完请求列表中所有请求的原则，选择最大值作为最终的调度周期长度。

对于资源总量与时长无关的资源类型，为其预先设定一个缺省的较小的调度周期长度值。

通过前述实施例的举例说明可知，准确评估请求资源需求，精确控制租户性能。根据配额为请求分配资源，限制请求执行时对资源的占用，保证租户性能隔离。自动确定调度周期的长度，提高调度效率。

对于调度服务器，基于实际度量的请求类型资源用量评估请求资源需求，用于解决资源需求评估不准确的问题。为解决该问题，应用服务器也进行了改动，即应用服务器在请求执行过程中度量请求资源用量，并将请求资源用量反馈给调度服务器。本申请实施例中调度周期的计算，不会受到请求阻塞的影响。因为请求阻塞不会影响对请求资源用量的度量，进一步不会影响依赖于历史请求资源用量的请求资源需求评估，所以依赖于请求资源需求而计算的调度周期长度也不会受到影响。采用动态调度周期，用于解决周期长度难以确定问题。

对于应用服务器，根据请求资源配额为请求分配资源，限制请求执行时对资源的占用，并及时终止资源使用量超过阈值的请求，用于解决请求过度占用资源问题。调度服务器为每一个请求分配资源配额，并将请求资源配额发送给应用服务器。

基于历史请求执行过程中实际度量的资源用量，准确评估请求资源需求，精确控制租户性能。基于租户资源配额和请求资源需求为请求分配资源配额，根据请求资源配额限制请求执行时对资源的占用，并及时终止资源使用量超过阈值的请求，保证租户性能隔离。基于本调度周期正好能处理完请求列表中所有请求的原则，自动计算调度周期长度和租户资源配额，根据租户资源配额和请求资源需求为分配请求资源配额，以控制请求调度，提高调度效率。

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

为便于更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。

请参阅图11所示，本申请实施例提供的一种调度服务器1100，包括：

处理模块1101，用于根据客户端发送的请求消息识别出租户；

所述处理模块1101，还用于根据历史请求资源用量确定出所述请求消息对应的资源需求量；

所述处理模块1101，还用于根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期；

所述处理模块1101，还用于根据所述租户的租户资源配额和所述资源需求量为所述请求消息分配请求资源配额；

发送模块1102，用于在所述调度周期内向所述应用服务器发送执行命令，所述执行命令用于指示所述应用服务器根据所述请求资源配额执行所述请求消息。

在本申请的一些实施例中，所述调度服务器1100还包括：

接收模块1103，用于接收所述应用服务器发送的执行结果，所述执行结果包括：所述请求消息所占用的资源使用总量和是否执行成功的信息；

在本申请的一些实施例中，所述处理模块1101，还用于记录所述资源使用总量，并将所述资源使用总量更新到所述历史请求资源用量中。

在本申请的一些实施例中，所述处理模块1101，具体用于获取所述请求消息对应的请求类型；获取与所述请求类型的类型相同的最近N次的历史请求资源用量，所述N的取值为正整数；根据所述最近N次的历史请求资源用量确定历史请求资源用量趋势信息；根据所述历史请求资源用量趋势信息确定出所述资源需求量。

在本申请的一些实施例中，所述处理模块1101，具体用于将所述请求消息、所述租户和所述资源需求量插入到请求列表中；获取所述请求列表中所有请求消息对应的资源需求总量；根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度。

在本申请的一些实施例中，所述处理模块1101，具体用于当所述请求消息需要使用多种资源类型时，针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为所述请求消息当前所处的调度周期。

在本申请的一些实施例中，所述处理模块1101，还用于当所述请求列表中所有请求消息在所述调度周期到达之前已经调度完成时，将所述请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。

在本申请的一些实施例中，当资源总量与时长无关时，所述应用服务器处理请求的资源总量为所述应用服务器所拥有的资源量；或，当资源总量与时长有关时，所述应用服务器处理请求的资源总量为所述应用服务器在单位时长内能够提供的资源量。

在本申请的一些实施例中，所述处理模块1101，具体用于当资源总量与时长无关时，根据所述应用服务器所拥有的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额；或，当资源总量与时长有关时，根据所述调度周期的长度、所述应用服务器在单位时长内能够提供的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额。

在本申请的一些实施例中，所述处理模块1101，用于在所述调度周期内向所述应用服务器发送执行命令之后，从所述应用服务器获取正在执行的所述请求消息的资源已使用量；确定所述资源已使用量是否超过使用量阈值；当所述资源已使用量没有超过所述使用量阈值、且所述请求消息使用的资源总量与时长无关时，根据所述资源已使用量对所述资源需求量进行更新，得到更新后的资源需求量；使用所述更新后的资源需求量重新获取所述请求消息当前所处的调度周期。

在本申请的一些实施例中，所述处理模块1101，还用于当所述资源已使用量超过所述使用量阈值时，停止对所述请求消息的调度；

所述发送模块1103，还用于发送终止执行指令给所述应用服务器，以终止执行所述请求消息。

在本申请的一些实施例中，所述处理模块1101，具体用于确定在前一个调度周期内所述租户是否存在未执行完成的请求消息；当存在未执行完成的请求消息时，从所述租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。

在本申请的一些实施例中，所述处理模块1101，还用于当为所述未执行完成的请求消息以及所述未执行的请求消息都分配过请求资源配额之后，所述租户资源配额还存在剩余配额时，从所述剩余配额中为除所述租户之外的其它租户对应的请求消息分配请求资源配额。

请参阅图12所示，本申请实施例提供的一种应用服务器1200，包括：

接收模块1201，用于接收调度服务器在调度周期内发送的执行命令，所述执行命令包括：客户端发送的请求消息和所述调度服务器为所述请求消息分配的请求资源配额；

处理模块1202，用于根据所述请求资源配额从所述应用服务器处理请求的资源总量中为所述请求消息分配资源；

所述处理模块1202，还用于使用所述资源执行所述请求消息，并按照所述请求资源配额对所述请求消息在执行过程中所占用的资源进行限额控制。

在本申请的一些实施例中，所述应用处理器1200，还包括：发送模块1203，其中，

所述处理模块1202，还用于在执行所述请求消息的过程中度量所述请求消息所使用的资源，并生成资源使用总量，以及生成所述请求消息是否执行成功的信息；

所述发送模块1203，用于向所述调度服务器发送执行结果，所述执行结果包括：所述资源使用总量和所述是否执行成功的信息。

在本申请的一些实施例中，所述处理模块1202，还用于获取正在执行的所述请求消息的资源已使用量；

所述发送模块1203，还用于向所述调度服务器发送所述资源已使用量。

在本申请的一些实施例中，所述接收模块1201，还用于接收所述调度服务器通知的终止执行指令；

所述处理模块1202，还用于根据所述终止执行指令终止执行所述请求消息。

需要说明的是，上述装置各模块/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其带来的技术效果与本申请方法实施例相同，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储有程序，该程序执行包括上述方法实施例中记载的部分或全部步骤。

接下来介绍本申请实施例提供的另一种调度服务器，请参阅图13所示，调度服务器1300包括：

接收器1301、发射器1302、处理器1303和存储器1304(其中调度服务器1300中的处理器1303的数量可以一个或多个，图13中以一个处理器为例)。在本申请的一些实施例中，接收器1301、发射器1302、处理器1303和存储器1304可通过总线或其它方式连接，其中，图13中以通过总线连接为例。

存储器1304可以包括只读存储器和随机存取存储器，并向处理器1303提供指令和数据。存储器1304的一部分还可以包括非易失性随机存取存储器(英文全称：Non-VolatileRandom Access Memory，英文缩写：NVRAM)。存储器1304存储有操作系统和操作指令、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，操作指令可包括各种操作指令，用于实现各种操作。操作系统可包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

处理器1303控制调度服务器的操作，处理器1303还可以称为中央处理单元(英文全称：Central Processing Unit，英文简称：CPU)。具体的应用中，调度服务器的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都称为总线系统。

上述本申请实施例揭示的方法可以应用于处理器1303中，或者由处理器1303实现。处理器1303可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1303中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1303可以是通用处理器、数字信号处理器(英文全称：digital signal processing，英文缩写：DSP)、专用集成电路(英文全称：ApplicatI/On Specific Integrated Circuit，英文缩写：ASIC)、现场可编程门阵列(英文全称：Field-Programmable Gate Array，英文缩写：FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1304，处理器1303读取存储器1304中的信息，结合其硬件完成上述方法的步骤。

接收器1301可用于接收输入的数字或字符信息，以及产生与调度服务器的相关设置以及功能控制有关的信号输入，发射器1302可包括显示屏等显示设备，发射器1302可用于通过外接接口输出数字或字符信息。

本申请实施例中，处理器1303，用于执行前述图2、图3、图5至图10中调度服务器所执行的请求处理方法。

接下来介绍本申请实施例提供的另一种应用服务器，请参阅图14所示，应用服务器1400包括：

接收器1401、发射器1402、处理器1403和存储器1404(其中应用服务器1400中的处理器1403的数量可以一个或多个，图14中以一个处理器为例)。在本申请的一些实施例中，接收器1401、发射器1402、处理器1403和存储器1404可通过总线或其它方式连接，其中，图14中以通过总线连接为例。

存储器1404可以包括只读存储器和随机存取存储器，并向处理器1403提供指令和数据。存储器1404的一部分还可以包括NVRAM。存储器1404存储有操作系统和操作指令、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，操作指令可包括各种操作指令，用于实现各种操作。操作系统可包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

处理器1403控制应用服务器的操作，处理器1403还可以称为CPU。具体的应用中，应用服务器的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都称为总线系统。

上述本申请实施例揭示的方法可以应用于处理器1403中，或者由处理器1403实现。处理器1403可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1403中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1403可以是通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1404，处理器1403读取存储器1404中的信息，结合其硬件完成上述方法的步骤。

本申请实施例中，处理器1403，用于执行前述图2、图4、图5中应用服务器所执行的请求处理方法。

在另一种可能的设计中，当该装置为服务器内的芯片时，芯片包括：处理单元和通信单元，所述处理单元例如可以是处理器，所述通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使该服务器内的芯片执行上述方面任意一项的无线通信方法。可选地，所述存储单元为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述服务器内的位于所述芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。

其中，上述任一处提到的处理器，可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制上述方面无线通信方法的程序执行的集成电路。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

Claims

1.一种请求处理方法，其特征在于，包括：

调度服务器根据客户端发送的请求消息识别出租户；

所述调度服务器根据历史请求资源用量确定出所述请求消息对应的资源需求量；

所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期；

所述调度服务器根据所述租户的租户资源配额和所述资源需求量为所述请求消息分配请求资源配额；

所述调度服务器在所述调度周期内向所述应用服务器发送执行命令，所述执行命令用于指示所述应用服务器根据所述请求资源配额执行所述请求消息。

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

所述调度服务器接收所述应用服务器发送的执行结果，所述执行结果包括：所述请求消息所占用的资源使用总量和是否执行成功的信息；

所述调度服务器向所述客户端发送所述是否执行成功的信息。

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

所述调度服务器记录所述资源使用总量，并将所述资源使用总量更新到所述历史请求资源用量中。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述调度服务器根据历史请求资源用量确定出所述请求消息对应的资源需求量，包括：

所述调度服务器获取所述请求消息对应的请求类型；

所述调度服务器获取与所述请求类型的类型相同的最近N次的历史请求资源用量，所述N的取值为正整数；

所述调度服务器根据所述最近N次的历史请求资源用量确定历史请求资源用量趋势信息；

所述调度服务器根据所述历史请求资源用量趋势信息确定出所述资源需求量。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期，包括：

所述调度服务器将所述请求消息、所述租户和所述资源需求量插入到请求列表中；

所述调度服务器获取所述请求列表中所有请求消息对应的资源需求总量；

所述调度服务器根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度。

6.根据权利要求5所述的方法，其特征在于，所述调度服务器根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度，包括：

当所述请求消息需要使用多种资源类型时，所述调度服务器针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为所述请求消息当前所处的调度周期。

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

当所述请求列表中所有请求消息在所述调度周期到达之前已经调度完成时，所述调度服务器将所述请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。

8.根据权利要求1至7中任一项所述的方法，其特征在于，当所述资源总量与时长无关时，所述应用服务器处理请求的资源总量为所述应用服务器所拥有的资源量；或，

当所述资源总量与时长有关时，所述应用服务器处理请求的资源总量为所述应用服务器在单位时长内能够提供的资源量。

9.根据权利要求8所述的方法，其特征在于，所述调度服务器根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期之后，所述方法还包括：

当所述资源总量与时长无关时，所述调度服务器根据所述应用服务器所拥有的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额；或，

当所述资源总量与时长有关时，所述调度服务器根据所述调度周期的长度、所述应用服务器在单位时长内能够提供的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额。

10.根据权利要求1至9中任一项所述的方法，其特征在于，所述调度服务器在所述调度周期内向所述应用服务器发送执行命令之后，所述方法还包括：

所述调度服务器从所述应用服务器获取正在执行的所述请求消息的资源已使用量；

所述调度服务器确定所述资源已使用量是否超过使用量阈值；

当所述资源已使用量没有超过所述使用量阈值、且所述请求消息使用的资源总量与时长无关时，所述调度服务器根据所述资源已使用量对所述资源需求量进行更新，得到更新后的资源需求量；

所述调度服务器使用所述更新后的资源需求量重新获取所述请求消息当前所处的调度周期。

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

当所述资源已使用量超过所述使用量阈值时，所述调度服务器停止对所述请求消息的调度，并发送终止执行指令给所述应用服务器，以终止执行所述请求消息。

12.根据权利要求1至11中任一项所述的方法，其特征在于，所述调度服务器根据所述租户资源配额和所述资源需求量为所述请求消息分配请求资源配额，包括：

所述调度服务器确定在前一个调度周期内所述租户是否存在未执行完成的请求消息；

当存在未执行完成的请求消息时，所述调度服务器从所述租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。

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

当所述调度服务器为所述未执行完成的请求消息以及所述未执行的请求消息都分配过请求资源配额之后，所述租户资源配额还存在剩余配额时，所述调度服务器从所述剩余配额中为除所述租户之外的其它租户对应的请求消息分配请求资源配额。

14.一种请求处理方法，其特征在于，包括：

应用服务器接收调度服务器在调度周期内发送的执行命令，所述执行命令包括：客户端发送的请求消息和所述调度服务器为所述请求消息分配的请求资源配额；

所述应用服务器根据所述请求资源配额从所述应用服务器处理请求的资源总量中为所述请求消息分配资源；

所述应用服务器使用所述资源执行所述请求消息，并按照所述请求资源配额对所述请求消息在执行过程中所占用的资源进行限额控制。

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

所述应用服务器在执行所述请求消息的过程中度量所述请求消息所使用的资源，并生成资源使用总量，以及生成所述请求消息是否执行成功的信息；

所述应用服务器向所述调度服务器发送执行结果，所述执行结果包括：所述资源使用总量和所述是否执行成功的信息。

16.根据权利要求14或15所述的方法，其特征在于，所述方法还包括：

所述应用服务器获取正在执行的所述请求消息的资源已使用量；

所述应用服务器向所述调度服务器发送所述资源已使用量。

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

所述应用服务器接收所述调度服务器通知的终止执行指令，并根据所述终止执行指令终止执行所述请求消息。

18.一种调度服务器，其特征在于，包括：

处理模块，用于根据客户端发送的请求消息识别出租户；

19.根据权利要求18所述的调度服务器，其特征在于，所述调度服务器还包括：

20.根据权利要求19所述的调度服务器，其特征在于，所述处理模块，还用于记录所述资源使用总量，并将所述资源使用总量更新到所述历史请求资源用量中。

21.根据权利要求18至20中任一项所述的调度服务器，其特征在于，所述处理模块，具体用于获取所述请求消息对应的请求类型；获取与所述请求类型的类型相同的最近N次的历史请求资源用量，所述N的取值为正整数；根据所述最近N次的历史请求资源用量确定历史请求资源用量趋势信息；根据所述历史请求资源用量趋势信息确定出所述资源需求量。

22.根据权利要求18至21中任一项所述的调度服务器，其特征在于，所述处理模块，具体用于将所述请求消息、所述租户和所述资源需求量插入到请求列表中；获取所述请求列表中所有请求消息对应的资源需求总量；根据所述资源需求总量和所述应用服务器处理请求的资源总量获取所述调度周期的长度。

23.根据权利要求22所述的调度服务器，其特征在于，所述处理模块，具体用于当所述请求消息需要使用多种资源类型时，针对每种资源类型分别计算出一个调度周期，从计算出的多个调度周期中选择出最大值的调度周期作为所述请求消息当前所处的调度周期。

24.根据权利要求23所述的调度服务器，其特征在于，所述处理模块，还用于当所述请求列表中所有请求消息在所述调度周期到达之前已经调度完成时，将所述请求列表中最后一个请求消息的调度完成时刻作为下一个调度周期的开始时刻。

25.根据权利要求18至24中任一项所述的调度服务器，其特征在于，当所述资源总量与时长无关时，所述应用服务器处理请求的资源总量为所述应用服务器所拥有的资源量；或，当所述资源总量与时长有关时，所述应用服务器处理请求的资源总量为所述应用服务器在单位时长内能够提供的资源量。

26.根据权利要求25所述的调度服务器，其特征在于，所述处理模块，具体用于根据所述资源需求量和应用服务器处理请求的资源总量获取所述请求消息当前所处的调度周期之后，当所述资源总量与时长无关时，根据所述应用服务器所拥有的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额；或，当所述资源总量与时长有关时，根据所述调度周期的长度、所述应用服务器在单位时长内能够提供的资源量和所述租户的租户资源权重，获取所述租户的租户资源配额。

27.根据权利要求18至26中任一项所述的调度服务器，其特征在于，所述处理模块，还用于在所述调度周期内向所述应用服务器发送执行命令之后，从所述应用服务器获取正在执行的所述请求消息的资源已使用量；确定所述资源已使用量是否超过使用量阈值；当所述资源已使用量没有超过所述使用量阈值、且所述请求消息使用的资源总量与时长无关时，根据所述资源已使用量对所述资源需求量进行更新，得到更新后的资源需求量；使用所述更新后的资源需求量重新获取所述请求消息当前所处的调度周期。

28.根据权利要求27所述的调度服务器，其特征在于，所述处理模块，还用于当所述资源已使用量超过所述使用量阈值时，停止对所述请求消息的调度；

29.根据权利要求18至28中任一项所述的调度服务器，其特征在于，所述处理模块，具体用于确定在前一个调度周期内所述租户是否存在未执行完成的请求消息；当存在未执行完成的请求消息时，从所述租户资源配额中为未执行完成的请求消息分配请求资源配额，然后再为未执行的请求消息分配请求资源配额。

30.根据权利要求29所述的调度服务器，其特征在于，所述处理模块，还用于当为所述未执行完成的请求消息以及所述未执行的请求消息都分配过请求资源配额之后，所属租户资源配额还存在剩余配额时，从所述剩余配额中为除所述租户之外的其它租户对应的请求消息分配请求资源配额。

31.一种应用服务器，其特征在于，包括：

32.根据权利要求31所述的应用服务器，其特征在于，所述应用处理器，还包括：发送模块，其中，

33.根据权利要求31或32所述的应用服务器，其特征在于，所述应用服务器，还包括：发送模块，其中，

34.根据权利要求33所述的应用服务器，其特征在于，所述接收模块，还用于接收所述调度服务器通知的终止执行指令；

35.一种服务器，其特征在于，所述服务器为调度服务器或者应用服务器，所述服务器包括：处理器，存储器；所述处理器、所述存储器进行相互的通信；

所述存储器，用于存储指令；

所述处理器，用于执行所述存储器中的所述指令，执行如权利要求1至13中任一项，或者14至17中任一项所述的方法。

36.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至13中任一项，或者14至17中任一项所述的方法。

37.一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如权利要求1至13中任一项，或者14至17中任一项所述的方法。