一种资源调度的方法和系统与流程

本发明涉及计算机应用技术领域，特别涉及一种资源调度的方法和系统。

背景技术：

在应用系统运营过程中，常常会碰到这样的问题：偶然会碰到访问量过高的情况，为了保证应用系统能够正常运行，系统建设时期会以最高要求来组件服务器，但这种情况在访问量低时，会出现大量的资源空闲的情况。如果在系统建设时期对访问量预计不足，则在出现高并发请求时，会造成应用系统运行缓慢或挂机等情况。因此，针对上述问题目前已经提出了弹性调度机制，即在访问量高时自动创建计算资源以扩展系统处理能力，在访问量低的空闲时能够自动缩减计算资源以节约成本。

目前采用的弹性调度机制主要是依据对系统资源的使用情况来判断应用的负载情况，例如依据对CPU、内存、网络流量、磁盘IO等资源的使用情况来确定应用的负载情况，如果某应用对CPU、内存等占用较多，则确定需要针对该应用进行扩容。然而，这种方式在有些情况下并不能真实反映应用状态，例如有些应用对系统资源的占用并不多，但针对该应用的处理却十分缓慢甚至停滞，如果使用目前的弹性调度机制则无法满足该应用的扩容需求。

技术实现要素：

有鉴于此，本发明提供了一种资源调度的方法和系统，以便于更加准确地满足实际的调度需求。

具体技术方案如下：

本发明提供了一种资源调度的方法，该方法包括：

监控待服务器处理的应用请求的阻塞状况；

依据预设的调度规则和所述应用请求的阻塞状况，对所述应用进行服务器的计算资源调度。

根据本发明一优选实施方式，所述监控待服务器处理的应用请求的阻塞状况包括：

收集服务器的阻塞请求队列的请求数，所述阻塞请求队列包含待服务器处理的应用请求；

对收集的所述请求数进行分析和统计，得到所述应用请求的阻塞状况。

根据本发明一优选实施方式，所述应用请求的阻塞状况包括：

针对具体应用的请求阻塞状况、针对具体实例的请求阻塞状况以及针对具体主机的请求阻塞状况中的至少一种。

根据本发明一优选实施方式，所述收集服务器的阻塞请求队列的请求数包括：

从代理服务器暴露的API收集服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，该方法还包括：

所述代理服务器中设置有事件监听统计模块；

所述事件监听统计模块监听所述代理服务器上报请求给所述服务器的事件，获取已上报请求数量；以及监听所述代理服务器确定所述服务器完成对请求的处理事件，获取已处理请求数量；

依据所述已上报请求数量和所述已处理请求数量，确定所述服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，所述从代理服务器暴露的API收集服务器的阻塞请求队列的请求数包括：

访问所述API提供的URL；

从所述URL对应的页面数据获取所述服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，依据预设的调度规则和所述应用请求的阻塞状况，对所述应用进行服务器的计算资源调度包括以下至少一种：

如果针对具体应用的请求阻塞状况满足第一扩容条件，则针对所述具体应用产生并部署新的实例；

如果针对具体应用的请求阻塞状况满足第一缩容条件，则减少所述具体应用的实例；

如果针对具体实例的请求阻塞状况满足第二扩容条件，则针对所述具体实例增加系统资源或者利用其它实例对所述具体实例进行负载分担；

如果针对具体实例的请求阻塞状况满足第二缩容条件，则针对所述具体实例减少系统资源；

如果针对具体主机的请求阻塞状况满足第三扩容条件，则利用其它主机对所述具体主机进行负载分担；

如果针对具体主机的请求阻塞状况满足第三缩容条件，则优先在所述具体主机上部署实例，或者优先利用所述具体主机对其他主机进行负载分担。

根据本发明一优选实施方式，该方法还包括以下至少一种：

监控具体应用中实例的资源使用状况，如果具体应用中实例的平均资源使用状况大于或等于预设的第一上限值，则增加所述具体应用的实例；如果具体应用中实例的平均资源使用状况小于或等于预设的第一下限值，则减少所述具体应用的实例；

监控具体应用中实例的资源使用状况，如果某实例的资源使用状况大于或等于预设的第二上限值，则增加所述某实例所占用的系统资源；如果某实例的资源使用状况小于或等于预设的第二下限值，则减少所述某实例所占用的系统资源；

如果检测到某主机不可用，则针对所述某主机上的实例发起迁移；

如果检测到某进程不可用，则针对所述某进程执行重启，如果重启失败，则针对所述某进程上的实例发起迁移；

如果检测到某应用异常，则对所述某应用执行重启，或者针对所述某应用的实例发起迁移，或者进行报警。

本发明还提供了一种资源调度的系统，该系统包括：

阻塞监控单元，用于监控待服务器处理的应用请求的阻塞状况；

调度单元，用于依据预设的调度规则和所述应用请求的阻塞状况，对所述应用进行服务器的计算资源调度。

根据本发明一优选实施方式，所述阻塞监控单元具体包括：

监控子单元，用于收集服务器的阻塞请求队列的请求数，所述阻塞请求队列包含待服务器处理的应用请求；

计算子单元，用于对所述监控子单元收集的所述请求数进行分析和统计，得到所述应用请求的阻塞状况。

根据本发明一优选实施方式，所述应用请求的阻塞状况包括：

针对具体应用的请求阻塞状况、针对具体实例的请求阻塞状况以及针对具体主机的请求阻塞状况中的至少一种。

根据本发明一优选实施方式，所述监控子单元从代理服务器暴露的API收集服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，该系统还包括：

设置于所述代理服务器的事件监听统计模块，用于监听所述代理服务器上报请求给所述服务器的事件，获取已上报请求数量；以及监听所述代理服务器确定所述服务器完成对请求的处理事件，获取已处理请求数量；依据所述已上报请求数量和所述已处理请求数量，确定所述服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，所述监控子单元，具体用于访问所述API提供的URL，从所述URL对应的页面数据获取所述服务器的阻塞请求队列的请求数。

根据本发明一优选实施方式，所述调度单元，具体执行以下调度中的至少一种：

如果针对具体应用的请求阻塞状况满足第一扩容条件，则针对所述具体应用产生并部署新的实例；

如果针对具体应用的请求阻塞状况满足第一缩容条件，则减少所述具体应用的实例；

如果针对具体实例的请求阻塞状况满足第二扩容条件，则针对所述具体实例增加系统资源或者利用其它实例对所述具体实例进行负载分担；

如果针对具体实例的请求阻塞状况满足第二缩容条件，则针对所述具体实例减少系统资源；

如果针对具体主机的请求阻塞状况满足第三扩容条件，则利用其它主机对所述具体主机进行负载分担；

如果针对具体主机的请求阻塞状况满足第三缩容条件，则优先在所述具体主机上部署实例，或者优先利用所述具体主机对其他主机进行负载分担。

根据本发明一优选实施方式，所述阻塞监控单元，还用于监控具体应用中实例的资源使用状况；

所述调度单元，还用于如果具体应用中实例的平均资源使用状况大于或等于预设的第一上限值，则增加所述具体应用的实例；如果具体应用中实例的平均资源使用状况小于或等于预设的第一下限值，则减少所述具体应用的实例；或者，如果某实例的资源使用状况大于或等于预设的第二上限值，则增加所述某实例所占用的系统资源；如果某实例的资源使用状况小于或等于预设的第二下限值，则减少所述某实例所占用的系统资源。

根据本发明一优选实施方式，该系统还包括：

状态检测单元，用于检测主机、进程或应用的运行状态；

所述调度单元，还用于如果所述状态检测单元检测到某主机不可用，则针对所述某主机上的实例发起迁移；如果所述状态检测单元检测到某进程不可用，则针对所述某进程执行重启，如果重启失败，则针对所述某进程上的实例发起迁移；如果所述状态检测单元检测到某应用异常，则对所述某应用执行重启，或者针对所述某应用的实例发起迁移，或者进行报警。

根据本发明一优选实施方式，所述调度单元包括：

调度子单元，用于依据依据预设的调度规则和所述应用请求的阻塞状况，生成调度指令，并将调度指令发送给管理子单元；

管理子单元，用于依据所述调度指令，对所述应用执行服务器的计算资源 调度。

由以上技术方案可以看出，本发明转换了一种思路，对待服务器处理的应用请求的阻塞状况进行收集并基于此对应用进行服务器的计算资源调度，而并非基于应用对系统资源的使用情况。由于待服务器处理的应用请求的阻塞状况能够更真实地反映应用的负载状况，因此本发明的调度方式能够更加准确地满足实际的调度需求。

【附图说明】

图1为本发明实施例所基于的架构图；

图2为本发明实施例提供的一个方法流程图；

图3为本发明实施例提供的资源调度系统的结构图。

【具体实施方式】

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

为了方便对本发明的理解，首先对本发明所基于的架构进行介绍。如图1中所示，在该架构中服务器是对应用请求进行具体处理的网络设备，即应用请求的访问对象是服务器，服务器负责对各应用请求进行处理从而实现该应用的服务内容。另外对应用请求进行处理的服务器可以是一台服务器，也可以是一个服务器集群。

在服务器中可以存在至少一台主机，每个主机上运行有一个或者多个应用的实例。也就是说，一个应用可以由一个以上的应用实例构成，每个应用实例部署在主机上，可以部署在同一台主机上，也可以部署在不同的主机上，甚至可以部署在服务器集群中的不同服务器上。

在如图1所示的架构中，代理服务器(proxy server)负责将来自用户侧设备的应用请求转发至服务器进行处理，并将来自服务器的响应转发给用户侧设备。

调度系统则是本发明的核心，负责监控服务器处理的应用请求的阻塞状况，依据预设的调度规则和应用请求的阻塞状况，对应用进行服务器的计算资源调度。更具体地，调度系统在监控服务器处理的应用请求的阻塞状况时，并非直接从服务器获取，而是采用从代理服务器进行数据收集并分析后，间接得到服务器处理的应用请求的阻塞状况。下面对调度系统的处理过程和组成结构进行详细描述。

图2为本发明实施例提供的一个方法流程图，该方法由上述调度系统执行，如图2中所示，该方法可以包括以下步骤：

在201中，从代理服务器暴露的API收集服务器的阻塞请求队列的请求数。

由于代理服务器负责将发送给服务器的应用请求转发给服务器，并接收服务器处理应用请求后返回的响应，因此依据代理服务器转发给服务器的应用请求数以及收到的响应对应的请求数，就可以获知已发送给服务器待服务器处理的请求数，基于该原理，就可以从代理服务器进行服务器的阻塞请求队列的请求数收集。

更具体地，由于代理服务器采用的是异步事件处理机制，当执行一项处理时存在相应的事件。因此，可以预先在代理服务器设置事件监听统计模块，负责进行代理服务器的事件监听和请求统计，即事件监听统计模块监听代理服务器上报请求给服务器的事件，获取已上报请求数量，在此可以采用一个全局变量进行已上报请求数量的统计，每上报一个请求，该全局变量(假设为u)加1。另外，事件监听统计模块监听代理服务器确定服务器完成对请求的处理事件(例如接收到服务器针对请求返回的处理完成响应)，获取已处理请求数量，每获取已处理请求数量，上述的全局变量u减1。最终该全局变量的值就可以认为是服务器的阻塞请求队列的请求数，即已发送给服务器并待服务器处理的请求数。

除此之外，事件监听统计模块还可以监听代理服务器建立网络连接的事件，获取已建立网络连接但尚未转发给服务器的请求数，该请求数体现了服 务器未来会面临的处理压力，该请求数可以作为辅助因素，后续调度单元可以将该辅助因素作为进行计算资源调度的参考。

上述获取的请求数，事件监听统计模块可以通过代理服务器暴露的API输出，在输出时可以采用http协议。例如该API可以提供特定的URL，当调度系统访问该URL时，API会返回一个页面，该页面可以通过格式化数据的方式提供上述的请求数，即调度系统从该URL对应的页面数据获取服务器的阻塞请求队列的请求数。

在202中，对收集的请求数进行分析和统计，得到应用请求的阻塞状况。

在本步骤中，可以对收集的请求数分别进行分析和统计，确定各具体应用对应的阻塞请求队列的请求数、各具体实例对应的阻塞请求队列的请求数、具体主机对应的阻塞请求队列的请求数。对于一个请求而言，依据其访问的域名可以确定其对应的具体应用，依据其访问的IP地址可以确定其对应的具体主机，依据其访问的端口可以确定其对应的具体实例。

阻塞请求队列的请求数结合对应计算资源的处理能力能够反映请求的阻塞状况，具体将在后续描述中体现。

在203中，依据预设的调度规则和应用请求的阻塞状况，对应用进行服务器的计算资源调度。

对于具体应用而言，如果某应用的请求阻塞状况满足第一扩容条件，例如，阻塞请求队列的请求数超过该应用所占用计算资源的3倍处理能力(其中3倍是一个例子，具体可以取经验值或者根据历史数据得到的值，下面所举的各例也类似)，则说明该应用的请求阻塞严重，需要针对该应用产生并部署新的实例，新的实例在部署时可以基于负载均衡策略，优先部署在负载较低(例如阻塞请求队列的请求数较少)的主机上。如果某应用的请求阻塞状况满足第一缩容条件，例如阻塞请求队列的请求数低于该应用所占用计算资源的0.5倍处理能力，则说明该应用的请求数量很少，其所占用的计算资源空闲，因此可以减少分配给该应用的实例，其中待结束的实例不再分配请求，待该实例无任务时，结束该实例。

对于具体实例而言，如果某实例的请求阻塞状况满足第二扩容条件，例如某实例的阻塞请求队列的请求数超过该实例所占用计算资源的3倍处理能力，则说明该实例的请求阻塞严重，可以针对该实例增加系统资源，本发明所涉及的系统资源可以包括但不限于CPU、内存、IO资源、网络流量等，或者增加实例对该实例进行负载分担，还可以结合该实例对系统资源的占用状况来确定增加那种系统资源。如果某实例的请求阻塞状况满足第二缩容条件，例如某实例的阻塞请求队列的请求数低于该实例所占用计算资源的3倍处理能力，则说明该实例的计算资源空闲，可以针对该实例减少系统资源。

对于具体主机而言，如果针对具体主机的请求阻塞状况满足第三扩容条件，例如该主机的阻塞请求队列的请求数超过该主机的3倍处理能力，则利用其它主机对该主机进行负载分担。如果针对具体主机的请求阻塞状况满足第三缩容条件，例如该主机的阻塞请求队列的请求数低于该主机的0.5倍处理能力，则优先在该主机上部署新的实例，或者优先利用该主机对其他主机进行负载分担。

上述对计算资源的调度可以是周期性地，可以满足不同阶段的应用弹性调度需求。

在基础上，还可以融合现有弹性调度机制，例如可以包括但不限于以下情况：

监控具体应用中实例的资源使用状况，这里的资源使用状况包括CPU、内存、IO资源等系统资源，如果所有实例的平均资源使用状况大于或等于预设的第一上限值，例如大于或等于80％的理论平均值，则可以增加具体应用的实例。如果所有实例的平均资源使用状况小于或等于预设的第一下限值，例如小于或等于20％的理论平均值，则可以减少具体应用的实例。其中第一上限值大于第一下限值。

如果某实例的资源使用状况大于或等于预设的第二上限值，例如CPU占用高于30％，则可以增加该实例所占用的系统资源，例如CPU、内存或IO资源等。如果某实例的资源使用状况小于或等于预设的第二下限值，例如 CPU占用低于10％，则可以减少该实例所占用的系统资源。其中第二上限值大于第二下限值。

如果检测到某主机不可用，则可以针对该主机上的所有实例发起迁移，例如迁移到其他一个或多个主机上，在迁移到其他一个或多个主机上时可以基于负载均衡策略，优先迁移到负载较小的主机上。

如果检测到某进程不可用，则针对该进程执行重启，如果重启失败，则针对该进程上的实例发起迁移，可以迁移到其他进程上，其中可以迁移到同一个主机的其他进程，但优选迁移到其他主机的进程。

如果检测到应用不可用，可能是由应用故障或者攻击引起，则可以将该应用的实例所在的进程进行重启，或者将整个应用的实例进行迁移，或者报警。

在上述实现中，可以对各应用实例的资源使用进行限制，例如可以设置各应用实例对内存的使用上限是4G。也可以针对各应用的资源使用进行限制，例如设置该应用所有实例对CPU的总使用上限是80％。其目的是为了防止因为某些应用代码异常而导致的系统资源的无限制使用。另外，调度系统可以开放接口供用户对上述调度规则和资源使用上限进行配置和调整。

图3为本发明实施例提供的资源调度系统的结构图，如图3中所示，该系统可以包括阻塞监控单元00和调度单元10，还可以包括设置于代理服务器的事件监听统计模块20和状态检测单元30。其中，阻塞监控单元00可以具体包括监控子单元01和计算子单元02，调度单元10可以具体包括调度子单元11和管理子单元12。

阻塞监控单元00负责监控待服务器处理的应用请求的阻塞状况。

具体地，监控子单元01负责收集服务器的阻塞请求队列的请求数，阻塞请求队列包含待服务器处理的应用请求。监控子单元01可以从代理服务器暴露的API收集服务器的阻塞请求队列的请求数。

由于代理服务器采用的是异步事件处理机制，当执行一项处理时存在相应的事件。因此，可以预先在代理服务器设置事件监听统计模块20，其负责 监听代理服务器上报请求给服务器的事件，获取已上报请求数量；以及监听代理服务器确定服务器完成对请求的处理事件，获取已处理请求数量；依据已上报请求数量和已处理请求数量，确定服务器的阻塞请求队列的请求数。

在此可以采用一个全局变量进行已上报请求数量的统计，每上报一个请求，该全局变量加1，每获取一个已处理请求的响应，上述的全局变量减1。最终该全局变量的值就可以认为是服务器的阻塞请求队列的请求数，即已发送给服务器并待服务器处理的请求数。

除此之外，事件监听统计模块20还可以监听代理服务器建立网络连接的事件，获取已建立网络连接但尚未转发给服务器的请求数，该请求数体现了服务器未来会面临的处理压力，该请求数可以作为辅助因素，后续调度单元可以将该辅助因素作为进行计算资源调度的参考。

上述获取的请求数，事件监听统计模块20可以通过代理服务器暴露的API输出，在输出时可以采用http协议。例如该API可以提供特定的URL，当调度系统访问该URL时，API会返回一个页面，该页面可以通过格式化数据的方式提供上述的请求数，即监控子单元01访问API提供的URL，从URL对应的页面数据获取服务器的阻塞请求队列的请求数。

计算子单元02负责对监控子单元01收集的请求数进行分析和统计，得到应用请求的阻塞状况。其中，应用请求的阻塞状况可以包括：针对具体应用的请求阻塞状况、针对具体实例的请求阻塞状况以及针对具体主机的请求阻塞状况中的至少一种。对于一个请求而言，依据其访问的域名可以确定其对应的具体应用，依据其访问的IP地址可以确定其对应的具体主机，依据其访问的端口可以确定其对应的具体实例。

由于监控子单元01对请求数的收集是周期性执行的，因此监控子单元01可以将收集的数据送入监控数据库，计算子单元02对监控数据库中的数据执行上述分析和统计。

调度单元10负责依据预设的调度规则和应用请求的阻塞状况，对应用进行服务器的计算资源调度。

具体地，调度单元10可以具体执行以下调度中的至少一种：

如果针对具体应用的请求阻塞状况满足第一扩容条件，则针对具体应用产生并部署新的实例，新的实例在部署时可以基于负载均衡策略，优先部署在负载较低(例如阻塞请求队列的请求数较少)的主机上。如果针对具体应用的请求阻塞状况满足第一缩容条件，则减少具体应用的实例，其中待结束的实例不再分配请求，待该实例无任务时，结束该实例。

如果针对具体实例的请求阻塞状况满足第二扩容条件，则针对具体实例增加系统资源或者利用其它实例对具体实例进行负载分担。如果针对具体实例的请求阻塞状况满足第二缩容条件，则针对具体实例减少系统资源。

如果针对具体主机的请求阻塞状况满足第三扩容条件，则利用其它主机对具体主机进行负载分担。如果针对具体主机的请求阻塞状况满足第三缩容条件，则优先在具体主机上部署实例，或者优先利用具体主机对其他主机进行负载分担。

在上述基础上，该系统还可以融合现有弹性调度机制，此时，阻塞监控单元00还负责监控具体应用中实例的资源使用状况。如果具体应用中实例的平均资源使用状况大于或等于预设的第一上限值，则调度单元10可以增加具体应用的实例。如果具体应用中实例的平均资源使用状况小于或等于预设的第一下限值，则调度单元10可以减少具体应用的实例。其中第一上限值大于第一下限值。

如果某实例的资源使用状况大于或等于预设的第二上限值，则调度单元10可以增加某实例所占用的系统资源，例如CPU、内存或IO资源等。如果某实例的资源使用状况小于或等于预设的第二下限值，则调度单元10可以减少某实例所占用的系统资源。其中第二上限值大于第二下限值。

状态检测单元30负责检测主机、进程或应用的运行状态。如果状态检测单元30检测到某主机不可用，则调度单元10可以针对某主机上的实例发起迁移，例如迁移到其他一个或多个主机上，在迁移到其他一个或多个主机上时可以基于负载均衡策略，优先迁移到负载较小的主机上。

如果状态检测单元30检测到某进程不可用，则调度单元10可以针对某进程执行重启，如果重启失败，则针对某进程上的实例发起迁移，可以迁移到其他进程上，其中可以迁移到同一个主机的其他进程，但优选迁移到其他主机的进程。

如果状态检测单元30检测到某应用异常，则调度单元10可以对某应用执行重启，或者针对某应用的实例发起迁移，或者进行报警。

调度单元10包括的调度子单元11负责依据依据预设的调度规则和应用请求的阻塞状况，生成调度指令，并将调度指令发送给管理子单元12。其中调度子单元11可以从规则数据库中加载调度规则，其中调度规则数据库可以对外提供一个接口，用户可以通过该接口对调度规则进行配置或修改。

管理子单元12是具体执行调度操作的单元，平时负责对资源进行管理，在本发明实施例中负责依据调度指令，对应用执行服务器的计算资源调度。还可以进一步将调度结果返回给调度子单元11。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指 令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。