资源处理方法及装置与流程

1.本公开涉及计算机技术中的人工智能领域，尤其涉及一种资源处理方法及装置。


背景技术：

2.在进行业务处理的过程中，通常需要为业务分配相应的资源，例如服务器资源、数据库资源等等。
3.在当前分布式架构的环境下，分布式的各个主机上都包括很多资源，现有技术在进行资源分配的时候，通常是在任一个主机的可用资源里随机进行选择，以为业务分配相应的资源，然而，这样会导致分布式的每个主机上都包括多业务的部署。
4.因此现有技术的实现方式中，各个业务之间的分配资源的耦合性较高，从而会出现当一个业务出现问题时，对应存在资源耦合的业务也会受到影响，进而导致系统的稳定性较低。


技术实现要素：

5.本公开提供了一种一种资源处理方法及装置。
6.根据本公开的第一方面，提供了一种资源处理方法，包括：
7.获取业务处理请求，所述业务处理请求包括第一业务的标识；
8.获取所述第一业务的第一预设标签和所述第一业务对应的资源需求信息，所述资源需求信息中包括所述第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量；
9.获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，所述多个候选资源为所述至少一种资源类型对应的资源；
10.根据所述第一业务的第一预设标签、所述第一业务对应的资源需求信息、所述多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，在所述多个候选资源中确定所述第一业务对应的目标资源，并将所述目标资源分配给所述第一业务。
11.根据本公开的第二方面，提供了一种资源处理装置，包括：
12.第一获取模块，用于获取业务处理请求，所述业务处理请求包括第一业务的标识；
13.第二获取模块，用于获取所述第一业务的第一预设标签和所述第一业务对应的资源需求信息，所述资源需求信息中包括所述第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量；
14.第三获取模块，用于获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，所述多个候选资源为所述至少一种资源类型对应的资源；
15.处理模块，用于根据所述第一业务的第一预设标签、所述第一业务对应的资源需求信息、所述多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，在所述多个候选资源中确定所述第一业务对应的目标资源，并将所述目标资源分配给所述第一业务。
16.根据本公开的第三方面，提供了一种电子设备，包括：
17.至少一个处理器；以及
18.与所述至少一个处理器通信连接的存储器；其中，
19.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面所述的方法。
20.根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面所述的方法。
21.根据本公开的第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行第一方面所述的方法。
22.根据本公开的技术解决了资源耦合导致的系统稳定性较低的问题。
23.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
24.附图用于更好地理解本方案，不构成对本公开的限定。其中：
25.图1为本公开实施例提供的资源分配的实现示意图；
26.图2为本公开实施例提供的资源处理方法的流程图；
27.图3为本公开实施例提供的资源处理方法的流程图二；
28.图4为本公开实施例提供的为第一业务分配目标资源的示意图；
29.图5为本公开实施例提供的资源处理方法的流程图三；
30.图6为本公开实施例提供的动态调整目标资源的实现示意图；
31.图7为本公开实施例提供的预设标签的实现示意图；
32.图8为本公开实施例提供的资源处理方法的处理结构图；
33.图9为本公开实施例的资源处理装置的结构示意图；
34.图10是用来实现本公开实施例的资源处理方法的电子设备的框图。
具体实施方式
35.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
36.为了更好的理解本公开的技术方案，下面对本公开所涉及的相关技术进行进一步的详细介绍。
37.随着计算机技术的不断发展，目前的分布式架构也取得了长足的进步，在当前复杂的分布式架构环境下，随着面向服务架构(service
‑
oriented architecture，soa)到微服务概念的过度，及kubernetes、spring cloud、service mesh等容器化技术的引入，目前的全栈资源趋于“云”化、多实例、以及多集群共用化。
38.通常在进行业务处理的过程中，需要为业务分配相应的资源，以保证业务的正常执行，比如说服务器资源、数据库资源、磁盘资源等等，在分布式架构的环境下，分布式的各个主机上都包括很多的资源，相关技术中在进行资源分配的是，通常是在任一个主机的可用资源中随机进行选择，将选择的资源分配给当前的业务，然而，这样会导致分布式的每个主机上都包括很多业务的部署。
39.例如可以以服务器资源为例，结合图1进行理解，图1为本公开实施例提供的资源分配的实现示意图。
40.如图1所示，假设当前的系统架构中包括多个集群，其中，每一个集群中都包括多个服务器，假设当前在针对各项业务进行服务器资源分配的时候，是在各个集群上任意分配可用的服务器资源，则可能导致出现图1所示的情况，也就是说在集群1的服务器资源，同时分配给了订单业务、商品业务、用户业务，以及在集群2的服务器资源，同时分配给了订单业务、商品业务、用户业务，在集群3的服务器资源，同时分配给了订单业务、商品业务、用户业务。
41.这样则会导致各个业务之间的分配资源的耦合性较高，那么当其中的一个业务出现问题的时候，对应存在资源耦合的业务也会受到影响，比如说针对图1所示的情况，当集群1上的服务器资源对应的订单业务出现问题的时候，则有可能导致集群1上的服务器资源所对应的商品业务和用户业务都同时出现问题，进而会导致系统的稳定性较低。
42.针对现有技术中的问题，本公开提出了如下技术构思：通过针对业务和资源分别提供标签，在进行资源分配的时候，根据匹配的标签进行分配，比如说针对订单业务，只在对应的订单标签的服务器中分配资源，从而可以有效实现资源解耦，以提升系统稳定性。
43.下面结合具体的实施例对本公开提供的资源处理方法进行介绍，值得说明的是，本公开中各实施例的执行主体例如可以为服务器、处理器、微处理器等具备数据处理功能的设备，本实施例对执行主体的具体实现方式不做限制。
44.首先结合图2对本公开实施例提供的资源处理方法进行介绍，图2为本公开实施例提供的资源处理方法的流程图。
45.如图2所示，该方法包括：
46.s201、获取业务处理请求，业务处理请求包括第一业务的标识。
47.在本实施例中，可以首先获取业务处理请求，在业务处理请求中包括第一业务的标识，第一业务的标识用于指示当前的业务处理请求是针对第一业务请求分配资源的，其中第一业务的标识例如可以为业务名称、业务代码等等，本实施例对第一业务的标识的具体实现方式不做限制，只要其可以实现对第一业务的指示即可。
48.以及本公开中的第一业务可以是任意类型的待处理的任务，比如说可以是订单类型的待处理的任务，例如可以为增加订单修改地址的功能，或者可以是增加订单查询物流信息的功能，等等，本实施例对第一业务的具体实现方式不做特别限制，其可以根据实际需求进行选择，凡是系统中需要处理的任务均可以作为本实施例中的第一业务。
49.s202、获取第一业务的第一预设标签和第一业务对应的资源需求信息，资源需求信息中包括第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量。
50.在本实施例中，第一业务对应有第一预设标签，在一种可能的实现方式中，第一预设标签包括如下中的至少一种：业务类型、场景类型、资源状态、共享标识。其中，业务类型
可以指示当前业务的具体类型，例如可以为订单业务、用户业务、商品业务等等；场景类型可以指示当前申请资源的应用场景，比如说临时活动、用完即焚、离线、测试等等；以及资源状可以为资源是否维护、资源是否升级等等；共享标识可以指示当前的资源是否共享、是否独享等等。在实际实现过程中，上述介绍的业务类型、资源类型、业务状态、共享标识的具体实现方式均可以根据实际需求进行选择，本实施例对此不做特别限制。
51.以及在实际实现过程中，本实施例对第一预设标签的具体实现方式不做特别限制，在一种可能的实现方式中，可以理解的是，第一预设标签的具体内容实际上指示了当前第一业务需要什么样的资源，比如说基于上述介绍的内容，第一预设标签可以指示当前的第一业务需要独享的、用于处理订单业务的测试的资源等等，在此基础上，第一预设标签的具体实现方式可以根据实际需求进行选择和扩展。
52.其中，第一预设标签例如可以为人为预先设置的，或者还可以为将第一业务的业务信息输入至预设模型之后，预设模型输出的，本实施例对确定第一预设标签的具体实现方式同样不做限制。
53.以及本实施例中还可以获取第一业务对应的资源需求信息，其中，资源需求信息中可以包括第一业务所需的至少一种资源类型，本实施例中的资源类型可以包括如下中的至少一种：服务器资源、中央处理器(central processing unit，cpu)资源、磁盘资源、内存资源，在实际实现过程中，第一业务所具体需要的资源类型可以根据实际需求进行选择，比如说当前第一业务需要服务器资源和磁盘资源，或者说当前第一业务需要服务器资源、磁盘资源、内存资源，本实施例对第一业务所需的至少一种资源类型不做特别限制，其可以根据实际需求进行选择。
54.以及资源需求信息中还可以包括每个资源类型对应的资源需求量，比如说当前的第一业务请求cpu资源和内存资源，其中，cpu资源的资源需求量为50ghz(千兆赫兹)，内存资源的资源需求量为25gb，在实际实现过程中，第一业务对应的资源需求信息可以根据实际需求进行选择，本实施例对此不做特别限制。
55.以及在获取第一业务的第一预设标签以及第一业务对应的资源需求信息的实现过程中，在一种可能的实现方式中，例如在业务处理请求中包括第一业务的这些相关信息，则例如可以从业务处理请求中获取第一预设标签以及资源需求信息。在另一种可能的实现方式中，第一预设标签和资源需求信息例如可以存储在业务对应的预设存储单元中，则在另一种可能的实现方式中，例如可以从业务对应的预设存储单元中获取第一预设标签和资源需求信息。
56.s203、获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，多个候选资源为至少一种资源类型对应的资源。
57.在本实施例中，存在多个候选资源，其中候选资源为第一业务所需的至少一个资源类型对应的资源，比如说当前第一业务所需的至少一个资源类型为cpu资源和内存资源，则多个候选资源就可以为至少一个cpu资源和至少一个内存资源。
58.其中，每个候选资源各自对应有第二预设标签，比如说其中的每个cpu资源都对应各自的第二预设标签，以及每个内存资源都对应各自的第二预设标签，在一种可能的实现方式中，第二预设标签包括如下中的至少一种：业务类型、场景类型、资源状态、共享标识。其具体实现方式与上述介绍的第一预设标签类似，不同之处在于，第二预设标签是针对预
设资源设置的。
59.以及本实施例中，每个候选资源还对应各自的剩余资源量，其中剩余资源量为可以分配给其余业务的资源量，在一种可能的实现方式中，本实施例中的剩余资源量为除了已分配资源和预配置资源之外的资源的资源量，其中，已分配资源为已经分配给对应的业务的资源，预配置资源为预先规定好分配给某些业务的资源，除去已分配资源和预配置资源之外的资源，即为剩余资源，其中剩余资源的资源量就是本实施例中的剩余资源量。
60.在本实施例中，在确定剩余资源量的时候，是将扣除了已分配资源和预配置资源之后的资源量确定为剩余资源量，可以有效避免将预配置资源错误的分配给第一业务之后导致的资源分配错误，从而可以有效保证资源分配的正确性。
61.其中，在获取多个候选资源各自对应的第二预设标签以及剩余资源量的实现过程中，在一种可能的实现方式中，各个候选资源各自对应的第二预设标签以及剩余资源量例如可以资源对应的预设存储单元中，则例如可以从资源对应的预设存储单元中获取各个候选资源各自对应的第二预设标签以及剩余资源量；或者，在另一种可能的实现方式中，各个候选资源各自对应的第二预设标签还可以和各个候选资源关联存储，则例如可以根据各个候选资源直接获取各自对应的第二预设标签，以及直接读取各个候选资源各自对应的剩余资源量。
62.s204、根据第一业务的第一预设标签、第一业务对应的资源需求信息、多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，在多个候选资源中确定第一业务对应的目标资源，并将目标资源分配给第一业务。
63.基于上述介绍可以确定的是，当前可以确定第一业务的第一预设标签、资源需求信息，以及各个候选资源各自对应的第二预设标签、剩余资源量，则可以根据这些信息为第一业务分配资源，具体的，可以根据上述介绍的信息，在多个候选资源中确定第一业务对应的目标资源，之后将目标资源分配给第一业务。
64.在一种可能的实现方式中，可以根据第一预设标签和第二预设标签进行匹配，从而将预设标签相匹配的候选资源确定为可以分配给第一业务的资源，之后将标签匹配的候选资源中，剩余资源量满足第一业务的资源需求量的候选资源确定为第一业务对应的目标资源。
65.基于这样的实现方式，可以在保证分配的目标资源满足第一业务的资源需求量的基础上，同时保证目标资源是根据预设标签的匹配分配给第一业务的，基于预设标签进行资源的分配，可以有效实现资源的解耦，具体的，将标签匹配的资源分配给对应的业务，从而可以保证各个不同的业务会分配到不同的资源，避免出现上述介绍的同一服务器资源同时部署了很多业务的情况，从而有效保证了资源的解耦分配，基于这样的资源分配方式，当某一个业务出现问题的时候，因为不存在资源的解耦，也就不会对其余的业务造成影响，从而有效保证了系统的稳定性。
66.本公开实施例提供的资源处理方法，包括：获取业务处理请求，业务处理请求包括第一业务的标识。获取第一业务的第一预设标签和第一业务对应的资源需求信息，资源需求信息中包括第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量。获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，多个候选资源为至少一种资源类型对应的资源。根据第一业务的第一预设标签、第一业务对应
的资源需求信息、多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，在多个候选资源中确定第一业务对应的目标资源，并将目标资源分配给第一业务。通过针对业务和资源分别设置各自对应的预设标签，之后在针对第一业务进行资源分配的时候，根据预设标签以及需求资源量进行资源的分配，从而可以在满足第一业务的需求资源量的基础上，按照匹配的标签为第一业务分配对应的资源，以有效实现资源的解耦，从而可以提升系统的稳定性。
67.在上述实施例的基础上，下面结合图3至图4对本公开实施例提供的资源处理方法进行进一步的详细介绍，图3为本公开实施例提供的资源处理方法的流程图二，图4为本公开实施例提供的为第一业务分配目标资源的示意图。
68.如图3所示，该方法包括：
69.s301、获取业务处理请求，业务处理请求包括第一业务的标识。
70.s302、获取第一业务的第一预设标签和第一业务对应的资源需求信息，资源需求信息中包括第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量。
71.s303、获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，多个候选资源为至少一种资源类型对应的资源。
72.其中，s301
‑
s303的实现方式与上述介绍的s201
‑
s203的实现方式类似，此处不再赘述。
73.s304、根据第一业务的第一预设标签和多个候选资源各自对应的第二预设标签进行匹配，在多个候选资源中确定第一业务对应的至少一个标签匹配资源，其中，各标签匹配资源对应的第二预设标签和第一业务的第一预设标签相同。
74.本实施例中，在确定第一业务对应的目标资源时，可以根据第一业务的第一预设标签和多个候选资源各自对应的第二预设标签进行匹配，从而可以可在多个候选资源中确定第一业务对应的至少一个标签匹配资源，可以理解的是，本实施例中介绍的标签匹配资源为第二预设标签和第一业务的第一预设标签相匹配的资源。
75.在本实施例中，标签的匹配例如可以为标签相同，则本实施例中的标签匹配资源对应的第二预设标签和第一业务的第一预设标签可以为相同的，比如说第一业务的第一预设标签包括“订单业务”，表示第一业务的业务类型为订单业务，同时标签匹配资源对应的第二预设标签包括“订单业务”，表示当前的资源为针对订单业务可用的资源。
76.或者在可选的实现方式中，标签的匹配还可以为第一预设标签和第二预设标签之间存在映射关系，本实施例对标签的匹配的具体实现方式不做特别限制，其可以根据实际需求进行选择。
77.例如可以基于图示理解基于第一预设标签和第二预设标签的匹配为第一业务分配资源，同样以服务器资源为例，则分配的资源例如可以如图4所示，参见图4，当前在集群1中包括服务器1
‑
1、服务器1
‑
2、服务器1
‑
3，在集群2中包括服务器2
‑
1、服务器2
‑
2、服务器2
‑
3，等等。
78.例如当前针对订单业务a进行资源的分配，其中，订单业务a对应的第一预设标签包括“订单业务”，其中，图4中的各个服务器都可以作为候选资源，则可以首先根据预设标签进行匹配。假设其中的服务器1
‑
1、服务器1
‑
2、服务器1
‑
3对应的第二预设标签都包括“订单业务”，则可以确定服务器1
‑
1、服务器1
‑
2、服务器1
‑
3的第二预设标签都是和第一预设标
签相匹配的，因此其中的服务器1
‑
1、服务器1
‑
2、服务器1
‑
3实际上都可以为标签匹配资源，之后可以根据剩余资源量在标签匹配资源中可以进行进一步的选择，从而确定目标资源。
79.s305、根据第一业务所需的至少一种资源类型，确定标签匹配资源中各资源类型各自对应的剩余资源量。
80.在确定标签匹配资源之后，实际上已经完成了预设标签的匹配操作，在确定目标资源的时候，除了预设标签的匹配之外，还需要进一步保证分配给第一业务的资源是能够满足第一资源的资源需求量的，因此可以根据第一业务所需的至少一种资源类型，确定标签匹配资源中各个资源类型各自对应的剩余资源量。
81.可以理解的是，标签匹配资源中实际上是包括各种资源类型的资源的，比如说包括至少一个服务器资源、至少一个cpu资源、至少一个磁盘资源、至少一个内存资源，则可以确定标签匹配资源中，各个服务器资源的剩余资源量、各个cpu资源的剩余资源量、各个磁盘资源的剩余资源量，各个内存资源的剩余资源量，在实际实现过程中，资源类型的具体实现方式可以根据实际需求进行选择，本实施例对此不做限制。
82.s306、针对任一个资源类型，在标签匹配资源中确定资源类型对应的资源需求量大于或等于第一剩余资源量的至少一个初步资源，其中，第一剩余资源量为标签匹配资源中资源类型对应的剩余资源量。
83.在确定各个资源类型各自对应的资源需求量之后，就可以根据资源需求量和第一业务的业务需求量，确定目标资源了，可以理解的是，在进行资源分配的时候，实际上针对各个资源类型的资源都会进行资源的分配，为了便于说明，下面以任一个资源类型为例，对资源分配的处理方式进行介绍，假设以服务器资源为例进行说明，其余各种资源类型的处理方式是类似的。
84.可以确定的是，在标签匹配资源中包括各个资源类型的资源，则例如可以在标签匹配资源中确定服务器资源对应的剩余资源量，以及第一业务对应的资源需求信息中包括服务器资源对应的资源需求量，为了保证分配的资源能够满足第一业务的需求，则可以在标签匹配资源中确定服务器资源对应的资源需求量大于或等于服务器资源对应的资源需求量的至少一个初步资源，此处确定的初步资源是预设标签和剩余资源量均满足第一业务的需求的资源。
85.例如可以结合图4进行理解，基于上述介绍可以确定的是，针对订单业务a，其中的服务器1
‑
1、服务器1
‑
2、服务器1
‑
3实际上都可以为标签匹配资源，假设服务器1
‑
1的剩余资源量大于订单业务a对服务器资源的资源需求量，以及服务器1
‑
2的剩余资源量大于订单业务a对服务器资源的资源需求量，以及服务器1
‑
3的剩余资源量小于订单业务a对服务器资源的资源需求量，则可以确定服务器1
‑
1和服务器1
‑
2是满足第一业务的资源需求量的，因此可以将服务器1
‑
1和服务器1
‑
2确定为初步资源。
86.上述是以服务器资源为例，对确定初步资源的实现方式进行的介绍，针对其余各种可能的资源类型，确定初步资源的实现方式是类似的，此处不再赘述。
87.以及还需要说明的是，本实施例中的第一业务的各个资源类型对应的资源需求量，例如可以包括初始申请资源量以及增长资源量，其中，初始申请资源量为第一业务初始情况下执行的时候所需要的资源量，增长资源量为随着第一业务的执行过程的进行所进一步需要的资源量。比如说针对内存资源，第一业务在初始情况下，只需要5gb就可以完成第
一业务的部署以及运行了，那么第一业务的初始申请资源量可以为5gb，但是随着第一业务的不断运行，第一业务所需要的内存资源必然是随之增加的，则还需要为第一业务分配增长资源量，以保证第一业务的后续正常运行，比如说第一业务的增长资源量为50gb。
88.在一种可能的实现方式中，第一业务的增长资源量可以为根据第一业务的资源增长速度确定的，其中，资源增长速度可以为预设的，或者还可以为通过模型处理、机器算法等方法计算得到的；或者，第一业务的资源增长量还可以为预设的；或者，第一业务的资源增长量还可以为根据预设算法确定的，本实施例对此不做特别限制。
89.s307、在各资源类型各自对应的至少一个初步资源中，确定第一业务对应的目标资源。
90.基于上述介绍的内容，可以确定至少一个初步资源，可以理解的是，本实施例中的任意一个初步资源都是满足第一业务的需求的，因此任意一个初步资源都可以作为第第一业务对应的目标资源，因此可以在各个资源类型各自对应的至少一个初步资源中确定第一业务对应的目标资源。
91.在一种可能的实现方式中，例如可以在各个资源类型各自对应的至少一个初步资源中随机进行选择，从而确定各个资源类型各自对应的选择的初步资源，从而确定第一业务对应的目标资源。或者，还可以在各个资源类型各自对应的至少一个初步资源中，将资源标识最大的初步资源确定为目标资源，或者将资源标识最小的初步资源确定为目标资源。或者，还可以将各个资源类型各自对应的至少一个初步资源中，将剩余资源量和第一业务对应的各个资源类型的资源需求量的差值最小的确定为目标资源，本实施例对确定目标资源的具体实现方式不做特别限制，其可以根据实际需求进行选择，本实施例对此不做限制，只要目标资源是根据初步资源确定的即可。
92.在本实施例中，确定的各个业务对应的目标资源例如可以如图4所示，参见图4，假设当前针对订单业务a，确定的服务器资源的目标资源为服务器102，针对订单业务b，确定的服务器资源的目标资源为服务器1
‑
1，以及针对其他的业务，确定的目标资源如图4所示，本实施例对此不再赘述。
93.可以理解的是，图4介绍的情况仅为示例性的说明，在实际实现过程中，针对第一业务所具体分配的目标资源可以取决于实际的实现，本实施例对此不做限制。
94.基于图4可以确定的是，本实施例中在保证可以满足业务的资源需求量的基础上，有效保证了按照预设标签进行资源的分配，从而可以有效实现资源的解耦，以避免因为资源耦合导致的一个业务出现问题时，其余业务也会随之受影响，比如说在图4的情况中，当订单业务a出现问题的时候，因为订单业务a的资源和其余的业务的资源不存在耦合，从而不会对其余业务造成影响，进而可以有效保证系统稳定性。
95.本公开实施例提供的资源处理方法，包括：获取业务处理请求，业务处理请求包括第一业务的标识。获取第一业务的第一预设标签和第一业务对应的资源需求信息，资源需求信息中包括第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量。获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，多个候选资源为至少一种资源类型对应的资源。根据第一业务的第一预设标签和多个候选资源各自对应的第二预设标签进行匹配，在多个候选资源中确定第一业务对应的至少一个标签匹配资源，其中，各标签匹配资源对应的第二预设标签和第一业务的第一预设标签相同。根
据第一业务所需的至少一种资源类型，确定标签匹配资源中各资源类型各自对应的剩余资源量。针对任一个资源类型，在标签匹配资源中确定资源类型对应的资源需求量大于或等于第一剩余资源量的至少一个初步资源，其中，第一剩余资源量为标签匹配资源中资源类型对应的剩余资源量。在各资源类型各自对应的至少一个初步资源中，确定第一业务对应的目标资源。通过根据第一预设标签和第二预设标签进行匹配，以在候选资源中确定标签匹配标签，从而可以有效根据标签的匹配为第一业务分配资源，以有效实现资源解耦，之后根据各个资源类型的资源需求量以及标签匹配资源中各个资源类型的剩余资源量，确定目标资源，从而可以有效保证确定的目标资源是满足第一业务的资源需求的，进而准确有效的保证了在满足第一业务的资源需求的情况下，有效实现资源的解耦，提升系统的稳定性。
96.在上述介绍内容的基础上，本公开实施例提供的资源处理方法，在将目标资源分配给第一业务之后，还可以获取第一业务的资源使用率，之后根据资源使用率对目标资源进行动态调整，从而提升资源分配的合理性，下面集合图5至图6对目标资源动态调整的实现方式进行介绍，图5为本公开实施例提供的资源处理方法的流程图三，图6为本公开实施例提供的动态调整目标资源的实现示意图。
97.如图5所示，该方法包括：
98.s501、获取第一业务的资源使用率。
99.在本实施例中，针对向第一业务分配的目标资源可以进行动态跟踪，从而确定第一业务对分配的目标资源的资源使用情况，以获取第一业务的资源使用率，例如可以确定第一业务对分配的目标资源的资源使用量，然后除以分配的目标资源的资源量，就可以确定资源使用率。
100.可以理解的是，本实施例中的目标资源包括第一业务所需要的各个资源类型的资源，因此资源使用率也对应包括各个资源类型的资源使用率，例如可以包括服务器资源的资源使用率、cpu使用率、磁盘使用率、内存使用率等等。
101.s502、若资源使用率大于或等于第一阈值，则向预设设备发送第一报警信息，并获取标签匹配资源中的剩余资源量。
102.例如可以参照图6进行理解，如图6所示，本实施例中可以将资源使用率和第一阈值进行比较，当资源使用率大于或等于第一阈值的时候，表示资源供给不足，当资源供给不足的时候，可能导致第一业务的运行稳定性降低，则此时可以向预设设备发送第一报警信息，其中第一报警信息用于指示当前针对第一业务分配的资源不足。
103.之后就需要动态增加向第一业务分配的目标资源，在增加向第一业务分配的目标资源的时候，需要保证增加的资源同样是标签匹配的资源，因此可以根据标签匹配资源进行资源的动态调整，具体的，可以获取标签匹配资源中的剩余资源量，本实施例中的标签匹配资源为第二预设标签和第一业务的第一预设标签相同的资源。
104.s503、若标签匹配资源中的剩余资源量大于等于待增加的资源量，则根据标签匹配资源增加向第一业务分配的目标资源。
105.在获取标签匹配资源中的剩余资源量之后，可以将标签匹配资源中的剩余资源量和针对第一业务待增加的资源量进行比较，从而确定当前在标签匹配资源中是否存在足够多的资源来进行动态的增加。
106.在一种可能的实现方式中，若标签匹配资源中的剩余资源量大于等于待增加的资
源量，则表示当前标签匹配资源量中的剩余资源量是足够完成目标资源的动态增加的，则可以根据标签匹配资源增加向第一业务分配的目标资源，具体的，就是将标签匹配资源中的部分资源分配给第一业务，其中，分配的部分资源的资源量大于等于待增加的资源量。
107.s504、若标签匹配资源中的剩余资源量小于待增加的资源量，则对标签匹配资源进行扩容，并根据扩容后的标签匹配资源增加为第一业务分配的目标资源。
108.在另一种可能的实现方式中，若标签匹配资源中的剩余资源量小于待增加的资源量，则表示当前标签匹配资源量中的剩余资源量是不足以完成目标资源的动态增加的，则可以首先对标签匹配资源进行扩容，实际上扩容就是增加标签匹配资源的资源量，以保证标签匹配资源的资源量足以完成对第一业务的目标资源的动态增加。
109.在对标签匹配资源进行扩容之后，就可以根据扩容后的标签匹配资源增加为第一业务分配的目标资源了，具体的，就是将扩容后的标签匹配资源中的部分资源分配给第一业务，其中，分配的部分资源的资源量大于等于待增加的资源量。
110.上述介绍的针对第一业务的目标资源的动态增加，是针对各个资源类型的资源一起介绍的，可以理解的是，在实际实现过程中，实际上的动态调整，是各个资源类型分别进行的，也就是说假设当前服务器资源的资源分配不足，那么就按照上述介绍的实现方式动态增加服务器资源，再例如当前磁盘资源的资源分配不足，那么就按照上述介绍的方式动态增加磁盘资源，各个资源类型的目标资源的动态增加方式都是类似的，此处不进行一一赘述。
111.s505、若资源使用率小于或等于第二阈值，则向预设设备发送第二报警信息，并减少向第一业务分配的目标资源；第一阈值大于第二阈值。
112.以及，还例如可以参照图6进行理解，如图6所示，本实施例中还可以将资源使用率和第二阈值进行比较，其中第一阈值是大于第二阈值的，当资源使用率小于或等于第二阈值的时候，表示资源供给过量，当资源供给过量的时候，可能导致资源的浪费，则此时可以向预设设备发送第二报警信息，其中第二报警信息用于指示当前针对第一业务分配的资源过量。
113.之后就需要动态减少向第一业务分配的目标资源，并将减少的目标资源释放为未被占用的候选资源，以保证系统中的资源可以动态的进行调整，有效避免了资源的浪费。
114.在另一种可选的实现方式中，当第一业务的资源使用率大于第二阈值并且小于第一阈值的时候，可以确定第一业务的资源供给是正常的，暂时无需进行调整，其中，第一阈值和第二阈值的具体设置可以根据实际需求进行选择，本实施例对此不做限制，只要保证第一阈值大于第二阈值即可。
115.本公开实施例提供的资源处理方法，通过将第一业务的资源使用率和第一阈值、第二阈值向比较，从而确定第一业务的资源使用情况，在第一业务的资源供给不足的时候，及时的增加向第一业务分配的目标资源，以及在第一业务的资源供给过量的时候，及时的减少向第一业务分配的目标资源，从而可以有效实现对系统中的各个候选资源的动态调整，有效保证了各个业务可以分配到足够的资源，并且本实施例中将减少的目标资源释放为未被占用的候选资源，可以有效的实现系统中资源的动态分配，以避免资源的浪费，提升资源分配的合理性。
116.本公开实施例提供的资源处理方法，还可以在图形用户界面上显示资源信息，其
中，资源信息包括如下中的至少一种：第一业务的资源使用率、各候选资源各自对应的资源使用率、各候选资源各自对应的资源总量、各候选资源各自对应的剩余资源量。
117.通过在图形用户界面上显示资源信息，可以直观并且快速有效的确定资源相关信息，从而提升系统资源的可观测性。
118.在上述介绍的各实施例的基础上，下面结合图7和图8对本公开实施例提供的资源处理方法进行进一步的系统详细介绍，图7为本公开实施例提供的预设标签的实现示意图，图8为本公开实施例提供的资源处理方法的处理结构图。
119.可以首先结合图7对预设标签进行理解，如图7所示，本公开中对业务和资源建立了多维度的标签体系，从而能够实现最优化解耦及最大化资源共享。
120.其中标签体系分为两个方向，分别为图7所示的系统标签体系，其中系统标签体系就是针对业务设置的标签体系，其对应的也就是上述实施例中介绍的第一预设标签，在一种可能的实现方式中，针对业务的第一预设标签可以包括图7所示的与用户相关的用户生成内容(user generated content，ugc)、专业生产内容(professional generated content，pgc)、品牌生产内容(brand generated content，bgc)等、订单相关的订单信息、商品相关的商品信息、商品数据等，可以理解的是，这些标签都是可选的标签，其可以理解为是预先建设的预设标签，之后可以根据实际需求在这些标签中进行选择，从而确定各个业务对应的第一预设标签，比如说当前的第一业务是用户业务，则可以在上述介绍的用户相关的标签中选择相应的第一预设标签，以在后续的资源匹配中根据第一预设标签匹配相应的资源。
121.以及，本公开中还针对各个资源进行了多维度的标签建设，如图7所示的资源场景体系，其中包括场景类型标签、业务类型标签、独享或共享标签、资源状态标签等等，同样的，针对各个资源，可以在这些资源中选择相应的标签，从而确定各个标签对应的第二预设资源。
122.之后根据第一预设标签和第二预设标签进行匹配，就可以基于标签实现资源的分配，从而有效实现资源解耦。
123.在上述图7介绍的标签相关实现方式的基础上，下面结合图8进行详细介绍，如图8所示，其中的业务标签管理单元可以对业务所需的第一预设标签进行增加、删除、修改、查找，其中的标签系统在上述的图7进行了介绍，此处不再赘述。
124.以及其中的资源标签管理单元可以对资源所需的第二预设标签进行增加、删除、修改、查找，其中的标签系统在上述的图7同样进行了介绍，此处不再赘述。
125.以及其中的项目管理单元中的业务评估子单元可以在业务评审及设计阶段完成后，接收业务处理请求，根据业务处理请求对第一业务对所需的全栈资源，如图8中所示的资源类型：服务器资源(server)、关系型数据库(mysql)、非关系型数据库(redis、memcache)、文件存储服务(file store、bos)、搜索引擎(elastic search)等，根据第一业务所需的资源类型进行量化，也就是图8所示的预估所需资源量化。
126.其中量化的结果例如可以为图8中所示的，cpu所需为xghz，磁盘所系为xgb，内存所需为xgb。
127.本公开中的项目管理单元还可以实现复杂业务的创建、已量化资源的申请维护、业务状态的管理、业务已申请资源的查看、业务实际使用资源量与预估量查看、业务所需资
源的修改(扩容、缩容、释放等)。
128.本公开中的资源评估模块例如可以根据第一业务的资源需求信息进行资源评估，然后基于上述各实施例介绍的方法，将第一业务的目标资源提供(图8中的产出箭头)给项目管理单元，项目管理单元进一步的可以将第一业务的目标资源分配给第一业务。
129.对应的，资源评估模块会对资源池剩余量进行维护，具体的，会将分配给第一业务的目标资源在对应的资源池中进行扣除。
130.以及本实施例中还包括资源监控及报警单元，其可以对分配给第一业务的目标资源进行动态跟踪，并进行相应的反馈，当第一业务的目标资源的实际使用值超预估或低预估时，可以通过报警单元进行报警，之后业务监控及报警单元可以对第一业务的目标资源进行动态调整，具体的，可以进行目标资源的增加或者减少，以及业务监控及报警单元还可以对资源池中的资源进行扩容或者缩容，以实现对资源的动态分配和动态调整，从而可以有效保证系统资源分配的合理性。
131.以及本实施例中的资源管理单元还可以对各类资源进行自身属性的建设，例如对资源自身属性如硬盘资源大小、硬盘最大iops阙值、内存大小、cpu大小、集群或实例承接最大连接数阙值、集群或实例承接读写qps阙值进行确定并存储。其中阙值的建设数据大部分通过压测或服务提供方提供。以及资源管理单元还可以维护各类资源与项目之间使用关系、对各类资源进行标签体系建设、查看各资源已分配的项目预估值及实际使用值、查看各资源总体使用值等等。
132.综上所述，本公开实施例提供的资源处理方法，通过根据预设标签确定为业务分配目标资源，从而可以有效避免各个业务之间的资源耦合，有效提升了系统稳定性，并且通过对业务及资源进行资源使用的动态追踪，并建立资源补给及资源反哺的策略，以追补的方式保证业务资源的充足，以反哺的方式保证了资源不必要的浪费，以有效保证了系统资源的分配合理性。
133.图9为本公开实施例的资源处理装置的结构示意图。如图9所示，本实施例的资源处理装置900可以包括：第一获取模块901、第二获取模块902、第三获取模块903、处理模块904。
134.第一获取模块901，用于获取业务处理请求，所述业务处理请求包括第一业务的标识；
135.第二获取模块902，用于获取所述第一业务的第一预设标签和所述第一业务对应的资源需求信息，所述资源需求信息中包括所述第一业务所需的至少一种资源类型、以及每个资源类型对应的资源需求量；
136.第三获取模块901，用于获取多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，所述多个候选资源为所述至少一种资源类型对应的资源；
137.处理模块904，用于根据所述第一业务的第一预设标签、所述第一业务对应的资源需求信息、所述多个候选资源各自对应的第二预设标签、以及每个候选资源对应的剩余资源量，在所述多个候选资源中确定所述第一业务对应的目标资源，并将所述目标资源分配给所述第一业务。
138.一种可能的实现方式中，所述处理模块904具体用于：
139.根据所述第一业务的第一预设标签和所述多个候选资源各自对应的第二预设标
签进行匹配，在所述多个候选资源中确定所述第一业务对应的至少一个标签匹配资源，其中，各所述标签匹配资源对应的第二预设标签和所述第一业务的第一预设标签相同；
140.根据所述第一业务对应的资源需求信息和每个所述标签匹配资源对应的剩余资源量，在所述标签匹配资源中确定所述第一业务对应的目标资源。
141.一种可能的实现方式中，所述处理模块904具体用于：
142.根据所述第一业务所需的至少一种资源类型，确定所述标签匹配资源中各所述资源类型各自对应的剩余资源量；
143.针对任一个所述资源类型，在所述标签匹配资源中确定第一剩余资源量大于或等于所述资源类型对应的资源需求量的至少一个初步资源，其中，所述第一剩余资源量为所述标签匹配资源中所述资源类型对应的剩余资源量；
144.在各所述资源类型各自对应的至少一个初步资源中，确定所述第一业务对应的目标资源。
145.一种可能的实现方式中，针对任一个所述候选资源，所述候选资源对应的剩余资源量为所述候选资源中，除已分配资源和预配置资源之外的资源的资源量。
146.一种可能的实现方式中，所述处理模块904还用于：
147.获取所述第一业务的资源使用率；
148.根据所述资源使用率对所述目标资源进行动态调整。
149.一种可能的实现方式中，所述处理模块904具体用于：
150.若所述资源使用率大于或等于第一阈值，则向预设设备发送第一报警信息，并增加向所述第一业务分配的目标资源；
151.若所述资源使用率小于或等于第二阈值，则向预设设备发送第二报警信息，并减少向所述第一业务分配的目标资源；
152.所述第一阈值大于所述第二阈值。
153.一种可能的实现方式中，所述处理模块904具体用于：
154.获取所述标签匹配资源中的剩余资源量；
155.若所述标签匹配资源中的剩余资源量大于等于待增加的资源量，则根据所述标签匹配资源增加向所述第一业务分配的目标资源；
156.若所述标签匹配资源中的剩余资源量小于所述待增加的资源量，则对所述标签匹配资源进行扩容，并根据扩容后的标签匹配资源增加为所述第一业务分配的目标资源。
157.一种可能的实现方式中，所述处理模块904还用于：
158.所述减少为所述第一业务分配的目标资源之后，将所述减少的目标资源释放为未被占用的候选资源。
159.一种可能的实现方式中，所述处理模块904具体用于：
160.在图形用户界面上显示资源信息，其中，所述资源信息包括如下中的至少一种：所述第一业务的资源使用率、各所述候选资源各自对应的资源使用率、各所述候选资源各自对应的资源总量、各所述候选资源各自对应的剩余资源量。
161.一种可能的实现方式中，所述第一预设标签和/或所述第二预设标签包括如下中的至少一种：业务类型、场景类型、资源状态、共享标识。
162.本公开提供一种资源处理方法及装置，应用于计算机技术中的人工智能领域，以
达到提升系统稳定性的目的。
163.根据本公开的实施例，本公开还提供了一种电子设备和一种可读存储介质。
164.根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。
165.图10示出了可以用来实施本公开的实施例的示例电子设备1000的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
166.如图10所示，电子设备1000包括计算单元1001，其可以根据存储在只读存储器(rom)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(ram)1003中的计算机程序，来执行各种适当的动作和处理。在ram 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、rom 1002以及ram 1003通过总线1004彼此相连。输入/输出(i/o)接口1005也连接至总线1004。
167.设备1000中的多个部件连接至i/o接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
168.计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如资源处理方法。例如，在一些实施例中，资源处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由rom1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到ram 1003并由计算单元1001执行时，可以执行上文描述的资源处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行资源处理方法。
169.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
170.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
171.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd
‑
rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
172.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
173.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
174.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端
‑
服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与vps服务("virtual private server"，或简称"vps")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
175.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
176.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。