一种资源申请方法、系统及电子设备和存储介质

本申请涉及云计算技术领域，更具体地说，涉及一种资源申请方法、系统及一种电子设备和一种计算机可读存储介质。

OpenStack是目前最流行的开源云平台，其对外提供了一套标准的RESTAPI，用于管理整个云平台，包括各类资源的申请和删除等，比如虚拟机、卷、网络等。目前多数第三方应用平台是基于OpenStack进行开发的，但是由于OpenStack中各个资源的申请是基于单独的接口实现的，例如，若想申请一个同时具备卷作为数据盘、浮动IP访问外部网络的虚拟机，就需要调用者调用至少五次对应的接口才能完成本次资源申请，包括申请虚拟机、申请卷、申请浮动IP、挂载卷、挂载浮动IP。上述调用过程对于用户来说比较繁琐，而且需要在查询前置条件的资源申请成功后才能进行后续操作，无疑增加了用户的负担，耗费时间成本和人力成本。

本申请的目的在于提供一种资源申请方法、系统及一种电子设备和一种计算机可读存储介质，降低了用户的使用复杂度，减少了人力和时间成本。

为实现上述目的，本申请提供了一种资源申请方法，包括：

获取用于申请多个目标资源的请求包；

对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务，并确定所述多个目标资源的资源参数；

确定所述多个目标资源的资源申请顺序；

基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。

可选的，所述基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务，包括：

利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求；

利用所述子请求调用所述当前目标资源对应的接口，进行所述当前目标资源的申请；

监测到所述当前目标资源申请成功之后，基于所述资源申请顺序确定所述当前目标资源的下一目标资源；

将所述下一目标资源确定为所述当前目标资源，并返回利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求的步骤，直至完成所述请求任务。

可选的，所述利用所述子请求调用所述当前目标资源对应的接口，进行所述当前目标资源的申请之后，还包括：

若监测到所述当前目标资源申请失败，则对所述当前目标资源进行重新申请；

若重新申请次数超过预设次数，则根据当前请求任务进度进行回滚。

可选的，对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务之后，还包括：

将所述请求任务存放至任务队列中，并将所述请求包存放至请求队列中；

向所述请求包的发起方下发表征请求接收成功的反馈信息；所述反馈信息包括所述请求队列中所述请求包对应的请求标识信息，以使所述发起方根据所述请求标识信息查询所述请求包的处理过程。

可选的，所述任务队列用于保存所述请求任务的标识信息及其对应的请求标识信息；所述请求队列用于保存所述请求标识信息、每个请求包对应的请求任务数量、执行成功的第一任务数量、执行失败的第二任务数量以及执行失败的描述信息。

可选的，将所述请求任务存放至任务队列中之前，还包括：

对所述请求包的发起方进行令牌验证；

若令牌验证未通过，则返回令牌失效信息或失败提示信息；

若令牌验证通过，则对所述请求包进行参数合法性验证，并在合法性验证通过后启动将所述请求任务存放至任务队列中的步骤。

为实现上述目的，本申请提供了一种资源申请系统，包括：

请求获取模块，用于获取用于申请多个目标资源的请求包；

请求解析模块，用于对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务，并确定所述多个目标资源的资源参数；

顺序确定模块，用于确定所述多个目标资源的资源申请顺序；

自动调用模块，用于基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。

可选的，所述自动调用模块，包括：

请求生成单元，用于利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求；

接口调用单元，用于利用所述子请求调用所述当前目标资源对应的接口，进行所述当前目标资源的申请；

第一确定单元，用于监测到所述当前目标资源申请成功之后，基于所述资源申请顺序确定所述当前目标资源的下一目标资源；

第二确定单元，用于将所述下一目标资源确定为所述当前目标资源，并返回执行所述请求生成单元的工作流程，直至完成所述请求任务。

为实现上述目的，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述公开的任一种资源申请方法的步骤。

为实现上述目的，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述公开的任一种资源申请方法的步骤。

通过以上方案可知，本申请提供的一种资源申请方法，包括：获取用于申请多个目标资源的请求包；对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务，并确定所述多个目标资源的资源参数；确定所述多个目标资源的资源申请顺序；基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。由上可知，本申请在获取到用于申请多个目标资源的请求包后，能够确定该请求包的请求任务中针对多个目标资源的资源参数，进而利用资源参数自动顺序调用每个目标资源对应的接口，使用户发送一次请求就可实现多个资源的申请，无需手动调用多个资源对应的多个接口，降低了用户的使用复杂度，减少了人力和时间成本。

本申请还公开了一种资源申请系统及一种电子设备和一种计算机可读存储介质，同样能实现上述技术效果。

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

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种资源申请方法的流程图；

图2为本申请实施例公开的一种资源申请方法中步骤S104的细化流程图；

图3为本申请实施例公开的一种资源申请系统的结构图；

图4为本申请实施例公开的一种电子设备的结构图；

图5为本申请实施例公开的另一种电子设备的结构图。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，由于OpenStack中各个资源的申请是基于单独的接口实现的，若想同时申请多个资源，则需要用户手动调用多个资源对应的多个接口，调用过程对于用户来说比较繁琐，而且需要在查询前置条件的资源申请成功后才能进行后续操作，无疑增加了用户的负担，耗费时间成本和人力成本。

因此，本申请实施例公开了一种资源申请方法，降低了用户的使用复杂度，减少了人力和时间成本。

参见图1所示，本申请实施例公开的一种资源申请方法包括：

S101：获取用于申请多个目标资源的请求包；

本实施例中，获取用户发送的用于申请多个目标资源的请求包，目标资源可以具体为虚拟机、网络、数据卷等。

S102：对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务，并确定所述多个目标资源的资源参数；

在本步骤中，对上述用户发送的请求包进行解析，得到请求包中的对于多个目标资源进行申请的请求任务，进而确定出请求任务中用户针对每个目标资源设定的资源参数。可以理解的是，本实施例的请求中可以包含一个或多个请求任务，即能够并发进行多个请求任务的申请。

具体地，本实施例在对请求包进行解析，得到请求包中对多个目标资源的请求任务之后，还可以将该请求包中所有的请求任务存放至任务队列中，并将请求包存放至请求队列中。其中，任务队列用于保存请求任务的标识信息及其对应的请求标识信息；请求队列用于保存请求标识信息、每个请求包对应的请求任务数量、执行成功的第一任务数量、执行失败的第二任务数量以及执行失败的描述信息。本实施例可以对每个请求任务进行监测，在任务执行完成后根据执行结果更新请求队列中的任务数量，若执行成功则第一任务数量加一，若执行失败则第二任务数量加一。可以理解的是，若第一任务数量和第二任务数量的和等于该请求包中请求任务的总数量时，表征该请求包对应的所有请求任务已执行完成。

本实施例中，在将所有请求任务存放至任务队列中之前，还可以对请求包的发起方进行令牌验证；若令牌验证未通过，则返回令牌失效信息或失败提示信息；若令牌验证通过，则对该请求包进行参数合法性验证，并在合法性验证通过后启动将请求任务存放至任务队列中的步骤。

可以理解的是，本实施例在将请求包存放至请求队列中之后，可以向请求包的发起方下发表征请求接收成功的反馈信息；其中，反馈信息可以包括请求队列中所述请求包对应的请求标识信息，以使发起方能够根据请求标识信息查询对应请求包的处理过程。

S103：确定所述多个目标资源的资源申请顺序；

需要指出的是，每个请求任务用于申请多个目标资源，对于目标资源的申请需要基于一定的顺序完成。

S104：基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。

可以理解的是，本实施例在确定资源参数以及每个请求任务中多个目标资源的资源申请顺序之后，将基于资源申请顺序利用上述资源参数依次自动调用每个目标资源对应的接口。其中，在上述调用过程中，需要在确保资源申请顺序中前一资源申请成功之后才能进行当前接口的调用。

具体地，如图2所示，上述步骤S104的细化流程可以包括：

S1041：利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求；

S1042：利用所述子请求调用所述当前目标资源对应的接口，进行所述当前目标资源的申请；

S1043：监测到所述当前目标资源申请成功之后，基于所述资源申请顺序确定所述当前目标资源的下一目标资源；

S1044：将所述下一目标资源确定为所述当前目标资源，并返回利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求的步骤，直至完成所述请求任务。

本实施例中，在利用子请求调用当前目标资源对应的接口，进行当前目标资源的申请之后，若监测到当前目标资源申请失败，还可以进一步对当前目标资源进行重新申请；若重新申请次数超过预设次数后仍未申请成功，则根据当前请求任务进度进行回滚。

通过以上方案可知，本申请提供的一种资源申请方法，包括：获取用于申请多个目标资源的请求包；对所述请求包进行解析，得到所述请求包中对所述多个目标资源的请求任务，并确定所述多个目标资源的资源参数；确定所述多个目标资源的资源申请顺序；基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。由上可知，本申请在获取到用于申请多个目标资源的请求包后，能够确定该请求包的请求任务中针对多个目标资源的资源参数，进而利用资源参数自动顺序调用每个目标资源对应的接口，使用户发送一次请求就可实现多个资源的申请，无需手动调用多个资源对应的多个接口，降低了用户的使用复杂度，减少了人力和时间成本。

以申请同时具备作为数据盘的数据卷、以及用于访问外部网络的浮动IP的虚拟机为例，本申请实施例公开了一种具体的资源申请方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

当用户请求到达时，首先利用keystone验证对应的令牌是否合法，如果合法则继续进行处理，否则返回令牌失效或者不合法提示信息。

进而对该请求进行参数合法性验证，如必选项是否为空、用户配额是否满足预设条件等，验证通过后将该请求放到任务队列中，其中，每一个组合资源申请任务为一个任务，如果有多个任务，将上述多个任务均添加保存至任务队列中，同时将本次请求放入到请求队列中，用以判断是否所有任务都已经完成。其中，任务队列为hash队列，可以具体包括：任务标识信息、对应的请求标识信息、具体的请求体、申请的虚拟机标识信息、申请的数据卷信息以及申请的浮动IP信息；请求队列为hash队列，可以具体包括：请求的标识信息、请求包含的任务总数、请求中执行成功的任务数量、请求中执行失败的任务数量以及失败的原因描述。

进一步地，本实施例可以返回表示资源申请请求已经接收的反馈信息给调用者，同时返回请求标识信息，用以查询本次申请资源的进度及状态。具体地，本实施例可将申请资源的进度和状态保存记录到数据库中。

在具体实施中，可利用任务线程池定期从任务队列中取出任务进行执行，从具体的请求体中取出创建虚拟机需要的参数，组装生成nova创建虚拟机需要的请求体，调用nova的接口创建虚拟机。其中，Nova是OpenStack所有组件中最重要的一个模块，负责云中虚拟机的管理。需要说明的是，Flavor是nova中重要的模块，Flavor规定了主机的内存大小，cpu大小等，并且可以用来限制虚拟机的一系列参数，相当于一个生产模具，使用同一个Flavor创建出来的虚拟机在规格上基本保持一致。在用户创建虚拟机时，若用户未指定Flavor，则需要根据用户设定的vcpu、ram、root_disk参数重新创建Flavor，用于创建虚拟机。进一步地，将该任务的状态置为创建中，重新放到任务队列末尾。这是由于创建虚拟机需要一段时间，本实施例可以让需要开始创建的任务优先执行。当线程池再次执行到该任务时，将再次检查该任务的进行状态，若仍是虚拟机创建中，则继续将该任务放到任务队列末尾，先执行其他创建任务。

若虚拟机的创建状态为完成，则创建数据卷，把具体的请求体中的数据卷参数拼接生成为调用cinder接口的参数，去创建相应的数据卷。Cinder与Nova均为OpenStack的组件，Cinder具体为Nova中的虚拟机提供块存储服务。由于数据卷的创建初始值是个空白卷，速度较快，本实施例无需将其重新加入到任务队列中去，因为线程切换也需要浪费CPU资源。按照预设时间周期对数据卷的状态进行查询，直至数据卷的状态由创建中更新为创建成功。其中，预设时间周期可根据cinder后端存储速度配置合适的值。等待所有的数据卷创建成功后，再进行数据卷的挂载。在数据卷挂载完成后，调用网络接口去创建浮动IP，并在创建成功后，绑定浮动IP到虚拟机的特定网卡上，在绑定时可根据请求体中设定的映射关系进行绑定。

本实施例中，创建虚拟机、创建数据卷、创建浮动IP、挂载数据盘以及绑定浮动IP的每个过程都对应设置单独的重试机制，即每个过程出错后，都进行重试，如果重试次数超过预设次数，则本次资源申请创建失败，进行回滚操作。由于不同OpenStack环境可能会由于硬件和网络不同导致不同的延迟，预设次数以及重试间隔时长可根据具体实施情况进行设置。在进行回滚操作时，首先查询当前资源申请的进度，即哪个过程出现了错误，根据查询结果依次解绑浮动IP，删除浮动IP，卸载数据盘，删除数据盘，最后删除虚拟机，完成回滚。

在任意一个资源申请任务执行完后，需要更新请求队列中该请求对应的内容。如果任务执行成功，则执行成功的任务数量加一，否则执行失败的任务数量加一，并添加失败原因，不同任务可以利用分号进行分割。当执行成功的任务数量与执行失败的任务数量的总和等于当前请求的任务总数时，本次请求结束，根据任务的执行结果，更新该请求对应的据库表记录。

本实施例中，用户可以调用原生OpenStack的接口查询到所有的组合资源，不会影响原生接口，而且该方法实现的装置可以具体部署在OpenStack各个组件的内部网络中，调用速度快，而且也更安全。

具体地，本实施例可以将本申请提供的资源申请方法具体实现为微服务，可以将该微服务部署在OpenStack的控制节点上，也可以部署在单独的服务器上，对外提供申请资源的API。也即，本申请提供的资源申请方法，可以使调用者调用一次接口就可以获取想要的计算、存储和网络资源，极大地简化了用户的使用流程，且该方法对应的微服务与OpenStack部署在相同的内网区域，内部调用时间延迟很短，有效减少了整体创建时间。同时，用户无需研究如何使用OpenStack各个资源的接口如何使用，只需要关注自身的业务逻辑，显著提高了开发应用的效率。

下面对本申请实施例提供的一种资源申请系统进行介绍，下文描述的一种资源申请系统与上文描述的一种资源申请方法可以相互参照。

参见图3所示，本申请实施例提供的一种资源申请系统包括：

请求获取模块11，用于获取用于申请多个目标资源的请求包；

请求解析模块12，用于对所述请求包进行解析，得到所述请求包中的请求任务，并确定所述多个目标资源的资源参数；

顺序确定模块13，用于确定所述多个目标资源的资源申请顺序；

自动调用模块14，用于基于所述资源申请顺序利用所述资源参数自动调用每个所述目标资源对应的接口，完成所述请求任务。

在上述实施例的基础上，作为一种优选实施方式，所述自动调用模块14可以包括：

请求生成单元，用于利用当前目标资源的资源参数生成用于申请所述当前目标资源的子请求；

接口调用单元，用于利用所述子请求调用所述当前目标资源对应的接口，进行所述当前目标资源的申请；

第一确定单元，用于监测到所述当前目标资源申请成功之后，基于所述资源申请顺序确定所述当前目标资源的下一目标资源；

第二确定单元，用于将所述下一目标资源确定为所述当前目标资源，并返回执行所述请求生成单元的工作流程，直至完成所述请求任务。

本申请还提供了一种电子设备，参见图4所示，本申请实施例提供的一种电子设备包括：

存储器100，用于存储计算机程序；

处理器200，用于执行所述计算机程序时可以实现上述实施例所提供的步骤。

具体的，存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令，该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200在一些实施例中可以是一中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，为电子设备提供计算和控制能力，执行所述存储器100中保存的计算机程序时，可以实现前述实施例公开的资源申请方法的步骤。

在上述实施例的基础上，作为优选实施方式，参见图5所示，所述电子设备还包括：

输入接口300，与处理器200相连，用于获取外部导入的计算机程序、参数和指令，经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连，接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是键盘、触控板或鼠标等。

显示单元400，与处理器200相连，用于显示处理器200处理的数据以及用于显示可视化的用户界面。该显示单元400可以为LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。

网络端口500，与处理器200相连，用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术，如移动高清链接技术(MHL)、通用串行总线(USB)、高清多媒体接口(HDMI)、无线保真技术(WiFi)、蓝牙通信技术、低功耗蓝牙通信技术、基于IEEE802.11s的通信技术等。

图5仅示出了具有组件100-500的电子设备，本领域技术人员可以理解的是，图5示出的结构并不构成对电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

本申请还提供了一种计算机可读存储介质，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述实施例公开的资源申请方法的步骤。

本申请在获取到用于申请多个目标资源的请求包后，能够确定该请求包的请求任务中针对多个目标资源的资源参数，进而利用资源参数自动顺序调用每个目标资源对应的接口，使用户发送一次请求就可实现多个资源的申请，无需手动调用多个资源对应的多个接口，降低了用户的使用复杂度，减少了人力和时间成本。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。