CN114385353A - 资源调度方法及装置、电子设备、存储介质 - Google Patents

Abstract

本申请的实施例揭示了一种资源调度方法及装置、电子设备、存储介质、程序产品，该方法包括：对应用服务自身的资源占用情况进行监测，若监测到应用服务自身的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标共享服务；获取目标共享服务中已占用的资源对应的第一已占用资源量，若第一已占用资源量小于第一阈值，则对应用服务进行扩容。本申请实施例的技术方案能够降低对应用服务进行扩容后，其他服务崩溃的概率，进而提升资源调度的合理性以及系统的稳定性。

Description

资源调度方法及装置、电子设备、存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种资源调度方法及装置、电子设备、存储介质、程序产品。

背景技术

在以云技术为基础实现的应用系统中，通常将一个应用系统划分为多个应用服务，每个应用服务由多个功能相同的服务实例对外提供服务，并支持对应用服务进行扩容或缩容。例如，在以容器技术为基础的微服务场景中，每个应用服务由多个功能相同的容器(或pod，即容器组)对外提供服务，且支持对应用服务包含的资源进行扩容或缩容。相关技术中，在对应用服务进行扩容时，通常是基于服务实例所在主机的剩余资源情况确定是否扩容，例如，若服务实例所在主机的剩余资源较多，则对应用服务进行扩容。但是，这种扩缩容方式容易导致系统崩溃。

发明内容

为解决上述技术问题，本申请的实施例提供了一种资源调度方法及装置、电子设备、存储介质、程序产品。

根据本申请实施例的一个方面，提供了一种资源调度方法，所述方法包括：

对应用服务自身的资源占用情况进行监测；

若监测到所述应用服务自身的资源占用情况满足预设扩容条件，则确定所述应用服务在执行过程中需要调用的目标服务；

获取所述目标服务中已占用的资源对应的第一已占用资源量；

若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容。

根据本申请实施例的一个方面，提供了一种资源调度装置，所述装置包括：

监测模块，配置为对应用服务自身的资源占用情况进行监测；

确定模块，配置为若监测到所述应用服务自身的资源占用情况满足预设扩容条件，则确定所述应用服务在执行过程中需要调用的目标服务；

获取模块，配置为获取所述目标服务中已占用的资源对应的第一已占用资源量；

扩容模块，配置为若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如前所述的资源调度方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被电子设备的处理器执行时，使电子设备执行如前所述的资源调度方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，包括计算机程序，所述计算机指令被处理器执行时实现如前所述的资源调度方法。

在本申请的实施例所提供的技术方案中，先对应用服务自身的资源占用情况进行监测，若监测到应用服务自身的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标共享服务；获取目标共享服务中已占用的资源对应的第一已占用资源量，若第一已占用资源量小于第一阈值，则对应用服务进行扩容，也就是说，在需要对应用服务进行扩容时，会参考该应用服务的关联服务的资源占用情况，从而根据关联服务的资源占用情况确定是否进行扩容，避免对应用服务扩容后，该应用服务占用关联服务中大量资源，导致关联服务中可用资源不足，关联服务崩溃，进而整个应用系统崩溃的情况，提升资源调度的合理性以及系统的稳定性。

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

附图说明

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

图1是本申请的一示例性实施例示出的资源调度方法的流程图；

图2是图1所示实施例中的步骤S140在一示例性实施例中的流程图；

图3是图1所示实施例中的步骤S140在另一示例性实施例中的流程图；

图4是本申请的一示例性实施例示出的资源调度方法的流程图；

图5是本申请的一示例性实施例示出的资源调度方法的实施环境；

图6是本申请的一示例性实施例示出的资源调度装置的结构示意图；

图7示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

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

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

还需要说明的是：在本申请中提及的“多个”是指两个或者两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在以云技术为基础实现的应用系统中，通常将一个应用系统划分为多个应用服务，每个应用服务由多个功能相同的服务实例对外提供服务，并支持对应用服务进行扩容或缩容。但是目前，在对应用服务进行扩容时，通常仅考虑到服务实例所在主机的剩余资源情况是否能够支撑扩容，例如，若服务实例所在主机的剩余资源较多，则对应用服务进行扩容，但是，这种扩容方式中未考虑到扩容后的应用服务对其他服务的影响，容易导致其他服务崩溃，进而使得系统崩溃。基于此，本申请的实施例提供了一种资源调度方法及装置、电子设备、存储介质，可以降低对应用服务进行扩容后，其他服务崩溃的概率，进而提升资源调度的合理性以及系统的稳定性。

请参见图1，图1是本申请的一示例性实施例示出的一种资源调度方法的流程图。如图1所示，在一示例性实施例中，该资源调度方法可以包括步骤S110至步骤S140，详细介绍如下：

步骤S110，对应用服务自身的资源占用情况进行监测。

需要说明的是，应用服务为以云技术基础实现的应用系统中所包含的服务。其中，在以云技术基础实现的应用系统中，通常将一个应用系统划分为多个应用服务，每个应用服务由多个功能相同的服务实例对外提供服务，并支持对应用服务进行扩缩容。例如，在以容器技术为基础的微服务场景中，每个应用服务由多个功能相同的容器对外提供服务，在kubernetes中，每个应用服务由多个功能相同的pod对外提供服务。其中，kubernetes是Google开源的一个容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理；pod由一个或一个以上的容器组成，可以视为容器组。

应用服务自身的资源是分配给该应用服务的资源，即，应用服务包含的资源，例如前述的容器、pod对应的资源，应用服务自身的资源类型包括但不限于计算资源(例如CPU资源等，其中，CPU为central processing unit，即中央处理器)、存储资源(例如，内存等)等。并且，支持对应用服务自身的资源进行扩容或缩容。

为了确定是否需要对应用服务进行扩容或缩容，本实施例中，对应用服务自身的资源占用情况进行监测。

步骤S120，若监测到应用服务自身的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标服务。

预设扩容条件为预设设置的、用于确定是否需要对应用服务进行扩容的条件。预设扩容条件可以根据实际需要灵活设置，可以设置为资源占用率达到预设资源占用率上限。其中，资源占用率为已占用资源与总资源(即已占用资源与剩余资源的和)的比值，对于应用服务而言，资源占用率为应用服务中已占用的资源与调度给该应用服务的总资源的比值；资源占用率上限为用于确定是否需要对应用服务进行扩容，其可以设置为应用服务正常运行和异常运行的界限，若超过该上限，则表明应用服务可用资源较少，应用服务容易崩溃，若低于该上限，则表明应用服务可以资源较多，应用服务正常运行，不容易崩溃。资源占用率上限的具体数值可以根据实际需要灵活设置，例如，可以设置为90％、80％等。在一个示例中，预设扩容条件可以包括应用服务的CPU资源占用率超过90％，或，应用服务的内存占用率超过80％。

目标服务包括应用服务执行过程中需要调用的服务。应当理解的是，应用服务在实现对应功能的过程中，需要调用其他服务，例如，假设应用服务为注册服务，由于注册服务需要调用数据库以将注册信息存储至数据库，因此，本实施例中，将应用服务在执行过程中需要调用的服务作为目标服务。其中，可以将应用服务在执行过程中需要调用的所有服务均作为目标服务；或者，考虑到共享服务为多个应用服务可以调用的服务，若共享服务崩溃，会导致多个应用服务崩溃，因此，为了避免共享服务崩溃，本实施例中，可以将应用服务在执行过程中需要调用的共享服务作为目标服务，其中，共享服务包括但不限于中间件服务，例如，数据库、消息中间件、缓存等中间件服务。

本实施例中，考虑到对应用服务进行扩容后，该应用服务在关联服务中占用的资源可能会增加，为了避免应用服务的扩容导致关联服务崩溃，或扩容部分无法调用关联服务的情况，本实施例中，在监测到应用服务自身的资源占用情况满足预设扩容条件后，即确定需要对应用服务进行扩容后，先确定该应用服务在执行过程中需要调用的目标服务。

步骤S130，获取目标服务中已占用的资源对应的第一已占用资源量。

需要说明的是，为目标服务分配有资源，其中，第一已占用资源量为目标服务中当前已占用的资源对应的资源量。其中，目标服务的资源可以包括计算资源、内存资源等，也可以包括其他服务与目标服务之间建立的连接数等，例如，对于数据库而言，其他服务可以通过与数据库创建连接，以通过该连接从数据库中读取数据或者向数据库中写入数据，数据库支持的连接数有限，因此，数据库中已占用的资源可以为其他服务与数据库之间建立的连接数。

本实施例中，在确定应用服务在执行过程中需要调用的目标服务之后，获取目标服务的第一已占用资源量。

步骤S140，若第一已占用资源量小于第一阈值，则对应用服务进行扩容。

第一阈值为针对目标服务设置的，可以设置为目标服务正常运行时的可占用资源上限，若目标服务的已占用资源超过第一阈值，则表明目标服务中剩余可用资源较少，目标服务容易崩溃。第一阈值的具体数值可以根据实际需要好设置，例如，可以设置为目标服务总资源量的90％等；又例如，第一阈值的计算公式可以为：f(n)＝m*n*q，其中，m为目标服务中单个服务实例正常运行时可提供的最大资源量，其可以根据实验或经验设置，n为目标服务中包括的服务实例的数量，q为预设比值，可设置为0.9、0.8等。

本实施例中，若第一已占用资源量小于第一阈值，表明目标服务剩余可用资源较多，因此，可以对应用服务进行扩容。

其中，对应用服务进行扩容的具体扩容方案可以根据实际需要灵活设置，例如，可以在当前调度给该应用服务的资源的基础上，扩容预设第一比例，该预设第一比例可以根据实际需要灵活设置，例如，可以是50％，30％等。在一个示例中，假设当前调度给应用服务的内存为200M，预设第一比例为20％，当应用服务中已占用的内存为185M时，满足预设扩容条件，因此，在200M的基础上，增加40M，即扩容后，应用服务的内存资源为240M。

对应用服务进行扩容可以是在该应用服务中新增服务实例，例如，假设预设第一比例为50％，在扩容前，应用服务包括8个服务实例，则新增4个服务实例，即，扩容后，应用服务包括12个服务实例。或者，对应用服务进行扩容也可以是在不新增服务实例的基础上，增加每个服务实例包括的资源量。

本实施例提供的技术方案中，先对应用服务自身的资源占用情况进行监测，若监测到应用服务自身的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标共享服务；获取目标共享服务中已占用的资源对应的第一已占用资源量，若第一已占用资源量小于第一阈值，则对应用服务进行扩容，也就是说，在需要对应用服务进行扩容时，会参考该应用服务的关联服务的资源占用情况，从而根据关联服务的资源占用情况确定是否进行扩容，一方面，可以避免对应用服务扩容后，由于关联服务剩余可用资源较少，扩容部分无法调用管理服务的情况，提升扩容后应用服务的处理效率；另一方面，也可以避免对应用服务扩容后，应用服务占用关联服务中大量资源，导致关联服务中可用资源不足，关联服务崩溃，进而整个应用系统崩溃的情况，提升资源调度的合理性以及系统的稳定性。

请参见图2，图2是图1所示实施例中的步骤S140在一示例性实施例中的流程图。如图2所示，若第一已占用资源量小于第一阈值，则对应用服务进行扩容的过程可以包括步骤S210至步骤S230，详细介绍如下：

步骤S210，确定对应用服务进行扩容的扩容方案。

本实施例中，还可以确定对应用服务进行扩容的扩容方案。扩容方案可以根据实际需要灵活设置。

步骤S220，根据确定出的扩容方案预估对应用服务进行扩容后，扩容部分在目标服务中需要占用的资源对应的待占用资源量。

应用服务在执行过程中需要调用目标服务，即需要在目标服务中占用资源，若目标服务的剩余可用资源不足，则对应用服务进行扩容后，会出现扩容部分无法调用目标服务、连接超时，甚至导致目标服务崩溃，进而导致其他业务崩溃的情况。

为了确保对应用服务进行扩容后，扩容部分可以正常调用目标服务，且避免目标服务崩溃的情况，在确定出扩容方案后，可以根据该扩容方案预估对应用服务进行扩容后，扩容部分在目标服务中需要占用的资源对应的待占用资源量。例如，假设扩容方案为新增服务实例，目标服务为数据库，则可以根据预先设置的应用服务中单个服务实例需要与数据库建立的连接数，以及需要新增的服务实例数，确定新增的服务实例需要与数据库建立的连接总数，将连接总数作为待占用资源量，在一个示例中，假设应用服务中单个服务实例需要与数据库建立的连接数为5，扩容方案为新增6个服务实例，则待占用资源量为30。

步骤S230，若第一已占用资源量与待占用资源量的和小于第一阈值，则根据确定出的扩容方案对应用服务进行扩容。

本实施例中，先计算第一已占用资源量与待占用资源量的和，若计算得到的和小于第一阈值，则表明对应用服务进行扩容后，扩容部分在目标服务中需要占用的待占用资源量小于目标服务剩余可用资源，即目标服务的剩余可用资源可以满足扩容部分的需求，因此，根据确定出的扩容方案对应用服务进行扩容，从而确保对应用服务进行扩容后，扩容部分可以正常调用目标服务，保证应用服务的效率，降低目标服务包括的概率。

本实施例中，通过确定对应用服务进行扩容的扩容方案，根据确定出的扩容方案预估对应用服务进行扩容后，扩容部分在目标服务中需要占用的资源对应的待占用资源量，若第一已占用资源量与待占用资源量的和小于第一阈值，则根据确定出的扩容方案对应用服务进行扩容，从而使得对应用服务进行扩容后，扩容部分可以正常调用目标服务，降低目标服务崩溃的概率，提升业务的稳定性。

请参见图3，图3是图1所示实施例中的步骤S140在一示例性实施例中的流程图。如图3所示，若第一已占用资源量小于第一阈值，则对应用服务进行扩容的过程可以包括步骤S310至步骤S320，详细介绍如下：

步骤S310，若第一已占用资源量小于第一阈值，获取应用服务在目标服务中已占用的资源对应的第二已占用资源量。

本实施例中，在监测到应用服务自身的资源占用情况满足预设扩容条件，且确定出应用服务在执行过程中需要调用的目标服务后，若确定第一已占用资源量小于第一阈值，则可以获取该应用服务在目标服务中已占用的资源对应的第二已占用资源量。

在一些实施方式中，还可以在确定第一已占用资源量与待占用资源量的和小于第一阈值后，获取应用服务在目标服务中已占用的资源对应的第二已占用资源量。其中，对于待占用资源量，请参见前述记载，此处不再赘述。

步骤S320，若获取到的第二已占用资源量小于第二阈值，则对应用服务进行扩容。

其中，第二阈值为应用服务在目标服务中可占用的最大资源量，第二阈值小于第一阈值。为了避免同一应用服务在目标服务中占用大量资源，导致其他应用服务无法调用目标服务的情况，本实施例中，设置了第二阈值，其中，第二阈值可以根据实际需要灵活设置。

本实施例中，若第一已占用资源量小于第一阈值，且获取到的第二已占用资源量小于第二阈值，则表明目标服务剩余可用资源较多，且应用服务在该目标服务中已占用的资源较少，则可以对应用服务进行扩容。

在一些实施方式中，为了进一步降低应用服务扩容后，目标服务崩溃的情况，步骤S320可以包括：若第二已占用资源量与待占用资源量的和小于第二阈值，则根据确定出的扩容方案对应用服务进行扩容。其中，待占用资源量以及扩容方案可以参见前述介绍，此次不再赘述。

本实施例中，若第一已占用资源量小于第一阈值，则获取应用服务在目标服务中已占用的资源对应的第二已占用资源量，若获取到的第二已占用资源量小于第二阈值，则对应用服务进行扩容，从而避免某一应用服务在目标服务中已占用的资源较多，其他应用服务无法调用目标服务的情况，实现目标服务中的资源均衡分配。

在一示例性实施例中，在目标服务的数量为多个的条件下，图1所示实施例中的步骤S140可以包括：若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，则对应用服务进行扩容。

在目标服务的数量为多个的条件下，针对每个目标服务，均设置有对应的第一阈值，为了保证应用服务的扩容不会对每个目标服务造成影响，本实施例中，可以在多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值时，才对应用服务进行扩容。例如，假设多个目标服务包括A、B、C三个服务，目标服务A对应的第一阈值为b，目标服务B对应的第一阈值为a，目标服务C对应的第一阈值为c，则在目标服务A当前已占用的资源量小于a，目标服务B当前已占用的资源量小于b，且目标服务B当前已占用的资源量小于c的条件下，对应用服务进行扩容。

在一些实施方式中，在多个目标服务包括数据库和消息中间件，第一阈值包括数据库对应的第一连接数阈值以及消息中间件对应的第二连接数阈值的条件下，若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，则对应用服务进行扩容的过程可以包括：若数据库的连接数小于第一连接数阈值，且消息中间件的连接数小于第二连接数阈值，则对应用服务进行扩容。

需要说明的是，数据库的连接数为其他服务(除该数据库外的服务)与该数据库之间建立的连接的数量，第一连接数阈值为其他服务与该数据库之间可建立的最大连接数。第一连接数阈值可以根据实际需要灵活设置。

消息中间件是基于队列与消息传递技术，例如，消息队列等。消息中间件的连接数为其他服务(除该消息中间件外的服务)与消息中间件之间建立的连接的数量，第二连接数阈值为其他服务与消息中间件之间可建立的最大连接数。第二连接数阈值可以根据实际需要灵活设置。

在数据库的连接数小于第一连接数阈值，且消息中间件的连接数小于第二连接数阈值时，表明数据库和消息中间件的可用连接数较多，则对应用服务进行扩容。

本实施例中，在目标服务的数量为多个的条件下，若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，才对应用服务进行扩容，从而保证应用服务以及该应用服务对应的每个目标服务正常运行。

在一示例性实施例中，在图1所示实施例中的步骤S130之后，资源调度方法还可以包括：若第一已使用资源量大于等于第一阈值，则暂停对应用服务进行扩容，并对传输至应用服务的请求的数量进行限制。

若第一已占用资源量大于等于第一阈值，则表明目标服务的剩余可用资源较少，若继续对应用服务进行扩容，由于扩容部分还会在目标服务中占用资源，因此，会导致扩容部分无法调用目标服务，且目标服务的可用资源进一步减少，导致目标服务崩溃，进而导致整个系统崩溃。因此，为了避免这种情况，本实施例中，若第一已占用资源量大于等于第一阈值，则暂停对应用服务进行扩容，并对传输至应用服务的请求的数量进行限制，即对需要传输至应用服务的请求进行限流，从而避免应用服务崩溃的情况。

本实施例中，若第一已使用资源量大于等于第一阈值，则暂停对应用服务进行扩容，从而避免目标服务崩溃，并且，对传输至应用服务的请求的数量进行限制，从而可以降低应用服务崩溃的概率。

在一示例性实施例中，在图1所示实施例中的步骤S110之后，资源调度方法还可以包括：若监测到应用服务自身的资源占用情况满足预设缩容条件，则对应用服务进行缩容。

预设缩容条件为预设设置的、用于确定是否需要对应用服务进行缩容的条件。预设缩容条件可以根据实际需要灵活设置，在一个示例中，预设缩容条件可以设置为：应用服务自身的资源占用率小于预设资源占用率下限，当资源占用率小于资源占用率下限时，表明应用服务的剩余可用资源较多，为了提高资源利用率，可以对应用服务进行缩容，其中，预设资源占用率下限可以设置50％、20％、10％等。或者，在另一示例中，为了避免偶然性，预设缩容条件也可以设置为：应用服务自身的资源占用率小于预设资源占用率下限、资源占用率小于资源占用率下限的状态的持续时长超过时长阈值；在此条件下，若监测到应用服务自身的资源占用率小于预设资源占用率下限，且资源占用率小于资源占用率下限的状态的持续时长超过时长阈值，则对应用服务进行缩容。其中，时长阈值可以根据实际需要灵活设置，例如3分钟、5分钟等。

对应用服务进行缩容的方案可以根据实际需要灵活设置，例如，例如，可以在当前调度给该应用服务的资源的基础上，缩小预设第二比例，该预设第二比例可以根据实际需要灵活设置，例如，可以是23％，35％等。在一个示例中，假设当前调度给应用服务的内存为100M，预设第二比例为30％，则在100M的基础上，较少30M，即缩容后，应用服务的内存资源为70M。

本实施例中，若监测到应用服务自身的资源占用情况满足预设缩容条件，则对应用服务进行缩容，从而提升资源利用率。

以下对资源调度方法的具体示例进行说明。参见图4所示，资源调度方法包括：

步骤S401，获取应用服务以及共享服务的元数据。

应用服务的元数据包括应用服务中单个服务实例需要在共享服务中占用的资源量等。共享服务的元数据包括共享服务正常运行时的最大可占用资源量，即第一阈值。

步骤S402，对应用服务的资源占用情况进行监测。

本实施例中，对应用服务的资源占用情况进行监测。

步骤S403，若应用服务的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标共享服务。

本实施例中，若应用服务的资源占用情况满足预设扩容条件，则表明应用服务当前可用资源不足，需要对应用服务进行扩容，为了避免对应用服务进行扩容后，应用服务无法调用目标共享服务或目标共享服务包括的情况，本实施例中，还需要确定应用服务在执行过程中需要调用的共享服务，即目标共享服务。

在一个示例中，假设预设扩容条件为CPU资源占用率达到90％或内存占用率达到80％，则在应用服务自身的CPU资源占用率达到90％，或者应用服务自身的内存占用率达到80％时，确定应用服务在执行过程中需要调用的目标共享服务。

步骤S404，获取目标共享服务中已占用的资源对应的第一已占用资源量。

在确定目标共享服务后，需要获取目标共享服务中当前已占用的资源量，即第一已占用资源量。

在一个示例中，假设目标共享服务包括缓存、数据库以及消息队列，数据库资源为数据库的连接数，消息队列的资源为消息队列的连接数，缓存的资源为缓存的存储资源，则获取数据库中已建立的连接数、消息队列中已建立的连接数、缓存中已占用的内存资源量。

步骤S405，确定对应用服务进行扩容的扩容方案，根据确定出的扩容方案预估对应用服务进行扩容后，扩容部分在目标共享服务中需要占用的资源对应的待占用资源量。

本实施例中，在监测到应用服务自身的资源占用情况满足预设扩容条件，并确定应用服务在执行过程中需要调用的目标服务后，可以确定对应用服务进行扩容的扩容方案，根据确定出的扩容方案预估对应用服务进行扩容后，扩容部分在目标共享服务中需要占用的资源对应的待占用资源量。需要说明的是，本实施例中，以先执行步骤S404，再执行步骤S405为例进行说明，在其他示例中，也可以先执行步骤S405，再执行步骤S404，或者，步骤S404与步骤S405同时执行。

假设扩容方案为在应用服务包括的服务实例的基础上，增加预设50％的服务实例，应用服务包括的服务示例的数量为20，应用服务的元数据中，单个服务实例在数据库中需要建立的连接数为2，单个服务实例在消息队列中需要建立的连接数为3，单个服务实例在缓存中需要占用的存储资源量为4，则在应用服务中，需要新增的服务实例的个数为20*50％＝10，新增的服务实例在数据库中的待占用资源量为10*2＝20，新增的服务实例在消息队列中的待占用资源量为10*3＝30，新增的服务实例在缓存中的待占用资源量为10*4＝40。

步骤S406，判断目标共享服务对应的第一已占用资源量与待占用资源量的和是否小于对应的第一阈值。

在获取到第一已占用资源量和待占用资源量后，可以确定第一已占用资源量与待占用资源量的和，并确定和是否小于第一阈值。其中，第一阈值可以部署在目标共享服务的元数据中。第一阈值的计算方式可以是：m*n*q，例如，对于数据库而言，m为数据库中单个服务实例正常运行时可建立的最大连接数，n为数据库包括的服务示例的数量，q为90％。

承接上例，获取数据库对应的第一已占用资源量与待占用资源量的和，并判断得到的和是否小于数据库的第一阈值；获取消息队列对应的第一已占用资源量与待占用资源量的和，并判断得到的和是否小于消息队列的第一阈值；获取缓存对应的第一已占用资源量与待占用资源量的和，并判断得到的和是否小于缓存的第一阈值。

步骤S407、若是，则根据确定出的扩容方案对应用服务进行扩容。

若目标共享服务对应的第一已占用资源量与待占用资源量的和小于对应的第一阈值，则根据确定出的扩容方案对应用服务进行扩容。

承接上例，若数据库对应的第一已占用资源量与待占用资源量的和小于数据库的第一阈值，消息队列对应的第一已占用资源量与待占用资源量的和小于消息队列的第一阈值，且缓存对应的第一已占用资源量与待占用资源量的和小于缓存的第一阈值，则在应用服务中新增10个服务实例。

步骤S408、若否，则对传输至应用服务的请求的数量进行限制。

若目标共享服务对应的第一已占用资源量与待占用资源量的和大于等于对应的第一阈值，则对传输至应用服务的请求的数量进行限制。

步骤S409、若应用服务的资源占用情况满足预设缩容条件，则对应用服务进行缩容。

在步骤S402后，若监测到应用服务的资源占用情况满足预设缩容条件，则对应用服务进行缩容。

需要说明的是，以上步骤S401至步骤S409所涉及的详细过程均在前述的各个实施例中进行了描述，因此本处不再进行赘述。

本实施例的方案，一方面，可以避免对应用服务扩容后，由于关联服务剩余可用资源较少，扩容部分无法调用管理服务的情况，提升扩容后应用服务的处理效率；另一方面，也可以避免对应用服务扩容后，应用服务占用关联服务中大量资源，导致关联服务中可用资源不足，关联服务崩溃，进而整个应用系统崩溃的情况，提升资源调度的合理性以及系统的稳定性。

以下对本申请实施例的一个具体应用场景进行详细说明。其中，请参见图5，图5为资源调度方法的一个示例性应用场景，应用于云原生场景，其包括：配置模块、云原生HPA(Horizontal Pod Autoscaling)模块、控制模块、服务网格平台以及中间件管理模块。

其中，配置模块用于配置应用服务、用于访问需要调用的中间件服务等服务的元数据，例如，配置应用服务中单个服务实例需要在中间件服务中占用的资源量、中间件服务的第一阈值等数据。

中间件管理模块用于管理数据库、缓存、消息队列等中间件服务，提供中间件服务的资源占用情况。

控制模块用于从中间件管理模块中获取中间件服务的资源占用情况，并将中间件服务对应的已占用资源量与对应的第一阈值进行比较，得到比较结果。

云原生HPA模块用于实现容器资源的弹性伸缩，在本实施例中，用于根据应用服务自身的资源占用情况确定是否满足预设缩容条件或预设扩容条件，在满足预设扩容条件时，调用控制模块将中间件服务对应的已占用资源量与对应的第一阈值进行比较，并从控制模块获取比较结果，根据比较结果对应用服务进行扩容或控制服务网格平台对传输至应用服务的请求的数量进行限制。

服务网格平台用于对传输至应用服务的请求的数量进行管理，例如，在云原生HPA模块的控制下，对传输至应用服务的请求的数量进行限制。

需要说明的是，该应用场景各模块所实现的功能与上述实施例所提供的资源调度方法属于同一构思，其中应用场景各模块的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

参见图6，图6是本申请的一示例性实施例示出的资源调度装置的框图。如图6所示，该装置包括：

监测模块601，配置为对应用服务自身的资源占用情况进行监测；确定模块602，配置为若监测到应用服务自身的资源占用情况满足预设扩容条件，则确定应用服务在执行过程中需要调用的目标服务；获取模块603，配置为获取目标服务中已占用的资源对应的第一已占用资源量；扩容模块604，配置为若第一已占用资源量小于第一阈值，则对应用服务进行扩容。

在另一示例性实施例中，扩容模块604包括：

方案确定模块，配置为确定对应用服务进行扩容的扩容方案。

预估模块，配置为根据确定出的扩容方案预估对应用服务进行扩容后，扩容部分在目标服务中需要占用的资源对应的待占用资源量。

第一扩容子模块，配置为若第一已占用资源量与待占用资源量的和小于第一阈值，则根据确定出的扩容方案对应用服务进行扩容。

在另一示例性实施例中，该装置还包括：

限流模块，配置为若第一已占用资源量大于等于第一阈值，则暂停对应用服务进行扩容，并对传输至应用服务的请求的数量进行限制。

在另一示例性实施例中，扩容模块604包括：

资源量获取模块，配置为若第一已占用资源量小于第一阈值，则获取应用服务在目标服务中已占用的资源对应的第二已占用资源量。

第二扩容子模块，配置为若获取到的第二已占用资源量小于第二阈值，则对应用服务进行扩容。

在另一示例性实施例中，在目标服务包括应用服务在执行过程中需要调用的共享服务，目标服务的数量为多个的条件下，扩容模块604包括：

第三扩容子模块，配置为若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，则对应用服务进行扩容。

在另一示例性实施例中，在多个目标服务包括数据库和消息中间件，第一阈值包括数据库对应的第一连接数阈值以及消息中间件对应的第二连接数阈值的条件下，第三扩容子模块包括：

服务扩容模块，配置为若数据库的连接数小于第一连接数阈值，且消息中间件的连接数小于第二连接数阈值，则对应用服务进行扩容。

在另一示例性实施例中，该装置还包括：

缩容模块，配置为若监测到应用服务自身的资源占用率小于预设资源占用率下限，且资源占用率小于资源占用率下限的状态的持续时长超过时长阈值，则对应用服务进行缩容。

需要说明的是，上述实施例所提供的资源调度装置与上述实施例所提供的资源调度方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得电子设备实现上述各个实施例中提供的资源调度方法。

图7示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图7示出的电子设备的计算机系统1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(Central Processing Unit，CPU)701，其可以根据存储在只读存储器(Read-Only Memory，ROM)702中的程序或者从储存部分708加载到随机访问存储器(Random Access Memory，RAM)703中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 703中，还存储有系统操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(Input/Output，I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分707；包括硬盘等的储存部分708；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入储存部分708。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机可读指令，该计算机可读指令被电子设备的处理器执行时，使电子设备实现如前所述的方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，计算机指令被处理器执行时实现上述各个实施例中提供的方法。其中，该计算机指令可以存储在计算机可读存储介质中；电子设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述各个实施例中提供的方法。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。

Claims (10)

1.一种资源调度方法，其特征在于，所述方法包括：

对应用服务自身的资源占用情况进行监测；

若监测到所述应用服务自身的资源占用情况满足预设扩容条件，则确定所述应用服务在执行过程中需要调用的目标服务；

获取所述目标服务中已占用的资源对应的第一已占用资源量；

若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容。

2.如权利要求1所述的方法，其特征在于，所述若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容，包括：

确定对所述应用服务进行扩容的扩容方案；

根据确定出的扩容方案预估对所述应用服务进行扩容后，扩容部分在所述目标服务中需要占用的资源对应的待占用资源量；

若所述第一已占用资源量与所述待占用资源量的和小于所述第一阈值，则根据确定出的扩容方案对所述应用服务进行扩容。

3.如权利要求1所述的方法，其特征在于，在所述获取所述目标服务中已占用的资源对应的第一已占用资源量之后，所述方法还包括：

若所述第一已占用资源量大于等于所述第一阈值，则暂停对所述应用服务进行扩容，并对传输至所述应用服务的请求的数量进行限制。

4.如权利要求1所述的方法，其特征在于，所述若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容，包括：

若所述第一已占用资源量小于第一阈值，则获取所述应用服务在所述目标服务中已占用的资源对应的第二已占用资源量；

若获取到的第二已占用资源量小于第二阈值，则对所述应用服务进行扩容。

5.如权利要求1所述的方法，其特征在于，所述目标服务包括所述应用服务在执行过程中需要调用的共享服务，所述目标服务的数量为多个；所述若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容，包括：

若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，则对所述应用服务进行扩容。

6.如权利要求5所述的方法，其特征在于，所述多个目标服务包括数据库和消息中间件，所述第一阈值包括所述数据库对应的第一连接数阈值以及所述消息中间件对应的第二连接数阈值；所述若多个目标服务中每个目标服务的第一已占用资源量均小于对应的第一阈值，则对所述应用服务进行扩容，包括：

若所述数据库的连接数小于所述第一连接数阈值，且所述消息中间件的连接数小于所述第二连接数阈值，则对所述应用服务进行扩容。

7.如权利要求1所述的方法，其特征在于，在所述对应用服务自身的资源占用情况进行监测之后，所述方法还包括：

若监测到所述应用服务自身的资源占用率小于预设资源占用率下限，且资源占用率小于所述资源占用率下限的状态的持续时长超过时长阈值，则对所述应用服务进行缩容。

8.一种资源调度装置，其特征在于，所述装置包括：

监测模块，配置为对应用服务自身的资源占用情况进行监测；

确定模块，配置为若监测到所述应用服务自身的资源占用情况满足预设扩容条件，则确定所述应用服务在执行过程中需要调用的目标服务；

获取模块，配置为获取所述目标服务中已占用的资源对应的第一已占用资源量；

扩容模块，配置为若所述第一已占用资源量小于第一阈值，则对所述应用服务进行扩容。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1-7中的任一项所述的资源调度方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1-7中的任一项所述的资源调度方法。

Images