CN109558446B - 作业请求方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种作业请求方法、装置、电子设备及存储介质，资源调度平台由至少一个资源队列构成，每个资源队列对应一个租户，不同资源队列对应的租户不同，每个资源队列其仅用于处理与其对应的租户发送的作业请求；相应的，应用管理平台在接收到目标租户发送的作业请求后，可以确定资源调度平台中与该目标租户唯一对应的目标资源队列，进而由该目标资源队列处理该目标租户发送的该作业请求，得到该作业请求的请求结果并返回给该目标租户。基于此，应用管理平台可以将不同租户的作业请求发送到资源调度平台中不同的资源队列进行处理，实现了对不同租户之间计算资源的隔离。

Description

作业请求方法、装置、电子设备及存储介质

技术领域

本发明属于大数据领域，涉及计算机软件技术，更具体地说，涉及一种作业请求方法、装置、电子设备及存储介质。

背景技术

大数据时代，随着海量数据的产生，各种大数据处理框架应运而生，Apache Spark即是其中的佼佼者。Apache Spark提供多种运行模式，底层兼容不同资源调度平台。在Sparkon YARN模式下对接Apache Hadoop YARN资源调度平台，通过向Apache Hadoop YARN资源调度平台请求计算资源，解决了单台服务器计算资源的限制。

然而，虽然基于Apache Spark开发的应用的运行选择SparkonYARN模式可以解决单台服务器计算资源的限制，但是，仍然存在应用逐渐被应用于各类政府和企业的数据***时，不能满足多租户需求的问题。例如基于Apache Spark开发的应用的运行选择SparkonYARN模式时，共用一个Apache Hadoop YARN资源调度平台，企业不同部门间无法做到计算资源的隔离。

发明内容

有鉴于此，本发明提供一种作业请求方法、装置、电子设备及存储介质，以实现不同租户之间计算资源的隔离。

技术方案如下：

一种作业请求方法，包括：

应用管理平台接收目标租户发送的作业请求；

所述应用管理平台确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，所述资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个所述资源队列仅用于处理与其对应的租户发送的作业请求；

所述应用管理平台向所述资源调度平台发送指示所述目标资源队列的所述作业请求，接收所述目标资源队列返回的所述作业请求的请求结果，并将所述请求结果返回给所述目标租户。

优选的，所述应用管理平台包括分别与每个所述租户对应的多个应用实例，所述应用管理平台接收目标租户发送的作业请求，包括：

应用管理平台中的目标应用实例接收目标租户发送的作业请求，所述目标应用实例为与所述目标租户对应的用于处理所述作业请求的应用实例。

优选的，所述应用管理平台包括分别与每个租户对应的多个应用实例管理单元，每个所述应用实例管理单元中包括一个应用实例，所述应用管理平台中的目标应用实例接收目标租户发送的作业请求，包括：

所述应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问所述目标应用实例管理单元中的目标应用实例，以便所述目标应用实例接收所述作业请求。

优选的，所述应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问所述目标应用实例管理单元中的目标应用实例，包括：

所述应用管理平台接收目标租户发送的作业请求；

所述应用管理平台从本地存储的所述目标租户的各个应用实例管理单元的地址中，获取用于处理所述作业请求的目标应用实例管理单元的地址；

所述应用管理平台中的目标应用实例管理单元接收所述应用管理平台基于所获取的地址发送的所述作业请求，访问所述目标应用实例管理单元中的目标应用实例。

优选的，所述应用管理平台确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，包括：

所述应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，所确定的资源队列为所述资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列。

优选的，所述应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，包括：

所述应用管理平台中的目标应用实例获取其所属的容器中挂载的配置文件；

所述目标应用实例将所述配置文件指示的资源队列确定为预先设置的与其关联的资源队列。

优选的，还包括：

所述应用管理平台监控所述应用管理平台中各个应用实例的状态信息；

所述应用管理平台根据各个所述应用实例的状态信息以及每个所述应用实例对应的租户，得到分别与每个租户对应的各个应用实例的状态信息。

优选的，该方法还包括：

所述应用管理平台获取当前的集群资源分配信息，所述应用管理平台和所述资源调度平台运行于包括多个节点的集群，所述集群资源分配信息指示所述应用管理平台和所述资源调度平台对所述集群资源的分配情况；

基于当前的集群资源分配信息，对所述应用管理平台和所述资源调度平台对所述集群资源的分配情况进行平衡管理。

一种作业请求装置，包括：

作业请求接收单元，用于接收目标租户发送的作业请求；

目标资源队列确定单元，用于确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，所述资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个所述资源队列仅用于处理与其对应的租户发送的作业请求；

作业请求单元，用于向所述资源调度平台发送指示所述目标资源队列的所述作业请求，接收所述目标资源队列返回的所述作业请求的请求结果，并将所述请求结果返回给所述目标租户。

一种电子设备，存储器以及处理器，所述存储器，用于存储程序，所述程序用于实现所述作业请求方法；所述处理器，用于调用并执行所述存储器中存储的程序。

一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行所述作业请求方法。

本申请提供一种作业请求方法、装置、电子设备及存储介质，资源调度平台由至少一个资源队列构成，每个资源队列对应一个租户，不同资源队列对应的租户不同，每个资源队列其仅用于处理与其对应的租户发送的作业请求；相应的，应用管理平台在接收到目标租户发送的作业请求后，可以确定资源调度平台中与该目标租户唯一对应的目标资源队列，进而由该目标资源队列处理该目标租户发送的该作业请求，得到该作业请求的请求结果并返回给该目标租户。基于此，应用管理平台可以将不同租户的作业请求发送到资源调度平台中不同的资源队列进行处理，实现了对不同租户之间计算资源的隔离。

附图说明

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

图1为本申请实施例提供的一种作业请求***的结构示意图；

图2为本申请实施例提供的一种作业请求方法流程图；

图3为本申请实施例提供的一种作业请求方法流程示意图；

图4为本申请实施例提供的一种应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问目标应用实例管理单元中的目标应用实例的方法流程图；

图5为本申请实施例提供的一种作业请求装置的结构示意图；

图6为本申请实施例提供的一种作业请求接收单元的详细结构示意图。

具体实施方式

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

实施例：

图1为本申请实施例提供的一种作业请求***的结构示意图。

如图1所示，该***包括：

应用管理平台1，以及用于与应用管理平台通信连接的资源调度平台2；资源调度平台中包括至少一个资源队列21，每个资源队列21对应一个租户，并且不同的资源队列21的租户不同，资源队列21仅用于处理与其对应的租户发送的作业请求。

在如图1所示的作业请求***的基础上，本申请实施例还提供一种作业请求方法，请参见图2和图3，图2为本申请实施例提供的一种作业请求方法流程图，图3为本申请实施例提供的一种作业请求方法流程示意图。

如图2所示，该作业请求方法包括：

S201、应用管理平台接收目标租户发送的作业请求；

在本申请实施例中，本申请实施例提供的作业请求***可以被不同的租户使用，以接收各个租户发送的作业请求。比如，图3示出了租户A和租户B，租户A可以向作业***发送作业请求，租户B也可以向作业***发送作业请求，具体的，租户A和租户B仅仅是本申请实施例为了便于理解提供的一种实例，实际上本申请并不限于可以向作业请求***发送作业请求的租户的数量，也不限定只有租户A和租户B可以向作业请求***发送作业请求。

在本申请实施例中，在租户A向应用管理平台发送作业请求后，为了便于区分，可以暂时将租户A称为目标租户；相应的，应用管理平台可以接收租户A发送的作业请求。

S202、应用管理平台确定资源调度平台中仅用于处理目标租户发送的作业请求的目标资源队列，资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个资源队列仅用于处理与其对应的租户发送的作业请求；

在本申请实施例中，作业请求***中的资源调度平台中包括多个资源队列，每个资源队列对应一个租户，不同的资源队列对应的租户不同，资源队列仅用于处理与其对应的租户发送的作业请求。

以图3为例，作业请求***可以接收租户A发送的作业请求和租户B发送的作业请求，资源调度平台中可以包括与租户A对应的资源队列(为了便于理解，图3中将租户A对应的资源队列暂称为租户A的资源队列)，和租户B对应的资源队列(为了便于理解，图3中将租户B对应的资源队列暂称为租户B的资源队列)。

若是作业请求***接收到租户C发送的作业请求，而资源调度平台中不包括与租户C对应的资源队列时，租户C发送的作业请求可能存在无法处理的问题。

在本申请实施例中，应用管理平台接收到租户A发送的作业请求(为了便于区分，暂时将该作业请求称为第一作业请求)后，可以确定资源调度平台中仅用于处理租户A发送的作业请求的资源队列(如图3所示，资源调度平台中仅用于处理租户A发送的作业请求的资源队列为租户A的资源队列，此时该租户A的资源队列为目标资源队列)；进而应用管理平台会向资源调度平台发送指示租户A的资源队列的该第一作业请求，以便于资源调度平台中的租户A的资源队列处理该第一作业请求得到该第一作业请求的请求结果并将该请求结果返回给该应用管理平台，相应的，应用管理平台在接收到租户A的资源队列发送的第一作业请求的请求结果后，会将该请求结果返回给租户A。

相应的，若是应用管理平台接收到租户B发送的作业请求(为了便于区分，暂时将该作业请求称为第二作业请求)后，可以确定资源调度平台中仅用于处理该租户B发送的作业请求的租户B的资源队列(此时，该租户B的资源队列为目标资源队列)，以将指示租户B的资源队列的该第二作业请求发送给资源调度平台，以便于资源调度平台中的租户B的资源队列处理第二作业请求，得到第二作业请求的请求结果，并将该请求结果返回给应用管理平台；相应的，应用管理平台在接收到资源该作业请求后，会将该作业请求返回给租户B。

在本申请实施例中，应用管理平台接收目标租户发送的作业请求，并确定资源调度平台中与该目标租户对应的目标资源队列后，将指示该目标资源队列的该作业请求发送给资源调度平台的方式可以为：应用管理平台在接收到目标租户发送的作业请求，并确定资源调度平台中与该目标租户对应的目标资源队列后，可以将用于与该目标资源队列唯一对应的目标资源队列标识添加到该作业请求中，并将添加有目标资源队列标识后的该作业请求发送给资源调度平台，该目标资源队列标识指示该目标资源队列。

S203、应用管理平台向资源调度平台发送指示目标资源队列的作业请求，接收目标资源队列返回的作业请求的请求结果，并将请求结果返回给目标租户。

本申请提供一种作业请求方法，资源调度平台由至少一个资源队列构成，每个资源队列对应一个租户，不同资源队列对应的租户不同，每个资源队列其仅用于处理与其对应的租户发送的作业请求；相应的，应用管理平台在接收到目标租户发送的作业请求后，可以确定资源调度平台中与该目标租户唯一对应的目标资源队列，进而由该目标资源队列处理该目标租户发送的该作业请求，得到该作业请求的请求结果并返回给该目标租户。基于此，应用管理平台可以将不同租户的作业请求发送到资源调度平台中不同的资源队列进行处理，实现了对不同租户之间计算资源的隔离。

为了便于对本申请实施例提供的一种作业请求方法的详细理解，现仍以

图3为例，对本申请实施例提供的一种作业请求方法进行详细说明。

可选的，本申请实施例提供一种作业请求***，该作业请求***由应用管理平台和资源调度平台构成，资源调度平台可以是Apache Hadoop YARN资源调度平台，基于Apache Spark开发的应用可以运行于Apache Hadoop YARN资源调度平台。

其中，作业请求***中的应用管理平台和资源调度平台运行于由多个节点构成的集群中，其中，节点可以为服务器。应用管理平台和资源调度平台均是占用集群中的资源实现运行。

在本申请实施例中，应用管理平台包括分别与每个租户对应的多个应用实例，应用管理平台接收目标租户发送的作业请求，可以包括：应用管理平台中的目标应用实例接收目标租户发送的作业请求，目标应用实例为与目标租户对应的用于处理作业请求的应用实例。

针对每个租户而言，在应用管理平台中可以包括与该租户对应的至少一个应用实例，应用实例仅用于接收与其对应的租户发送的作业请求。目标租户在将作业请求发送给应用管理平台时，可以确定应用管理平台中与该目标租户对应的用于处理该作业请求的目标应用实例，进而将该作业请求发送给应用管理平台中的该目标应用实例。

在本申请实施例中，应用管理平台中的每个应用实例均是位于与该应用实例唯一对应的应用实例管理单元中的，在本申请实施例中，应用实例管理单元可以是应用管理平台中的pod，在本申请实施例中，以应用实例管理单元为pod为例对如图3所示的作业请求***进行详细说明。

应用管理平台可以包括分别与每个租户对应的多个pod，每个pod中包括一个应用实例，相应的，应用管理平台中的目标应用实例接收目标租户发送的作业请求，可以包括：应用管理平台中的目标pod接收目标租户发送的作业请求，访问目标pod中的目标应用实例，以便目标应用实例接收作业请求。

在目标租户需要向应用管理平台发送作业请求时，可以确定应用管理平台中与该目标租户对应的用于处理该作业请求的目标应用实例所属pod，通过将该作业请求发送给应用管理平台中的该目标应用实例所属的pod，进而由该pod将该作业请求发送给该目标应用实例。

图4为本申请实施例提供的一种应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问目标应用实例管理单元中的目标应用实例的方法流程图。

如图4所示，该方法包括：

S401、应用管理平台接收目标租户发送的作业请求；

S402、应用管理平台从本地存储的目标租户的各个应用实例管理单元的地址中，获取用于处理作业请求的目标应用实例管理单元的地址；

S403、应用管理平台中的目标应用实例管理单元接收应用管理平台基于所获取的地址发送的作业请求，访问目标应用实例管理单元中的目标应用实例。

在本申请实施例中，应用管理平台确定资源调度平台中仅用于处理目标租户发送的作业请求的目标资源队列，包括：应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，所确定的资源队列为资源调度平台中仅用于处理目标租户发送的作业请求的目标资源队列。

其中，针对应用管理平台中的每个应用实例，确定与该应用实例对应的租户，资源调度平台中与所确定的租户对应的资源队列便是与该应用实例关联的资源队列。

可选的，应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，包括：应用管理平台中的目标应用实例获取其所属的容器中挂载的配置文件；目标应用实例将配置文件指示的资源队列确定为预先设置的与其关联的资源队列。

为了便于理解，结合图3现从作业请求***的角度对本申请实施例提供的一种作业请求方法的实现过程进行说明。

在本申请实施例中，应用管理平台可以是kubernetes，针对每个租户，在应用管理平台中可以创建该租户的多个pod，每个pod中包括一个应用实例，该应用实例位于其所属的pod中的容器中。

并且，预先按照租户对资源调度平台进行划分，将资源调度平台划分成至少一个资源队列，每个资源队列对应唯一的一个租户。

参见图3本申请实施例提供的一种作业请求方法如下：

如图3所示，该方法包括：

S301、应用管理平台中的pod接收目标租户发送的作业请求，访问pod中的目标应用实例；

在本申请实施例中，租户可以登陆终端设备，通过终端设备向应用管理平台中的pod发送作业请求，以访问pod中的应用实例。

租户登陆终端设备，向终端设备发送作业请求，终端设备从本地存储的该租户的各个pod的地址中，获取用于处理该作业请求的pod的地址，在获取到地址后，终端设备基于获取到的地址向应用管理平台中的该租户的用于处理该作业请求的pod发送作业请求。

针对每个租户而言，应用管理平台中包括该租户的多个pod，每个pod中包括一个应用实例，一个租户的多个pod中的各个应用实例互不相同。

不同的应用实例用于处理不同业务类型的作业请求；当终端设备接收到租户发送的作业请求后，会确定该作业请求的业务类型，进而从应用管理平台的该租户的多个应用实例中确定用于处理该业务类型的应用实例，并得到所确定的该应用实例所属的pod，进而得到本地存储的该pod的地址，以基于该地址将作业请求发送至应用管理平台中的该pod。

在本申请实施例中，应用管理平台中的pod接收到作业请求后，会访问其中的应用实例。其中，访问应用实例可以是将作业请求发送给应用实例。

S302、目标应用实例获取与目标应用实例关联的资源队列标识，并向资源调度平台发送携带该资源队列标识的该作业请求，资源队列标识指示资源调度平台中与目标租户对应的目标资源队列；

在本申请实施例中，将应用实例运行于应用管理平台中的方法可以为：创建Kubernetes Configmap和Secret，内含应用实例的配置信息，配置信息包括资源调度平台的访问信息，资源调度平台的访问信息包括资源调度平台的地址以及应用实例所属租户在资源调度平台中的资源队列的资源队列标识；创建Kubernetes Deployment，定义Docker化的应用实例的容器编排，并将其中定义的Configmap和Secret以文件形式挂载进容器；其中，挂载进容器中的Configmap和Secret可以认为是配置文件；定义Kubernetes Service，作为外部访问该应用实例的入口。

进一步的，配置信息中还可以包括认证所用配置、应用运行参数等等，在此不做限定。

相应的，访问目标应用实例包括：基于目标应用实例的入口访问目标应用实例，目标应用实例的入口是预先定义的目标应用实例的Kubernetes Service。

在本申请实施例中，目标应用实例获取与目标应用实例关联的资源队列标识，包括：目标应用实例获取其所属的容器中挂载的配置文件，配置文件是创建的该目标应用实例的Kubernetes Configmap和Secret文件；获取配置文件中的资源队列标识作为与目标应用实例关联的资源队列标识。

其中，获取目标应用实例所属的容器中挂载的Kubernetes Configmap和Secret文件，并获取Kubernetes Configmap和Secret文件中的配置信息，进而获取配置信息中的资源队列标识，将该资源队列标识作为获取到的与目标应用实例关联的资源队列标识。

S303、资源调度平台基于资源队列标识将该作业请求发送至目标资源队列；

可选的，目标应用实例在获取到与该目标应用实例关联的资源队列标识后，可以将在其接收到的作业请求中携带上该资源队列标识，并将携带该资源队列标识的该作业请求发送给资源调度平台。

资源调度平台被划分成多个资源队列，不同的资源队列对应不同的租户；资源调度平台中每个资源队列有唯一的资源队列标识；当资源调度平台接收到目标应用实例发送的作业请求后，将该作业请求发送给该作业请求携带的资源队列标识指示的资源队列(即，目标资源队列)，以便于该资源队列接收到该作业请求后，处理该作业请求得到请求结果。

S304、目标应用实例接收目标资源队列返回的作业请求的请求结果，并将请求结果返回给目标租户。

如图3所示，本申请实施例中，资源调度平台接收到作业请求后，可以处理该作业请求得到请求结果；并将该请求结果返回给用于发送该作业请求的目标应用实例；进而由该目标应用实例将该请求结果返回给发送该作业请求的目标租户。

进一步的，本申请实施例提供的一种应用管理平台还可以监控该应用管理平台中各个应用实例的状态信息，并根据各个应用实例的状态信息以及每个应用实例对应的租户，得到分别与每个租户对应的各个应用实例的状态信息。

在本申请实施例中，应用管理平台还用于对其中的每个应用实例的KubernetesDeployment、Service、Configmap以及Secret中的任意一项或多项进行监控，以得到每个应用实例的状态信息。

其中，应用管理平台可以针对其中的每个应用实例而言，监控该应用实例的Kubernetes Deployment、Service、Configmap以及Secret中的任意一项或多项，以得到该应用实例的状态信息。

应用管理平台中包括一个租户的多个应用实例，针对每个租户而言，将该租户的各个应用实例的状态信息进行汇总，便可得到该租户的状态信息。该租户的状态信息可以为该租户在应用管理平台中的各个应用实例的状态信息。

进一步的，应用管理平台可以向每个租户返回与其对应的状态信息。

在本申请实施例中，应用实例的状态信息可以是应用实例的运行状态信息，有关状态信息的具体内容，发明人可根据自己的需求进行设置，在此不做限定。

在本申请实施例中，应用管理平台接收租户发送的状态信息查看请求，向该租户返回该租户的在应用管理平台中的各个应用实例的状态信息。即，针对每个租户而言，应用管理平台可以接收该租户发送的状态信息查看请求，并确定应用管理平台中该租户的各个应用实例的状态信息，进而将所确定的状态信息返回给该租户。

本申请通过对应用管理平台中每个租户对应的各个应用实例的状态信息的监控，不仅可以基于监控结果实现对应用管理平台中应用实例的维护，还可以便于租户了解与其对应的应用实例的状态信息，提高用户对作业请求***的粘性。

进一步的，在本申请实施例中，应用管理平台还可以获取当前的集群资源分配信息，应用管理平台和资源调度平台运行于包括多个节点的集群，集群资源分配信息指示应用管理平台和资源调度平台对集群资源的分配情况；基于当前的集群资源分配信息，对应用管理平台和资源调度平台对集群资源的分配情况进行平衡管理。

在本申请实施例中，应用管理平台和资源调度平台运行于包括多个节点的集群，本申请实施例可以对应用管理平台和资源调度平台分别占用集群资源的情况进行监控，得到集群资源分配信息(该集群资源分配信息可以指示同一时间应用管理平台和资源调度平台对集群资源的分配情况，比如，同一时间应用管理平台占用集群的资源和资源调度平台占用集群的资源)；进而基于该集群资源分配信息，对应用管理平台和资源调度平台对集群资源的分配情况进行平衡管理。

在本申请实施例中，优选的，基于预设规则和集群资源分配信息，对应用管理平台和资源调度平台对集群资源的分配情况进行平衡管理；其中，预设规则可以为应用管理平台和资源调度平台占用集群资源的比例；在监测到同一时间应用管理平台和资源调度平台占用集群资源的比例不满足预设规则时，可以对应用管理平台和资源调度平台对集群资源的分配情况进行平衡管理，以使得应用管理平台和资源调度平台占用集群资源的比例满足预设规则。

本申请通过对应用管理平台和资源调度平台对集群资源的分配情况的平衡管理，可以避免因应用管理平台/资源调度平台中任意一方占用集群资源过多而导致另一方占用集群资源过少，占用集群资源过少的另一方处理效率降低，进而影响作业请求效率的情况，且保证了作业请求***的稳定性。

本申请实施例还提供一种作业请求装置的结构示意图，请参见图5。

如图5所示，该装置包括：

作业请求接收单元51，用于接收目标租户发送的作业请求；

目标资源队列确定单元52，用于确定资源调度平台中仅用于处理目标租户发送的作业请求的目标资源队列，资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个资源队列仅用于处理与其对应的租户发送的作业请求；

作业请求单元53，用于向资源调度平台发送指示目标资源队列的作业请求，接收目标资源队列返回的作业请求的请求结果，并将请求结果返回给目标租户。

在本申请实施例中，应用管理平台包括分别与每个租户对应的多个应用实例，作业请求接收单元51具体用于应用管理平台中的目标应用实例接收目标租户发送的作业请求，目标应用实例为与目标租户对应的用于处理作业请求的应用实例。

在本申请实施例中，应用管理平台包括分别与每个租户对应的多个应用实例管理单元，每个应用实例管理单元中包括一个应用实例，作业请求接收单元51具体用于应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问目标应用实例管理单元中的目标应用实例，以便目标应用实例接收作业请求。

参见图6为本申请实施例提供的一种作业请求接收单元的详细结构示意图。如图6所示，该作业请求接收单元包括：

第一作业请求接收单元61，用于应用管理平台接收目标租户发送的作业请求；

地址获取单元62，用于应用管理平台从本地存储的目标租户的各个应用实例管理单元的地址中，获取用于处理作业请求的目标应用实例管理单元的地址；

第二作业请求接收单元63，用于应用管理平台中的目标应用实例管理单元接收应用管理平台基于所获取的地址发送的作业请求，访问目标应用实例管理单元中的目标应用实例。

在本申请实施例中，目标资源队列确定单元52具体用于应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，所确定的资源队列为资源调度平台中仅用于处理目标租户发送的作业请求的目标资源队列。

在本申请实施例中，目标资源队列确定单元52具体用于应用管理平台中的目标应用实例获取其所属的容器中挂载的配置文件；目标应用实例将配置文件指示的资源队列确定为预先设置的与其关联的资源队列。

进一步的，在本申请实施例提供的一种作业请求装置中，还包括状态信息确定单元，用于：监控应用管理平台中各个应用实例的状态信息；根据各个应用实例的状态信息以及每个应用实例对应的租户，得到分别与每个租户对应的各个应用实例的状态信息。

进一步的，在本申请实施例提供的一种作业请求装置中，还包括管理单元，用于：获取当前的集群资源分配信息，应用管理平台和资源调度平台运行于包括多个节点的集群，集群资源分配信息指示应用管理平台和资源调度平台对集群资源的分配情况；基于当前的集群资源分配信息，对应用管理平台和资源调度平台对集群资源的分配情况进行平衡管理。

进一步的，本申请实施例还提供一种电子设备，该电子设备包括存储器以及处理器，处理器以及存储器通过通信总线相连，该存储器用于存储程序，该程序用于实现上述作业请求方法；处理器，用于调用并执行存储器中存储的程序。

进一步的，本申请实施例还提供一种存储介质，该存储介质中存储有计算机可执行指令，该计算机可执行指令用于执行上述作业请求方法。

以上对本发明所提供的一种作业请求方法、装置、电子设备及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种作业请求方法，特征在于，包括：

应用管理平台接收目标租户发送的作业请求；

所述应用管理平台确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，所述资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个所述资源队列仅用于处理与其对应的租户发送的作业请求；

所述应用管理平台向所述资源调度平台发送指示所述目标资源队列的所述作业请求，接收所述目标资源队列返回的所述作业请求的请求结果，并将所述请求结果返回给所述目标租户；

所述应用管理平台获取当前的集群资源分配信息，所述应用管理平台和所述资源调度平台运行于包括多个节点的集群，所述集群资源分配信息指示所述应用管理平台和所述资源调度平台对所述集群资源的分配情况；

基于当前的集群资源分配信息，对所述应用管理平台和所述资源调度平台对所述集群资源的分配情况进行平衡管理。

2.根据权利要求1所述的方法，其特征在于，所述应用管理平台包括分别与每个所述租户对应的多个应用实例，所述应用管理平台接收目标租户发送的作业请求，包括：

应用管理平台中的目标应用实例接收目标租户发送的作业请求，所述目标应用实例为与所述目标租户对应的用于处理所述作业请求的应用实例。

3.根据权利要求2所述的方法，其特征在于，所述应用管理平台包括分别与每个租户对应的多个应用实例管理单元，每个所述应用实例管理单元中包括一个应用实例，所述应用管理平台中的目标应用实例接收目标租户发送的作业请求，包括：

所述应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问所述目标应用实例管理单元中的目标应用实例，以便所述目标应用实例接收所述作业请求。

4.根据权利要求3所述方法，其特征在于，所述应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求，访问所述目标应用实例管理单元中的目标应用实例，包括：

所述应用管理平台接收目标租户发送的作业请求；

所述应用管理平台从本地存储的所述目标租户的各个应用实例管理单元的地址中，获取用于处理所述作业请求的目标应用实例管理单元的地址；

所述应用管理平台中的目标应用实例管理单元接收所述应用管理平台基于所获取的地址发送的所述作业请求，访问所述目标应用实例管理单元中的目标应用实例。

5.根据权利要求2所述的方法，其特征在于，所述应用管理平台确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，包括：

所述应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，所确定的资源队列为所述资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列。

6.根据权利要求5所述的方法，其特征在于，所述应用管理平台中的目标应用实例确定预先设置的与其关联的资源队列，包括：

所述应用管理平台中的目标应用实例获取其所属的容器中挂载的配置文件；

所述目标应用实例将所述配置文件指示的资源队列确定为预先设置的与其关联的资源队列。

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

所述应用管理平台监控所述应用管理平台中各个应用实例的状态信息；

所述应用管理平台根据各个所述应用实例的状态信息以及每个所述应用实例对应的租户，得到分别与每个租户对应的各个应用实例的状态信息。

8.一种作业请求装置，特征在于，包括：

作业请求接收单元，用于应用管理平台中的目标应用实例管理单元接收目标租户发送的作业请求；

目标资源队列确定单元，用于确定资源调度平台中仅用于处理所述目标租户发送的作业请求的目标资源队列，所述资源调度平台由至少一个资源队列构成，不同资源队列对应不同租户，每个所述资源队列仅用于处理与其对应的租户发送的作业请求；

作业请求单元，用于向所述资源调度平台发送指示所述目标资源队列的所述作业请求，接收所述目标资源队列返回的所述作业请求的请求结果，并将所述请求结果返回给所述目标租户；

管理单元，用于获取当前的集群资源分配信息，所述应用管理平台和所述资源调度平台运行于包括多个节点的集群，所述集群资源分配信息指示所述应用管理平台和所述资源调度平台对所述集群资源的分配情况；基于当前的集群资源分配信息，对所述应用管理平台和所述资源调度平台对所述集群资源的分配情况进行平衡管理。

9.一种电子设备，其特征在于，存储器以及处理器，所述存储器，用于存储程序，所述程序用于实现如权利要求1-7任意一项所述的作业请求方法；所述处理器，用于调用并执行所述存储器中存储的程序。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1-7任意一项所述的作业请求方法。

Images