资源调度方法、装置、设备、可读存储介质及程序产品

技术领域

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

背景技术

现有技术中，实现跨云调度的调度方案，需要通过虚拟化平台获取到底层资源权限，再进行策略和资源开通，这种方式只支持私有云，但是不支持公有云，而且获取到底层资源权限需要做比较复杂的接口对接，存在诸多限制条件，也面临许多实际操作困难，不利于调度能力快速部署和扩容，从而导致虚拟化平台中资源调度的速度较慢。

发明内容

本申请针对现有的方式的缺点，提出一种资源调度方法、装置、设备、计算机可读存储介质及计算机程序产品，用于解决如何快速实现虚拟化平台中资源调度的问题。

第一方面，本申请提供了一种资源调度方法，由云管理平台执行，包括：

获取用户的资源调度请求，资源调度请求包括资源筛选策略；

基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；

确定至少两个资源调度策略标签对应的编码值；

基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；

确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源。

在一个实施例中，基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签，包括：

基于资源调度请求中用户请求的资源的相关信息，通过云管理平台的调度单元，进行匹配处理，从云管理平台的资源视图中心存储的资源调度策略标签集合中，确定至少两个资源调度策略标签，至少两个资源调度策略标签中每个资源调度策略标签表征的资源满足所述相关信息；

其中，相关信息包括资源的类型、资源的数量、资源归属的虚拟化平台的平台标签、资源不归属的虚拟化平台的平台标签中至少一项，每个资源调度策略标签包括用户的用户标签、预设虚拟化平台集合中任一虚拟化平台对应的任一网络的网络标签、任一网络中资源的资源性能指标标签中至少一项。

在一个实施例中，确定至少两个资源调度策略标签对应的编码值，包括：

通过云管理平台的调度单元，从云管理平台的策略中心单元存储的编码值集合中调用至少两个资源调度策略标签对应的编码值，至少两个资源调度策略标签中每个资源调度策略标签对应的编码值的类型为数值、字符串中任一项。

在一个实施例中，基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值，包括：

若资源筛选策略包括将任一资源性能指标的指标值为最大的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最大指标值对应的编码值确定为目标编码值；

若资源筛选策略包括将任一资源性能指标的指标值为最小的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最小指标值对应的编码值确定为目标编码值。

在一个实施例中，基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值，包括：

基于至少两个资源调度策略标签中每个资源调度策略标签对应的编码值表征的至少两个资源性能指标的指标值，以及至少两个资源性能指标的指标值对应的预设权重，确定每个资源调度策略标签对应的编码值的评分；

将各评分进行排序，并将各评分中最大评分对应的编码值确定为目标编码值。

在一个实施例中，在获取用户的资源调度请求之后，还包括：

若确定预设的资源调度策略标签集合中没有资源调度策略标签满足资源调度请求，则将资源调度请求上报给级联云管理平台，以使级联云管理平台将资源调度请求发送给其他云管理平台进行资源调度，级联云管理平台为云管理平台和其他云管理平台的上一级管理系统。

第二方面，本申请提供了一种资源调度装置，应用于云管理平台，包括：

第一处理模块，用于获取用户的资源调度请求，资源调度请求包括资源筛选策略；

第二处理模块，用于基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；

第三处理模块，用于确定至少两个资源调度策略标签对应的编码值；

第四处理模块，用于基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；

第五处理模块，用于确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给所述虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源。

第三方面，本申请提供了一种电子设备，包括：处理器、存储器和总线；

总线，用于连接处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，执行本申请第一方面的资源调度方法。

第四方面，本申请提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被用于执行本申请第一方面的资源调度方法。

第五方面，本申请提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现本申请第一方面中资源调度方法的步骤。

本申请实施例提供的技术方案，至少具有如下有益效果：

云管理平台获取用户的资源调度请求，资源调度请求包括资源筛选策略；云管理平台基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；云管理平台确定至少两个资源调度策略标签对应的编码值；云管理平台基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；云管理平台确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源；如此，云管理平台不对虚拟化平台进行直接监控纳管，对虚拟化平台入侵少，对接部署方便，例如能够对接公有云，从而快速实现虚拟化平台中的资源调度。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的资源调度系统的架构示意图；

图2为本申请实施例提供的一种资源调度方法的流程示意图；

图3为本申请实施例提供的一种资源调度的示意图；

图4为本申请实施例提供的一种资源调度的示意图；

图5为本申请实施例提供的一种资源调度装置的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”指示实现为“A”，或者实现为“B”，或者实现为“A和B”。

可以理解的是，在本申请的具体实施方式中，涉及到资源调度相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请实施例是识别系统提供的一种资源调度方法，该资源调度方法涉及云技术等领域。

为了更好的理解及说明本申请实施例的方案，下面对本申请实施例中所涉及到的一些技术用语进行简单说明。

算力网络：算力网络是一种在云、边、端之间按需分配，以及灵活调度计算资源、存储资源以及网络资源的新型信息基础设施。

算网大脑：算网大脑作为算力网络的编排管理核心，通过人工智能技术，实现算网智能感知、智能编排调度、算网自智等，促进算网一体、算网共生发展。

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

为了更好的理解本申请实施例提供的方案，下面结合具体的一个应用场景对该方案进行说明。

在一个实施例中，图1中示出了本申请实施例所适用的一种资源调度系统的架构示意图，可以理解的是，本申请实施例所提供的资源调度方法可以适用于但不限于应用于如图1所示的应用场景中。

本示例中，如图1所示，该示例中的资源调度系统的架构可以包括但不限于云管理平台10、终端20和数据库30。云管理平台10、终端20和数据库30之间可以通过网络40进行交互。

用户通过终端20发送资源调度请求给云管理平台10，云管理平台10获取用户的资源调度请求，资源调度请求包括资源筛选策略；云管理平台10基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；云管理平台10确定至少两个资源调度策略标签对应的编码值；云管理平台10基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；云管理平台10确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源；云管理平台10将目标编码值存储在数据库30中。

可理解，上述仅为一种示例，本实施例在此不作限定。

其中，终端包括但不限于智能手机(如Android手机、iOS手机等)、手机模拟器、平板电脑、笔记本电脑、数字广播接收器、MID(Mobile Internet Devices，移动互联网设备)、PDA(个人数字助理)、智能语音交互设备、智能家电、车载终端等。

服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器或服务器集群。

上述网络可以包括但不限于：有线网络，无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、Wi-Fi及其他实现无线通信的网络。具体也可基于实际应用场景需求确定，在此不作限定。

参见图2，图2示出了本申请实施例提供的一种资源调度方法的流程示意图，其中，该方法可以由任一电子设备执行，如可以是服务器等；作为一可选实施方式，该方法可以由服务器执行，为了描述方便，在下文的一些可选实施例的描述中，将以云管理平台的服务器作为该方法执行主体为例进行说明。如图2所示，本申请实施例提供的资源调度方法包括如下步骤：

S201，获取用户的资源调度请求，资源调度请求包括资源筛选策略。

具体地，CMP(Cloud Management Platform，云管理平台)通过CMP内部组件CMP-API(算力需求统一对外服务接口)，接收上层调度、用户需求、业务需求等资源调度请求，资源调度请求包括：请求的资源类别、请求的资源数量、调度策略(资源筛选策略，例如成本优先、网络时延最小、权重优先等)、资源限制(例如，是否需要亲和某个平台；例如，在虚拟化平台(region)下的指定VPC(Virtual Private Cloud，虚拟私有云)适用于原资源扩容)等。

S202，基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签。

具体地，基于资源调度请求，从资源调度策略标签集合(policy ID集合)中确定至少两个资源调度策略标签policy ID，至少两个资源调度策略标签policy ID中的每个资源调度策略标签policy ID可以包括多个标签，多个标签例如网络标签(网络ID)、用户标签(custom ID)、其他用于筛选平台(region)所需的标签(例如带宽、时延等)。

S203，确定至少两个资源调度策略标签对应的编码值。

具体地，至少两个资源调度策略标签中每个资源调度策略标签对应的编码值的类型例如数值、字符串等；一个资源调度策略标签对应的编码值例如，地点南京带宽40M时延0.5秒。

S204，基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值。

具体地，若资源筛选策略包括将任一资源性能指标的指标值为最大的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最大指标值对应的编码值确定为目标编码值。若资源筛选策略包括将任一资源性能指标的指标值为最小的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最小指标值对应的编码值确定为目标编码值。基于至少两个资源调度策略标签中每个资源调度策略标签对应的编码值表征的至少两个资源性能指标的指标值，以及至少两个资源性能指标的指标值对应的预设权重，确定每个资源调度策略标签对应的编码值的评分；将各评分进行排序，并将各评分中最大评分对应的编码值确定为目标编码值。

S205，确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源。

具体地，不同虚拟化平台对独立组网，短期无法实现不同资源池之间二层互通；各虚拟化平台对纳管的资源能够独立调度，例如调度器kube-scheduler、nova-scheduler、DRS(Distributed Resource Scheduler，分布式资源调度程序)等，完成对纳管下的资源调度；所有虚拟化平台能够开通的资源和规格，需要先在受理平台完成统一注册，具备全网唯一识别标识；若虚拟化平台开通资源失败，则能够反馈相应的状态码，状态码可以表征资源不足、服务不可用等。

本申请实施例中，云管理平台获取用户的资源调度请求，资源调度请求包括资源筛选策略；云管理平台基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；云管理平台确定至少两个资源调度策略标签对应的编码值；云管理平台基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；云管理平台确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源；如此，云管理平台不对虚拟化平台进行直接监控纳管，对虚拟化平台入侵少，对接部署方便，例如能够对接公有云，从而快速实现虚拟化平台中的资源调度。

在一个实施例中，基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签，包括：

基于资源调度请求中用户请求的资源的相关信息，通过云管理平台的调度单元，进行匹配处理，从云管理平台的资源视图中心存储的资源调度策略标签集合中，确定至少两个资源调度策略标签，至少两个资源调度策略标签中每个资源调度策略标签表征的资源满足所述相关信息；

其中，相关信息包括资源的类型、资源的数量、资源归属的虚拟化平台的平台标签、资源不归属的虚拟化平台的平台标签中至少一项，每个资源调度策略标签包括用户的用户标签、预设虚拟化平台集合中任一虚拟化平台对应的任一网络的网络标签、任一网络中资源的资源性能指标标签中至少一项。

具体地，例如，如图3所示，云管理平台的内部组件包括云管理平台的算力需求统一对外服务接口(CMP-API)、Etcd、云管理平台的调度单元(CMP-Schduler)、云管理平台的资源视图中心(Resource-Center)、策略中心(Policy-Center)、策略接口(Policy-API)、云管理平台的工作器(CMP-Worker)等；其中：

(1)CMP-API：算力需求统一对外服务接口，负责接受上层调度、用户、业务需求，所有提交给CMP-API的需求需要具备以下基本信息：请求的资源的类型、资源的数量、采取的调度策略(调度策略例如成本优先、网络时延最小、权重优先等)、资源限制(例如，是否需要亲和某个虚拟化平台；又例如，在虚拟化平台下的指定VPC，适用于原资源扩容)等。

(2)Etcd：负责云管理平台的各内部组件之间的消息交互、事务性消息的订购和消费等，事务性消息例如待处理的资源需求、待修正的库存数量等。

(3)CMP-Schduler：从Etcd中拉取待处理的资源调度需求，并按照用户的指定策略或默认策略，匹配统一资源视图数据库(统一资源视图中心)中满足要求的条目，进行排序，最终筛选出能够开通服务的最优的虚拟化平台(region)。

(4)Resource-Center：统一资源视图中心，即云管理平台的资源视图中心，维护和存储CMP下纳管各虚拟化平台(region)的信息和虚拟化平台(region)下所有资源的资源信息；region层面包括region层关联的所有的policy ID(资源调度策略标签)，即policy ID集合，一个policy ID(资源调度策略标签)是多个标签的集合，例如，一个policy ID包括多个标签，多个标签例如网络ID(网络标签)、custom ID(用户标签)、其他用于筛选region所需的ID(例如带宽、时延等)；一个用户对应多个region，多个region中每个region对应多个网络；用户的资源需求指令(例如带宽40M，时延0.5秒的网络)转换为多个policy ID，将多个policy ID中每个policy ID的多个标签进行加权处理，得到每个policy ID的分数；将分数最高的policy ID对应的资源(带宽40M，时延0.5秒的网络)提供给用户；资源信息包括可开通的资源唯一识别号、伪库存数、有效期、价格等；有效期过期后，按照预定的周期重新更新伪库存数量为9999(库存为0不自动更新)，并更新一次有效期，有效期长度支持按照region自定义，资源库存数为0代表该region无法提供对应的资源，库存数为1代表region提供这类资源但已无库存，库存数为2代表该资源库存小于2，以此类推。

(5)Policy-Center：保存所有资源和虚拟化平台(region)的policy ID(policyID是策略的唯一识别编码)的policy ID值，其中包括CMP内部的policy ID值、第三方及用户自定义的policy ID值等；CMP-Schduler将依据用户指定的资源筛选策略，例如，取最大(例如最大带宽)、取最小(例如最小带宽)、完全匹配(例如，用户之前使用region1下的网络2的两台服务器，现在有3台服务器的需求，则继续调用region1下的网络2的另外3台服务器)、部分匹配等策略；policy ID值可以是数值或字符串(例如，地点南京带宽40M时延0.5秒)，若值为字符串则不支持取最大或最小等策略，参考资源和region在Policy-Center的ID值，最终得出排序。

(6)Policy-API：负责拉取或接收第三方和客户自定义的Policy ID信息，包括参数的唯一识别ID(例如人脸识别参数)、虚拟化平台(region)、对应的资源类型(可选，例如服务器)、参数名称(例如人脸识别参数的名称)、值、有效期(例如更新频率)等。

(7)CMP-Worker：负责消费消息队列中经过CMP-Schduler调度完成后的资源开通任务，并返回对应云平台(虚拟化平台)的最终开通状态和返回参数。

如图3所示，云管理平台的外部组件包括虚拟化平台的对外服务接口(Openstack/K8s-api)、虚拟化平台内部的资源调度器(XX-XXX-schduler)、第三方或客户自定义策略组件(Customer-Policy)等，其中：

(1)Openstack/K8s-api：虚拟化平台的对外服务接口，接受资源开通信息，进行虚拟化平台(region)内部资源开通。

(2)XX-XXX-schduler：虚拟化平台内部的资源调度器，负责该虚拟化平台内部的资源调度。

(3)Customer-Policy：第三方或客户自定义策略组件，负责引入外部策略，并周期性的对策略赋值。

在一个实施例中，采用默认乐观的机制，先将下层资源池(虚拟化平台管理的资源池)可用的服务类别进行统一的记录，如资源池A能够开通服务1、服务2、服务3和服务4，资源池B能够开通服务2、服务3、服务4和服务5，默认服务在各个资源池都一定可用的，库存为9999(例如，可以提供9999台服务器资源)；在此基础上对资源池级别进行特定的标识，标识例如网络性能、优先级、区域等，一个资源池可以有多个标识，多个标识例如网络性能(例如延时指标)、优先级(例如优先级A)、区域(例如武汉)等；如此，实现多因子(多个标识)筛选，将筛选后的最优解提交给底层资源池(例如资源池A)进行资源开通。

若由于服务对应的资源不足开通失败，则将对应库存(库存的资源)修改为此请求的数量，如开通3个服务2(例如一个服务2对应的资源为3台服务器)，资源不足开通失败，则对应库存修正为3(表示小于3，即只能开通2个服务2对应的资源)，且更新有效期，即表示在有效期内，高于或等于3个服务2的请求，不必再调度给A；直至有效期过期，重新将库存修正为默认的9999。重新接受调度，以便有新的服务2类型的资源释放回A；库存为1表示：有服务无库存；库存为0表示：无服务。

对多个资源池之间资源实现调度，采用乐观的模糊数学模型，定期对服务可用数更新为9999，通过少量试错来避免对底层资源的入侵，最终达到调度的目的，这种方式支持对接公有云。

在一个实施例中，确定至少两个资源调度策略标签对应的编码值，包括：

通过云管理平台的调度单元，从云管理平台的策略中心单元存储的编码值集合中调用至少两个资源调度策略标签对应的编码值，至少两个资源调度策略标签中每个资源调度策略标签对应的编码值的类型为数值、字符串中任一项。

具体地，例如，policy ID值(资源调度策略标签对应的编码值)可以是数值或字符串，字符串例如，地点南京带宽40M时延0.5秒。

在一个实施例中，基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值，包括：

若资源筛选策略包括将任一资源性能指标的指标值为最大的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最大指标值对应的编码值确定为目标编码值；

若资源筛选策略包括将任一资源性能指标的指标值为最小的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最小指标值对应的编码值确定为目标编码值。

具体地，资源筛选策略例如，取最大(例如最大带宽)、取最小(例如最小带宽)、完全匹配(例如，用户之前使用region1下的网络2的两台服务器，现在有3台服务器的需求，则继续调用region1下的网络2的另外3台服务器)、部分匹配等策略。

例如，若资源筛选策略包括将最大带宽的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的带宽进行排序，并将最大带宽对应的编码值确定为目标编码值；

例如，若资源筛选策略包括将最小带宽的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的带宽进行排序，并将最小带宽对应的编码值确定为目标编码值。

在一个实施例中，基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值，包括：

基于至少两个资源调度策略标签中每个资源调度策略标签对应的编码值表征的至少两个资源性能指标的指标值，以及至少两个资源性能指标的指标值对应的预设权重，确定每个资源调度策略标签对应的编码值的评分；

将各评分进行排序，并将各评分中最大评分对应的编码值确定为目标编码值。

具体地，例如，基于两个资源性能指标(带宽和延时指标)的指标值，以及至少两个资源性能指标的指标值对应的预设权重，确定每个资源调度策略标签对应的编码值的评分；将各评分进行排序，并将各评分中最大评分对应的编码值确定为目标编码值。

在一个实施例中，通过定义policy ID并赋值，配合policy ID的筛选方式(取最大、最小、完全匹配、部分匹配等)，一种因子(例如权重)对应一个唯一policy ID，一种policy ID对应多个资源(例如regionA、regionB)，通过对多个资源policy ID赋值(不同资源对应不同权重)，达到按照一定策略择优的目的。注册某个policy ID的主体，同时能够对policy ID绑定的所有资源policy ID值进行更新，实现动态的筛选。主体也可以是外部主体，实现外部策略的融合。

在一个实施例中，在获取用户的资源调度请求之后，还包括：

若确定预设的资源调度策略标签集合中没有资源调度策略标签满足资源调度请求，则将资源调度请求上报给级联云管理平台，以使级联云管理平台将资源调度请求发送给其他云管理平台进行资源调度，级联云管理平台为云管理平台和其他云管理平台的上一级管理系统。

具体地，例如，如图4所示，在级联场景下，级联CMP数据库中保存的是被级联CMP的资源和数量情况，级联CMP和被级联CMP的工作原理、实现机制相同，但级联CMP不纳管云平台，只做调度转发和管理；被级联CMP如本地无可调度资源，可将请求上报给级联CMP，由级联CMP根据CMP层资源视图决定被级联CMP是否能够进行开通，并对被级联CMP进行资源筛选和排序后，择优交给被级联CMP继续调度开通。

在一个实施例中，例如，如图4所示，通过将统一资源视图的数据，原对应虚拟化平台(region)节点的字段，修改为级联CMP，将调度的对象由虚拟化平台(region)变更为被级联CMP；如此，实现了上下级的级联效果，实现更广范围内的跨多个云管理平台的资源调度。

应用本申请实施例，至少具有如下有益效果：

云管理平台不对虚拟化平台进行直接监控纳管，对虚拟化平台入侵少，对接部署方便，例如能够对接公有云，从而快速实现虚拟化平台中的资源调度。

为了更好的理解本申请实施例所提供的方法，下面结合具体应用场景的示例对本申请实施例的方案进行进一步说明。

在一个实施例中，实现用户动态资源调度，用户只需要提交业务需求设置资源偏好、由CMP调度系统根据现有资源分布情况和匹配的调度策略，为客户选择相应的虚拟化平台开通服务。

在一个实施例中，搭建中小型资源调度平台，面向中小型多云多管理平台场景，通过CMP和级联CMP实现中小范围内的算力资源调度和算力运营。

在一个实施例中，嵌入算力网络，补充算网大脑，嵌入算力大脑，作为区域模块能够独立完成区域内的一部分调度任务，降低调度中心大脑的工作压力。

在一个实施例中，实现融合调度，通过Policy-API支持第三方或自定义调度策略，通过API提供外部调度因子的值、更新频率、匹配策略等信息，就可以融入到CMP-schduler中实现多因子的融合调度。

在一个实施例中，资源调度的评估关键指标包括单位时间调度命中率、单次调度时间等；其中，单位时间调度命中率的计算公式(1)和单次调度时间的计算公式(2)如下所示：

单位时间调度命中率＝M×1/n 公式(1)

其中，n＝单位时间完成请求实际调度次数，M＝单位时间完成调度请求总数量。

单次调度时间＝调度完成时间-请求发起时间公式(2)

需要说明的是，资源信息有效期越长，调度命中率越高，资源利用率越低；有效设置每个节点资源有效期是平衡命中率和资源利用率的关键。

在一个具体应用场景实施例中，例如多云管理场景，参见图3，示出了一种资源调度方法的处理流程，如图3所示，本申请实施例提供的资源调度方法的处理流程包括如下步骤：

S301，云管理平台通过CMP-API接收外部资源开通请求。

具体地，CMP(Cloud Management Platform，云管理平台)可以是多云管理平台。云管理平台通过CMP-API接收外部资源开通请求，外部资源开通请求例如用户的资源调度请求，外部资源开通请求包括需要开通的资源的类型、资源的数量、选择策略(例如policy ID筛选策略，即policy ID的筛选方式)、资源限制(例如指定或排除某些region)。

S302，云管理平台通过CMP-API向Etcd请求索引加入消息，并将完整请求存入持久化存储。

具体地，云管理平台通过CMP-API将开通请求元数据录入Etcd，并将完整请求存入持久化存储(storge)；Etcd生成事件。

S303，云管理平台通过CMP-Schduler订阅并消费请求事件。

具体地，CMP-Schduler订阅并消费请求事件，根据Resource-Center中记录的各region内资源的类别和伪库存信息，以及用户请求资源限制要求，选出所有符合需求的资源清单；若无符合需求资源，则直接反馈CMP-API平台无可用资源，流程结束。

S304，云管理平台通过Resource-Center获取资源列表和伪库存信息，并获取完整请求。

具体地，CMP-Schduler订阅并消费请求事件，根据Resource-Center中记录的各region内资源的类别和伪库存信息，以及用户请求资源限制要求，选出所有符合需求的资源清单；若无符合需求资源，则直接反馈CMP-API平台无可用资源，流程结束。

S305，云管理平台通过Resource-Center向CMP-Schduler返回符合需求的资源清单。

具体地，CMP-Schduler订阅并消费请求事件，根据Resource-Center中记录的各region内资源的类别和伪库存信息，以及用户请求资源限制要求，选出所有符合需求的资源清单；若无符合需求资源，则直接反馈CMP-API平台无可用资源，流程结束。

S306，云管理平台通过CMP-Schduler向Policy-Center获取对应的policy ID值。

具体地，确认此时资源清单中是否只有一个region符合用户需求，若存在一个region，则转到步骤S311；若存在多个region，则CMP-schduler根据用户策略和系统默认策略，向Policy-Center获取对应policy ID值继续筛选。

S307，云管理平台通过Policy-Center请求失效或实时的Policy ID值。

具体地，Policy-Center根据CMP-schduler请求的Policy ID，查询对应Policy ID有效期内对应的Policy ID值，若本地保存的Policy ID值已超出有效期，则通过Policy-API进行外部(Customer-Policy)获取更新的Policy ID值，并将最新Policy ID值返回给CMP-schduler。

S308，云管理平台通过Customer-Policy获取更新的Policy ID值。

具体地，Policy-Center根据CMP-schduler请求的Policy ID，查询对应Policy ID有效期内对应的Policy ID值，若本地保存的Policy ID值已超出有效期，则通过Policy-API进行外部(Customer-Policy)获取更新的Policy ID值，并将最新Policy ID值返回给CMP-schduler。

S309，云管理平台通过Policy-API将更新的Policy ID值返回给Policy-Center。

具体地，Policy-Center根据CMP-schduler请求的Policy ID，查询对应Policy ID有效期内对应的Policy ID值，若本地保存的Policy ID值已超出有效期，则基于Policy-API，通过外部(Customer-Policy)获取更新的Policy ID值，并将最新Policy ID值返回给CMP-schduler。

S310，云管理平台通过Policy-Center将更新的Policy ID值返回给CMP-schduler。

具体地，Policy-Center根据CMP-schduler请求的Policy ID，查询对应Policy ID有效期内对应的Policy ID值，若本地保存的Policy ID值已超出有效期，则通过Policy-API进行外部(Customer-Policy)获取更新的Policy ID值，并将最新Policy ID值返回给CMP-schduler。

S311，云管理平台通过CMP-schduler生成开通任务。

具体地，CMP-schduler根据资源清单中匹配到的Policy ID值，根据用户或系统策略进行排序；例如，实现权重值(因子1)取最大、网络时延(因子2)最小，选出最优的region资源，生成开通任务并存入Etcd。

S312，云管理平台通过Etcd发送资源开通任务给CMP-Worker。

具体地，CMP-Worker获取资源开通任务，将资源开通请求提交给指定的虚拟化平台进行资源开通，返回开通结果并存入Etcd。

S313，云管理平台通过CMP-Worker将资源开通请求提交给指定的虚拟化平台。

具体地，CMP-Worker获取资源开通任务，将资源开通请求提交给指定的虚拟化平台进行资源开通，返回开通结果并存入Etcd。

S314，云管理平台通过CMP-Worker接收指定的虚拟化平台返回的开通结果。

具体地，CMP-Worker获取资源开通任务，将资源开通请求提交给指定的虚拟化平台进行资源开通，返回开通结果并存入Etcd。

S315，云管理平台通过CMP-Worker发送开通结果给Etcd。

具体地，CMP-Worker获取资源开通任务，将资源开通请求提交给指定的虚拟化平台进行资源开通，返回开通结果并存入Etcd。

S316，云管理平台通过Resource-Center获取开通失败事件，并修正库存和有效期。

具体地，CMP-API从Etcd中获取开通成功事件并最终通知到前端，Resource-Center获取开通失败事件，根据失败原因更新资源信息；若失败信息为服务不可用，则库存改为0(库存为1代表服务可用，但无库存；0为服务不可用，或资源池无此服务)；若失败信息为资源不足，则库存改为开通失败的请求数量，同时更新有效期。将开通失败的region加入请求的资源限制中；避免失败循环，更新请求调度次数。

S317，云管理平台通过CMP-Schduler修正事件，并重新进行事件消费。

具体地，CMP-Schduler重新进行事件消费，进行新一轮可用资源筛选和排序，直至开通成功或无可用资源。

应用本申请实施例，至少具有如下有益效果：

零入侵：调度系统对现网和平台几乎不存在改造需求，能够实现快速的上线，抢占前期市场；支持级联：可通过级联的形式，实现跨CMP之间更大范围的资源调度；策略接口：提供独特的策略注入API，实现外部策略自定义注入和融合调度；统一抽象：抽象底层异构资源，实现各层级的统一资源视图；水平组合扩展：支持水平扩展系统的规模，并支持通过多个系统组合扩展应对更大的调度规模的能力，亦支持对算网能力进行嵌入补充；轻量级：适合中小型、以IaaS(Infrastructure as a Service，基础设施级服务)层为主的调度场景，部署轻量；支持公有云：由于不需要直接监测到底层资源情况，也能够完美对接公有云。

本申请实施例还提供了一种资源调度装置，应用于云管理平台，该资源调度装置的结构示意图如图5所示，资源调度装置80，包括第一处理模块801、第二处理模块802、第三处理模块803、第四处理模块804和第五处理模块805。

第一处理模块801，用于获取用户的资源调度请求，资源调度请求包括资源筛选策略；

第二处理模块802，用于基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；

第三处理模块803，用于确定至少两个资源调度策略标签对应的编码值；

第四处理模块804，用于基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；

第五处理模块805，用于确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给所述虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源。

在一个实施例中，第二处理模块802，具体用于：

基于资源调度请求中用户请求的资源的相关信息，通过云管理平台的调度单元，进行匹配处理，从云管理平台的资源视图中心存储的资源调度策略标签集合中，确定至少两个资源调度策略标签，至少两个资源调度策略标签中每个资源调度策略标签表征的资源满足所述相关信息；

其中，相关信息包括资源的类型、资源的数量、资源归属的虚拟化平台的平台标签、资源不归属的虚拟化平台的平台标签中至少一项，每个资源调度策略标签包括用户的用户标签、预设虚拟化平台集合中任一虚拟化平台对应的任一网络的网络标签、任一网络中资源的资源性能指标标签中至少一项。

在一个实施例中，第三处理模块803，具体用于：

通过云管理平台的调度单元，从云管理平台的策略中心单元存储的编码值集合中调用至少两个资源调度策略标签对应的编码值，至少两个资源调度策略标签中每个资源调度策略标签对应的编码值的类型为数值、字符串中任一项。

在一个实施例中，第四处理模块804，具体用于：

若资源筛选策略包括将任一资源性能指标的指标值为最大的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最大指标值对应的编码值确定为目标编码值；

若资源筛选策略包括将任一资源性能指标的指标值为最小的资源作为目标资源，则将至少两个资源调度策略标签对应的编码值分别表征的任一资源性能指标的指标值进行排序，并将各指标值中最小指标值对应的编码值确定为目标编码值。

在一个实施例中，第四处理模块804，具体用于：

基于至少两个资源调度策略标签中每个资源调度策略标签对应的编码值表征的至少两个资源性能指标的指标值，以及至少两个资源性能指标的指标值对应的预设权重，确定每个资源调度策略标签对应的编码值的评分；

将各评分进行排序，并将各评分中最大评分对应的编码值确定为目标编码值。

在一个实施例中，第一处理模块801，还用于：

若确定预设的资源调度策略标签集合中没有资源调度策略标签满足资源调度请求，则将资源调度请求上报给级联云管理平台，以使级联云管理平台将资源调度请求发送给其他云管理平台进行资源调度，级联云管理平台为云管理平台和其他云管理平台的上一级管理系统。

应用本申请实施例，至少具有如下有益效果：

云管理平台获取用户的资源调度请求，资源调度请求包括资源筛选策略；云管理平台基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；云管理平台确定至少两个资源调度策略标签对应的编码值；云管理平台基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；云管理平台确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源；如此，云管理平台不对虚拟化平台进行直接监控纳管，对虚拟化平台入侵少，对接部署方便，例如能够对接公有云，从而快速实现虚拟化平台中的资源调度。

本申请实施例还提供了一种电子设备，该电子设备的结构示意图如图6所示，图6所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

其中，电子设备包括但不限于：服务器等。

应用本申请实施例，至少具有如下有益效果：

云管理平台获取用户的资源调度请求，资源调度请求包括资源筛选策略；云管理平台基于资源调度请求，从预设的资源调度策略标签集合中确定至少两个资源调度策略标签；云管理平台确定至少两个资源调度策略标签对应的编码值；云管理平台基于资源筛选策略和至少两个资源调度策略标签对应的编码值，进行排序处理，确定目标编码值；云管理平台确定目标编码值对应的虚拟化平台中的目标资源，并发送资源开通请求给虚拟化平台，资源开通请求用于指示虚拟化平台向用户开通目标资源；如此，云管理平台不对虚拟化平台进行直接监控纳管，对虚拟化平台入侵少，对接部署方便，例如能够对接公有云，从而快速实现虚拟化平台中的资源调度。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

基于与本申请实施例提供的方法相同的原理，本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述本申请任一可选实施例中提供的方法。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。