CN114675973A - 资源管理方法、设备、存储介质及程序产品 - Google Patents

Abstract

本申请提供一种资源管理方法、设备、存储介质及程序产品，通过获取各服务的初始并发处理量及线程池的线程数；获取各服务的实时并发请求量及并发请求参考量；若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，控制各服务以对应的初始并发处理量处理并发请求；若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，对各服务的实时并发请求量求和获取实时并发请求总量，根据实时并发请求总量与线程数的比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量处理并发请求。从整体角度对资源合理管控，各服务的并发处理量更合理，保证资源稳定使用的同时使资源充分利用，保障系统稳定性。

Description

资源管理方法、设备、存储介质及程序产品

技术领域

本申请涉及云计算技术领域，尤其涉及一种资源管理方法、设备、存储介质及程序产品。

背景技术

分布式服务调用为远程调用，每个服务都应该轻量运行，即服务运行耗时短，而如果服务耗时长，会长时间占用线程池资源，当该服务调用并发突增时，很容易造成全链路节点堵塞，从而影响其他服务的调用，并进一步造成整个服务集群性能下降甚至整体不可用。

现有技术中分布式服务中每一服务都可能存在并发的调用请求，而在并发管控中通常会对单个服务配置并发处理量，也即最大同时处理的请求数量，当并发请求量超过并发处理量，超过的并发请求直接拒绝进而避免了临界资源的使用压力。

现有技术中对于单个服务通常人工配置并发处理量，满足一定的临界资源管控要求，但是可能存在某些核心服务分配资源不足或资源浪费等问题，无法实现资源充分利用。

发明内容

本申请提供一种资源管理方法、设备、存储介质及程序产品，以从整体角度对资源进行合理管控，使得各服务的并发处理量更合理。

第一方面，本申请提供一种资源管理方法，包括：

获取各服务的初始并发处理量、以及线程池的线程数；

获取各服务的实时并发请求量、以及各服务的并发请求参考量；

将每一服务的实时并发请求量与对应的并发请求参考量进行比较；

若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；

若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。

第二方面，本申请提供一种资源管理设备，包括：

第一获取单元，用于获取各服务的初始并发处理量、以及线程池的线程数；

第二获取单元，用于获取各服务的实时并发请求量、以及各服务的并发请求参考量；

比较单元，用于将每一服务的实时并发请求量与对应的并发请求参考量进行比较；

控制单元，用于若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；

配置单元，用于若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，

所述控制单元还用于，控制各服务以设置后的并发处理量进行并发请求的处理。

第三方面，本申请提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如第一方面所述的方法。

本申请提供的资源管理方法、设备、存储介质及程序产品，通过获取各服务的初始并发处理量、以及线程池的线程数；获取各服务的实时并发请求量、以及各服务的并发请求参考量；将每一服务的实时并发请求量与对应的并发请求参考量进行比较；若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将实时并发请求总量与线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。本实施例从整体角度对资源进行合理管控，使得各服务的并发处理量更合理，在保证资源稳定使用的同时使资源得到充分利用，避免出现资源分配不足或资源浪费，一定程度上保障系统的稳定性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请一实施例提供的资源管理方法场景示意图；

图2为本申请一实施例提供的资源管理方法的流程图；

图3为本申请另一实施例提供的资源管理方法的流程图；

图4为本申请一实施例提供的资源管理设备的结构图；

图5为本申请一实施例提供的电子设备的结构图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

首先对本申请所涉及的名词进行解释：

分布式系统：建立在网络之上的软件系统，具有高度的内聚性和透明性，通俗的说，就是有多个性能规格及代码含义一样的单机组成的系统。

临界资源：多道程序系统中存在许多进程，它们共享各种资源，然而有很多资源一次只能供一个进程使用。一次仅允许一个进程使用的资源称为临界资源。许多物理设备都属于临界资源，如输入机、打印机、磁带机等。本文中的临界资源是从软件线程数角度描述的，底层限制同为硬件，如多个线程连接数据库，连接数的上线就是数据库的临界资源边界。

分布式服务调用为远程调用，每个服务都应该轻量运行，即服务运行耗时短，而如果服务耗时长，会长时间占用线程池资源，当该服务调用并发突增时，很容易造成全链路节点堵塞，从而影响其他服务的调用，并进一步造成整个服务集群性能下降甚至整体不可用。

现有技术中分布式服务中每一服务都可能存在并发的调用请求，而在并发管控中通常会对单个服务配置并发处理量，也即最大同时处理的请求数量，当并发请求量超过并发处理量，超过的并发请求直接拒绝进而避免了临界资源的使用压力。

现有技术中对于单个服务通常人工配置并发处理量，满足一定的临界资源管控要求，但是可能存在某些核心服务分配资源不足或资源浪费等问题，无法实现资源充分利用。

为了解决上述技术问题，本申请实施例提供一种资源管理方法，以针对于分布式系统的临界资源从整体角度对资源进行合理管控，具体的，通过获取各服务的初始并发处理量、以及线程池的线程数；获取各服务的实时并发请求量、以及各服务的并发请求参考量；将每一服务的实时并发请求量与对应的并发请求参考量进行比较；若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将实时并发请求总量与线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。本实施例从整体角度对资源进行合理管控，使得各服务的并发处理量更合理，在保证资源稳定使用的同时使资源得到充分利用，避免出现资源分配不足或资源浪费，一定程度上保障系统的稳定性。

本申请具体的应用场景如图1所示，包括待进行资源管理的多个分布式服务101、服务器102、并发数库105，还可包括管理平台103和/或注册中心104；服务器102可通过扫描扫描代码注解信息或目标文件、和/或从管理平台103、注册中心104，获取各服务的初始并发处理量、以及线程池的线程数；从分布式服务101获取各服务的实时并发请求量，从并发数库105获取各服务的并发请求参考量；将每一服务的实时并发请求量与对应的并发请求参考量进行比较；若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将实时并发请求总量与线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的资源管理方法流程图。本实施例提供了一种资源管理方法，其执行主体为服务器等电子设备，该资源管理方法具体步骤如下：

S201、获取各服务的初始并发处理量、以及线程池的线程数。

在本实施例中，并发处理量是服务最大可同时处理的服务调用的请求数量，各服务的初始并发处理量为各服务最初的并发处理量，初始并发处理量可以为预设的并发处理量，例如在代码注解信息或某一文件中预先设置某个或某些服务的并发处理量，可通过扫描、解析获取；也可以是用户随时设置的并发处理量，例如通过管理平台设置某个或某些服务的并发处理量；也可以是注册中心中预存的并发处理量，其中预存的并发处理量为上一次资源管理过程最终确定的各服务的初始并发处理量。

线程池是一种多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务。在本实施例中，线程池中包括多个线程，对于任一服务，在处理一个请求时启动一个线程，若同时处理多个请求则需启动多个线程。

更具体的，在获取各服务的初始并发处理量、以及线程池的线程数时，可包括：

通过扫描代码注解信息或目标文件，获取各服务的初始并发处理量、以及线程池的线程数；和/或

接收管理平台或注册中心推送的各服务的初始并发处理量、以及线程池的线程数。

在本实施例中，可从不同的来源获取各服务的初始并发处理量、以及线程池的线程数，为后续处理提供数据支撑。

若在代码注解信息或目标文件中预先设置某个或某些服务的并发处理量，可通过扫描代码注解信息或目标文件，对代码注解信息或目标文件进行解析，获取各服务的初始并发处理量；同样的，线程池的线程数也可预先设置在代码注解信息或目标文件中，通过扫描代码注解信息或目标文件获取线程池的线程数。

此外若用户随时通过管理平台设置某个或某些服务的并发处理量和/或线程池的线程数，例如在一些应急情况下可进行设置，管理平台可推送某个或某些服务的并发处理量和/或线程池的线程数；若注册中心中预存各服务的并发处理量和/或线程池的线程数，其中预存的并发处理量为上一次资源管理过程最终确定的各服务的初始并发处理量，注册中心可推送预存的各服务的并发处理量和/或线程池的线程数。

需要说明的是，若任一服务的初始并发处理量或者线程池的线程数存在多种来源、且不相等，则可按照优先级来选择一种，其中管理平台优先级最高，注册中心次之，代码注解信息或目标文件最低。此外，在不发生冲突的情况下不同服务的初始并发处理量的来源可有不同的组合，例如某些服务的初始并发处理量来源于扫描代码注解信息，某些服务的初始并发处理量来源于扫描目标文件，某些服务的初始并发处理量来源于管理平台推送，某些服务的初始并发处理量来源于注册中心推送，组合方式此处不一一列举。

S202、获取各服务的实时并发请求量、以及各服务的并发请求参考量。

在本实施例中，对于任一服务，在运行时可能同时接收到多个用户请求，其数量也即实时并发请求量，可根据交易量、TPS(Transaction Per Second，每秒事务处理量)来计算出服务的实时并发请求量，例如统计某一时刻服务的各设备的并发请求量并进行汇总，还可对不同时刻的并发请求量进行平均，可以由用户自定义实现计算频率，如每隔半小时计算一次。将各服务的实时并发请求量存储在并发数库中。

而各服务的并发请求参考量则是衡量实时并发请求量的参考值，判断实时并发请求量是否出现突变，其中任一服务的并发请求参考量可以是服务在历史时间段中的历史并发请求量的中值、平均值或最大值，可从并发数库中获取历史时间段中的历史并发请求量，并计算中值、平均值或最大值，当然也可以是其他值，来反映历史并发请求量的水平，为判断实时并发请求量是否出现突变提供参考。

需要说明的是，本实施例中不限定S201和S202的先后顺序，S201和S202可同时执行或按任意顺序执行。

S203、将每一服务的实时并发请求量与对应的并发请求参考量进行比较。

在本实施例中，将实时并发请求量与对应的并发请求参考量进行比较，若每一服务的实时并发请求量与对应的并发请求参考量接近，则执行S204，否则，若至少一个服务的实时并发请求量与对应的并发请求参考量差异比较大，则执行S205。其中实时并发请求量与对应的并发请求参考量是否接近可判断服务的实时并发请求量与对应的并发请求参考量的差值是否在预设范围内。

S204、若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理。

在本实施例中，若每一服务的实时并发请求量与对应的并发请求参考量接近，则说明每一服务的实时并发请求量均未发生突变，可不调整各服务的并发处理量，使用初始并发处理量进行并发请求的处理。

S205、若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。

在本实施例中，若至少一个服务的实时并发请求量与对应的并发请求参考量差异比较大，则说明至少一个服务的实时并发请求量发生突变，需要调整各服务的并发处理量，来从整体上优化各服务的并发处理量，适应至少一个服务的实时并发请求量发生突变，避免核心服务分配资源不足、或资源浪费。

具体的，对各服务的实时并发请求量求和得到实时并发请求总量，并将实时并发请求总量与线程池的线程数进行比较，由于线程池中一个线程可以处理一个请求，且线程池的线程数有限，因此可根据实时并发请求总量与线程池的线程数的比较结果来合理分配各服务的并发处理量。

可选的，如图3所示，将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，具体包括：

S301、将所述实时并发请求总量与所述线程数进行比较；

S302、若所述实时并发请求总量与所述线程数不相等，则获取各服务的实时并发请求量的比例，并根据各服务的实时并发请求量的比例调整各服务的并发处理量；

S303、若所述实时并发请求总量与所述线程数相等，则控制各服务以对应的初始并发处理量进行并发请求的处理。

在本实施例中，在实时并发请求总量与线程池线程数相等的情况中，可不调整各服务的并发处理量，使用初始并发处理量进行并发请求的处理，当然也可按照各服务的实时并发请求量的比例重新配置各服务的并发处理量，使资源得到充分利用。

而在实时并发请求总量与线程数不相等的情况中，也即实时并发请求总量可能大于或者小于线程数，可按照各服务的实时并发请求量的比例调整各服务的并发处理量，以从整体角度对资源进行合理管控，使得各服务的并发处理量更合理，资源充分利用。

具体的，若所述实时并发请求总量小于所述线程数，则按照各服务的实时并发请求量的比例，同比例增加各服务的并发处理量；

若所述实时并发请求总量大于所述线程数，则按照各服务的实时并发请求量的比例，同比例减小各服务的并发处理量。

在实时并发请求总量小于线程池的线程数的情况中，此时资源存在剩余，各服务的并发处理量可按照各服务的实时并发请求量进行配置，但是各服务的实时并发请求量可能存在波动，为了能够在实时并发请求量增加的情况下也能够得到及时处理，可按照各服务的实时并发请求量的比例，同比例增加各服务的并发处理量，也可使得资源被充分利用；在实时并发请求总量大于线程池的线程数的情况中，此时资源存在不足，各服务的并发处理量仍可按照各服务的实时并发请求量进行配置，但是此时可能存在线程池中没有足够的线程来处理请求，因此需要按照各服务的实时并发请求量的比例，同比例减小各服务的并发处理量，使得每个服务的并发请求均能够有效的被处理。当然，按照各服务的实时并发请求量的比例调整各服务的并发处理量也并不限于上述举例，其他方式亦可，例如在各服务的初始并发处理量基础上按各服务的实时并发请求量的比例增减并发处理量等。

在设置各服务的并发处理量后，还可将各服务的并发处理量推送至注册中心，以便于下一次执行S201时注册中心可作为各服务的初始并发处理量进行推送。

本实施例提供的资源管理方法，通过获取各服务的初始并发处理量、以及线程池的线程数；获取各服务的实时并发请求量、以及各服务的并发请求参考量；将每一服务的实时并发请求量与对应的并发请求参考量进行比较；若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将实时并发请求总量与线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。本实施例从整体角度对资源进行合理管控，使得各服务的并发处理量更合理，在保证资源稳定使用的同时使资源得到充分利用，避免出现资源分配不足或资源浪费，一定程度上保障系统的稳定性。

在上述实施例的基础上，所述方法还包括：

若任一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对该服务的并发请求参考量根据该服务的实时并发请求量进行调整，作为下一次执行S202时获取各服务的并发请求参考量时该服务的并发请求参考量。例如，若实时并发请求量大于对应的并发请求参考量，则适当增加并发请求参考量，或者重新获取新的一段历史时间段中的历史并发请求量计算并发请求参考量，新的历史时间段中包括当前时刻；若实时并发请求量小于对应的并发请求参考量，则适当减小并发请求参考量，或者重新获取新的一段历史时间段中的历史并发请求量计算并发请求参考量，新的历史时间段中包括当前时刻。

在上述任意实施例的基础上，所述方法还包括：

获取各服务的业务指标，业务指标包括但不限于以下至少一种：交易量、峰值区间、响应耗时、业务网类型等；根据各服务的业务指标以及预设分级算法，对各服务进行分级和/或分组。

其中，举例来讲，可将服务划分为高、中、低三个等级，预设分级算法可以是对于某一指标按照高、中、低三个等级分别配置取值范围，对于任一服务，判断其指标处于哪一个取值范围，进而确定为该取值范围对应的等级。当然也可采用其他的分级算法，此处不做限定。

本实施例中可根据各服务的等级对各服务进行部署，例如将高等级的服务部署于高性能设备上，将低等级的服务部署于低性能设备上；此外，可选的，在服务运行过程中，可实时判断服务的等级，当服务等级发生变化，可动态的重新部署服务。

可选的，在设置各服务的并发处理量时，也可根据服务的等级来调整服务的并发处理量，也即上述实施例中，根据各服务的实时并发请求量的比例和/或服务的等级调整各服务的并发处理量，对于高等级的服务可适当增加并发处理量，对于低等级的服务可适当减小并发处理量，保证高等级的服务的稳定运行。

图4为本申请实施例提供的资源管理设备的结构图。本实施例提供的资源管理设备可以执行资源管理方法实施例提供的处理流程，如图4所示，所述资源管理设备400包括：第一获取单元401、第二获取单元402、比较单元403、控制单元404及配置单元405。

第一获取单元401，用于获取各服务的初始并发处理量、以及线程池的线程数；

第二获取单元402，用于获取各服务的实时并发请求量、以及各服务的并发请求参考量；

比较单元403，用于将每一服务的实时并发请求量与对应的并发请求参考量进行比较；

控制单元404，用于若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；

配置单元405，用于若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，

所述控制单元404还用于，控制各服务以设置后的并发处理量进行并发请求的处理。

在本申请的一个或多个实施例中，所述配置单元405在根据比较结果设置各服务的并发处理量时，用于：

若所述实时并发请求总量与所述线程数不相等，则获取各服务的实时并发请求量的比例，并根据各服务的实时并发请求量的比例调整各服务的并发处理量。

在本申请的一个或多个实施例中，所述配置单元405在根据各服务的实时并发请求量的比例调整各服务的并发处理量时，用于：

若所述实时并发请求总量小于所述线程数，则按照各服务的实时并发请求量的比例，同比例增加各服务的并发处理量；

若所述实时并发请求总量大于所述线程数，则按照各服务的实时并发请求量的比例，同比例减小各服务的并发处理量。

在本申请的一个或多个实施例中，所述控制单元404还用于：

若所述实时并发请求总量与所述线程数相等，则控制各服务以对应的初始并发处理量进行并发请求的处理。

在本申请的一个或多个实施例中，所述第一获取单元401在获取各服务的初始并发处理量、以及线程池的线程数时，用于：

通过扫描代码注解信息或目标文件，获取各服务的初始并发处理量、以及线程池的线程数；和/或

接收管理平台或注册中心推送的各服务的初始并发处理量、以及线程池的线程数。

在本申请的一个或多个实施例中，所述第二获取单元402在获取各服务的并发请求参考量时，用于：

获取任一服务在历史时间段中的历史并发请求量的中值、平均值或最大值，将历史并发请求量的中值、平均值或最大值确定为该服务的并发请求参考量。

在本申请的一个或多个实施例中，所述配置单元405还用于：

若任一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对该服务的并发请求参考量根据该服务的实时并发请求量进行调整，作为下一次获取各服务的并发请求参考量时该服务的并发请求参考量。

本申请实施例的资源管理设备可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图5示出了本申请实施例提供的一种电子设备的硬件结构示意图。如图5所示，该电子设备500，用于实现上述任一方法实施例中对应于电子设备的操作，本实施例的电子设备500可以包括：存储器501，处理器502和通讯接口503。

存储器501，用于存储计算机程序。该存储器501可能包含高速随机存取存储器(Random Access Memory，RAM)，也可能还包括非易失性存储(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

处理器502，用于执行存储器存储的计算机程序，以实现上述实施例中的方法，具体可以参见前述方法实施例中的相关描述。该处理器502可以是中央处理单元(CentralProcessing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

可选的，存储器501既可以是独立的，也可以跟处理器502集成在一起。当存储器501是独立于处理器502之外的器件时，电子设备500还可以包括总线。该总线用于连接存储器501和处理器502。该总线可以是工业标准体系结构(IndustryStandard Architecture，ISA)总线、外部设备互连(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

通讯接口503，用于接收或发送请求和/或数据。

本实施例提供的电子设备可用于执行上述实施例中的方法，其实现方式和技术效果类似，本实施例此处不再赘述。

另外，本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的方法。

另外，本实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的方法。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

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

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上各实施例仅用以说明本申请实施例的技术方案，而非对其限制；尽管参照前述各实施例对本申请实施例进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请实施例各实施例技术方案的范围。

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

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (14)

1.一种资源管理方法，其特征在于，包括：

获取各服务的初始并发处理量、以及线程池的线程数；

获取各服务的实时并发请求量、以及各服务的并发请求参考量；

将每一服务的实时并发请求量与对应的并发请求参考量进行比较；

若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；

若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，控制各服务以设置后的并发处理量进行并发请求的处理。

2.根据权利要求1所述的方法，其特征在于，所述根据比较结果设置各服务的并发处理量，包括：

若所述实时并发请求总量与所述线程数不相等，则获取各服务的实时并发请求量的比例，并根据各服务的实时并发请求量的比例调整各服务的并发处理量。

3.根据权利要求2所述的方法，其特征在于，所述根据各服务的实时并发请求量的比例调整各服务的并发处理量，包括：

若所述实时并发请求总量小于所述线程数，则按照各服务的实时并发请求量的比例，同比例增加各服务的并发处理量；

若所述实时并发请求总量大于所述线程数，则按照各服务的实时并发请求量的比例，同比例减小各服务的并发处理量。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

若所述实时并发请求总量与所述线程数相等，则控制各服务以对应的初始并发处理量进行并发请求的处理。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述获取各服务的初始并发处理量、以及线程池的线程数，包括：

通过扫描代码注解信息或目标文件，获取各服务的初始并发处理量、以及线程池的线程数；和/或

接收管理平台或注册中心推送的各服务的初始并发处理量、以及线程池的线程数。

6.根据权利要求1-3任一项所述的方法，其特征在于，所述获取各服务的并发请求参考量，包括：

获取任一服务在历史时间段中的历史并发请求量的中值、平均值或最大值，将历史并发请求量的中值、平均值或最大值确定为该服务的并发请求参考量。

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

若任一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对该服务的并发请求参考量根据该服务的实时并发请求量进行调整，作为下一次获取各服务的并发请求参考量时该服务的并发请求参考量。

8.一种资源管理设备，其特征在于，包括：

第一获取单元，用于获取各服务的初始并发处理量、以及线程池的线程数；

第二获取单元，用于获取各服务的实时并发请求量、以及各服务的并发请求参考量；

比较单元，用于将每一服务的实时并发请求量与对应的并发请求参考量进行比较；

控制单元，用于若每一服务的实时并发请求量与对应的并发请求参考量的差值均在预设范围内，则控制各服务以对应的初始并发处理量进行并发请求的处理；

配置单元，用于若至少一个服务的实时并发请求量与对应的并发请求参考量的差值不在预设范围内，则对各服务的实时并发请求量求和获取实时并发请求总量，并将所述实时并发请求总量与所述线程数进行比较，根据比较结果设置各服务的并发处理量，

所述控制单元还用于，控制各服务以设置后的并发处理量进行并发请求的处理。

9.根据权利要求8所述的设备，其特征在于，所述配置单元在根据比较结果设置各服务的并发处理量时，用于：

若所述实时并发请求总量与所述线程数不相等，则获取各服务的实时并发请求量的比例，并根据各服务的实时并发请求量的比例调整各服务的并发处理量。

10.根据权利要求9所述的设备，其特征在于，所述配置单元在根据各服务的实时并发请求量的比例调整各服务的并发处理量时，用于：

若所述实时并发请求总量小于所述线程数，则按照各服务的实时并发请求量的比例，同比例增加各服务的并发处理量；

若所述实时并发请求总量大于所述线程数，则按照各服务的实时并发请求量的比例，同比例减小各服务的并发处理量。

11.根据权利要求8-10任一项所述的设备，其特征在于，所述控制单元还用于：

若所述实时并发请求总量与所述线程数相等，则控制各服务以对应的初始并发处理量进行并发请求的处理。

12.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-7任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-7任一项所述的方法。

14.一种计算机程序产品，其特征在于，包括计算机程序，该计算机程序被处理器执行时实现如权利要求1-7任一项所述的方法。

Images