CN114924888A - 资源配置方法、数据处理方法、装置、设备和存储介质 - Google Patents

Abstract

本申请涉及一种资源配置方法、数据处理方法、装置、设备和存储介质。该资源配置方法应用于管理目标容器集群的GPU资源的资源管理服务，该方法包括：响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。如此，资源管理服务根据客户端的GPU资源需求信息，自动在目标容器集群中为其配置至少一个容器实体，整个过程无需人工介入，提高了GPU资源配置效率。

Description

资源配置方法、数据处理方法、装置、设备和存储介质

技术领域

本申请涉及云原生技术领域，特别是涉及一种资源配置方法、数据处理方法、装置、设备和存储介质。

背景技术

随着图形处理器(Graphics Processing Unit，GPU)在硬件架构上取得持续的高速发展，GPU已经演变为拥有强大的计算能力的高度并行、多线程及多处理核心的处理器，它采用不同于中央处理器的单指令多线程体系结构，增加了编程的灵活性。

在医疗行业中，常常涉及到影像高计算性能服务，当服务端中存在新接入的客户端时，需要在服务端的物理服务器中启动一个GPU服务。由于GPU服务是独享GPU显卡模式，一个GPU显卡只能运行一个GPU服务，因此，在新启动一个GPU服务之前，需要工作人员评估服务端中各物理服务器的GPU资源使用情况，在服务端GPU资源充足的情况下，手动在物理服务器中启动一个GPU服务。进一步地，当服务端接收到客户端发起的数据处理请求时，手动将流量转发给该客户端对应的GPU服务进行处理。

在此过程中，GPU服务的资源配置需要手动操作，导致客户端的接入过程较为复杂。

发明内容

基于此，有必要针对上述技术问题，提供一种能够实现GPU服务自动配置，同时提高GPU资源使用率的资源配置方法、数据处理方法、装置、设备和存储介质。

第一方面，本申请提供了一种资源配置方法，应用于资源管理服务，资源管理服务用于管理目标容器集群的GPU资源；该方法包括：

响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

在其中一个实施例中，获取客户端的GPU资源需求信息和客户端的标识信息，包括：

从目标容器集群中的注册中心获取客户端的注册信息；

根据注册信息，确定客户端的GPU资源需求信息和客户端的标识信息。

在其中一个实施例中，根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源，包括：

根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中确定至少一个目标GPU服务；每个目标GPU服务对应一个容器实体；

根据各目标GPU服务中的空闲资源信息，确定目标GPU服务资源。

在其中一个实施例中，该方法还包括：

根据目标容器集群的GPU资源使用状态，确定目标容器集群的第一GPU资源使用率；

若第一GPU资源使用率大于预设的第一资源阈值，则发送资源告警信息；资源告警信息用于指示在目标容器集群中新增至少一个GPU服务。

在其中一个实施例中，该方法还包括：

针对客户端对应的至少一个容器实体，获取客户端的GPU资源使用率；

GPU资源使用率包括客户端对应的各容器实体的第二GPU资源使用率；

若存在至少一个第二GPU资源使用率大于预设的第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照预设的扩容步长，增加客户端对应的容器实体的数量；

或者，

GPU资源使用率包括客户端对应的所有容器实体的总GPU资源使用率；

若总GPU资源使用率大于第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照扩容步长，增加客户端对应的容器实体的数量。

在其中一个实施例中，该方法还包括：

针对客户端对应的至少一个容器实体，获取各容器实体的第二GPU资源使用率；

若各容器实体的第二GPU资源使用率均小于第二资源阈值，则按照预设的缩容步长，减少客户端对应的容器实体的数量。

第二方面，本申请还提供了一种数据处理方法，该方法包括：

接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过上述第一方面中任一方法实施例所示的资源配置方法生成的；

将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

第三方面，本申请还提供了一种资源配置装置，该装置用于管理目标容器集群的GPU资源；该装置包括：

获取模块，用于响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

资源配置模块，用于根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

流量配置模块，根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

第四方面，本申请还提供了一种数据处理装置，该装置包括：

接收模块，用于接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

确定模块，用于根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过上述第一方面中任一方法实施例所示的资源配置方法生成的；

流量转发模块，用于将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

第五方面，本申请还提供了一种计算机设备，该计算机设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述第一方面中任一方法实施例的步骤，或者，实现上述第二方面中所示方法实施例的步骤。

第六方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面中任一方法实施例的步骤，或者，实现上述第二方面中所示方法实施例的步骤。

第七方面，本申请还提供了一种计算机程序产品，该计算机程序产品包括计算机程序，计算机程序被处理器执行时实现上述第一方面中任一方法实施例的步骤，或者，实现上述第二方面中所示方法实施例的步骤。

上述资源配置方法、数据处理方法、装置、设备和存储介质，目标器群中的资源管理服务响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。在本申请中，管理目标容器集群的GPU资源的资源管理服务可以感知到客户端接入时，在目标容器集群中为该客户端启动至少一个容器实体，以实现客户端GPU服务资源的自动配置，无需人工介入操作，提高了客户端的GPU资源配置效率。同时，在为客户端配置GPU资源时，是根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态确定的，保证配置的目标GPU服务资源可以满足客户端的需求，GPU资源配置准确度更高。进一步地，在为客户端启动至少一个容器实体后，根据客户端的标识信息和所配置的容器实体之间的对应关系，生成该客户端的流量转发配置信息。如此，在后续数据处理过程中，可以通过该流量转发配置信息，快速有效地将客户端的访问流量转发给对应的容器实体进行处理。

附图说明

图1a为一个实施例中客户端接入示意图；

图1b为一个实施例中目标容器集群的架构示意图；

图1c为一个实施例中资源配置方法的应用环境示意图；

图2为一个实施例中资源配置方法的流程示意图；

图3为一个实施例中客户端信息获取流程示意图；

图4为一个实施例中目标GPU服务资源配置流程示意图；

图5为另一个实施例中资源配置方法的流程示意图；

图6为一个实施例中目标容器集群的扩容流程示意图；

图7为一个实施例中客户端GPU服务扩容流程示意图；

图8为一个实施例中客户端GPU服务缩容流程示意图；

图9为一个实施例中数据处理方法的流程示意图；

图10为一个实施例中资源配置装置的结构框图；

图11为一个实施例中数据处理装置的结构框图；

图12为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在医疗行业中，常常涉及到医学影像高计算性能服务，需要利用物理服务器上的GPU资源来实现数据计算和处理。对于服务端的多个物理服务器而言，每个物理服务器上可以部署一个或多个GPU显卡，对外提供的GPU服务独享显卡模式，即每个显卡只能运行一个GPU服务。

参见图1a，当有客户端项目在注册中心完成地址信息注册后，即执行接入服务端操作。在接入服务端时，需要人工评估服务器的GPU资源是否充足，然后手动在代理服务中为新接入的客户端配置一个GPU服务。进一步地，代理服务从注册中心获取新接入客户端的注册信息，建立新接入客户端和GPU服务之间的对应关系，生成流量转发配置信息。

其中，客户端项目和GPU服务之间为一一对应关系，客户端项目和GPU服务的数量可以为一个，也可以为多个，图1a仅以3个客户端项目和3个GPU服务进行举例，并不在于限制其数量。

通过上述方式为客户端配置对应的GPU服务时，手动操作较多，客户端的接入过程较为复杂。而且，当存在大量的客户端接入时，整个系统的维护成本较大，GPU成本也非常大。

基于此，本申请提供了一种资源配置方法、数据处理方法、装置、设备和存储介质，在目标容器集群中实现客户端对应GPU服务的自动配置，同时提高服务端GPU资源的使用率。

其中，目标容器集群可以为由容器构成的云计算网络，比如，可基于开源的Kubernetes和Moby(Docker的社区项目)定制优化实现，交付云计算通信即服务(Communication as a service，CaaS)能力，主要是持续集成、持续部署和面向应用的微服务能力。kubernetes简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用。

在一个实施例中，参见图1b，目标容器集群可以是基于Kubernetes实现的容器集群，目标容器集群100包括一个主节点110和多个GPU节点120。

其中，主节点110包括API(Application Programming Interface，应用程序接口)服务器111、调度器112、资源管理器113和资源状态存储器114；每个GPU节点120包括节点管理单元121、代理服务器122和运行在容器运行环境下的多个容器实体123，每个容器实体123中包括多个容器。

以Kubernetes为例，容器实体123即为Kubernetes创建或部署的最小/最简单的基本单位Pod，一个Pod代表集群上正在运行的一个进程，一个Pod可封装一个或多个应用容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。

需要说明的是，基于云原生的kubernetes技术实现的目标容器集群100，在为客户端提供GPU服务时，开发者无需关心底层的技术实现，只需要关注自己的代码开发，将整个部署流程基本实现全部自动化。

因此，本申请中的目标容器集群100不关心每个GPU节点120对应的底层物理服务器数量，只需明确每个GPU节点120可用的GPU服务数量即可。在为客户端提供GPU服务时，在目标容器集群中为该客户端确定其对应的GPU节点，以及在该节点上对应的目标GPU服务即可。

具体地，在主节点110中，API服务器111用于提供Kubernetes API服务，作为系统管理指令的统一入口，对GPU服务资源增删改查等操作均由API服务器处理后，再提交到资源状态存储器114；调度器112用于将Pod部署到合适的GPU节点上；资源管理器113用于管理每个GPU服务资源对应的控制器；资源状态存储器114用于存储各个GPU服务资源的状态。

具体地，在GPU节点120中，节点管理单元121用于维护和管理GPU节点中的所有容器实体123，以使容器实体123的运行状态和期望的状态一致，其中，Kubernetes目前支持的容器运行环境包括Docker和Rocket等；代理服务器122用于实现目标容器集群中GPU服务资源启动和反向代理功能，即维护GPU服务资源与容器实体123之间的映射关系。

进一步地，在上述目标容器集群的基础上，从GPU资源层面而言，无需关注目标容器集群200中所包括的GPU节点数量以及GPU节点分布情况，只需明确目标容器集群200所包括的GPU服务数量即可。即，在不考虑目标容器集群100中节点部署的情况下，只关注目标容器集群可以对外提供的GPU服务层面来看，本申请提供的资源配置方法，可以进一步地应用于如图1c所示的应用环境中。

应该理解的是，图1b中的目标容器集群100和图1c中的目标容器集群200为同一容器集群，其底层的物理硬件分布情况相同，区别仅在于两个附图是从不同的层面来进行说明的，目标容器集群100是从集群中节点层面进行说明的，目标容器集群200是从集群所提供的GPU服务层面来进行说明的。

在另一个实施例中，参见图1c，目标容器集群200可以包括注册中心210、资源管理服务220和服务端230。其中，服务端230包括代理服务231和多个GPU服务232，每个GPU服务232对应一个容器实体，可以对外提供GPU资源。

需要说明的是，本申请实施例不关注注册中心210、资源管理服务220和服务端230在目标容器集群中的部署节点，可以部署在图1b所示的主节点110中，也可以部署在任一GPU节点120中，对此不做限制。

具体地，注册中心210用于供客户端注册，注册完成后，即可访问目标容器集群，调用目标容器集群中的GPU服务资源；资源管理服务220是本申请实施例为实现GPU服务资源自动配置而设置的一种管理器，用于为新接入的客户端从目标容器集群200的服务端230中自动配置一个或一组目标GPU服务232；代理服务231用于根据客户端和至少一个目标服务232之间的对应关系，将客户端流量转发给对应的目标服务232进行处理。

需要说明的是，本申请实施例提供的资源配置方法不仅适用于基于Kubernetes实现的目标容器集群，还适用于其他容器集群。本申请提供的资源配置方法，其执行主体可以是资源配置装置，该资源配置装置可以通过软件、硬件或者软硬件结合的方式实现成为目标容器集群中部署资源管理服务220的底层计算机设备的部分或者全部。另外，本申请提供的数据处理方法，其执行主体可以是数据处理装置，该数据处理装置可以通过软件、硬件或者软硬件结合的方式实现成为目标容器集群中部署代理服务231的底层计算机设备的部分或者全部。

作为一个示例，目标容器集群中底层的计算机设备可以是服务器或者终端。其中，服务器可以为一台服务器，也可以为由多台服务器组成的服务器集群，终端可以是智能手机、个人电脑、平板电脑、以及智能机器人等其他智能硬件设备。

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

在一个实施例中，如图2所示，提供了一种资源配置方法，该方法应用于图1c中资源管理服务220对应的底层计算机设备，资源管理服务用于管理目标容器集群的GPU资源，该方法包括以下步骤：

步骤210：响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息。

其中，客户端标识信息为表示唯一一个客户端身份的信息，GPU资源需求信息用于描述客户端实际所需的GPU资源。

作为一个示例，客户端标识信息可以为客户端名称、客户端ID、客户端注册地址等，GPU资源需求信息可以包括GPU资源最大需求量和GPU资源最小需求量。

在一种可能的实现方式中，客户端的接入请求中携带有客户端的GPU资源需求信息和客户端的标识信息，资源管理服务接收客户端发送的接入请求后，即可从接入请求中解析出该客户端的标识信息和GPU资源需求信息。

需要说明的是，为实现快速GPU资源的快速配置，且保证目标容器集群中的GPU服务资源可以在各客户端之间实现共享，当客户端接入目标容器集群时，资源管理服务为其配置对应的目标GPU服务资源。待客户端接入后，即可可以使用目标GPU服务资源处理数据，此时，目标GPU服务资源仅用于处理对应客户端的数据处理任务。当客户端下线后，资源管理服务销毁对应的目标GPU服务资源配置，将目标GPU服务的GPU资源释放出来，供其他客户端接入使用，以实现GPU服务的灵活配置。

由于目标容器集群中的GPU服务资源是灵活配置的，大大提高了目标容器集群中GPU资源的利用率，可以供更多的客户端调用。因此，本申请实施例不限制客户端的接入数量和接入时机，只要目标容器集群中在客户端接入时存在未分配的GPU服务资源，即可供客户端接入使用。

步骤220：根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体。

其中，若目标容器集群为kubernetes实现的容器集群，则此处的容器实体即为容器集群中容器运行环境中的Pod。配置给客户端的目标GPU服务资源包括至少一个容器实体的GPU资源，即配置给客户端的目标GPU资源可以为一个Pod，也可以为一组Pod。

参见图1c，目标容器集群的服务端包括多个GPU服务，每个GPU服务对应一个容器实体，进一步地，该容器实体上可以创建多个应用容器。

在一种可能的实现方式中，步骤220的实现过程可以为：资源管理服务可以实时或者周期性采集目标容器集群中各容器实体的GPU资源使用情况，进而在接收到客户端的接入请求后，可以根据客户端的GPU资源需求信息，从目标容器集群中确定至少一个容器实体，使得至少一个容器实体上的GPU资源可以满足该客户端需求的GPU资源。

应该理解的是，当客户端所需的GPU资源较少时，可以在目标容器集群中为其确定一个容器实体。当客户端所需的GPU资源较多时，可以在目标容器集群中为其确定多个容器实体。

步骤230：根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

其中，流量转发配置信息包括客户端对应的至少一个容器实体，基于流量转发配置信息可以将客户端的流量转发给该客户端对应的至少一个容器实体进行处理。

上述资源配置方法中，资源管理服务响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。也即是，管理目标容器集群的GPU资源的资源管理服务可以感知到客户端接入时，在目标容器集群中为该客户端启动至少一个容器实体，以实现客户端GPU服务资源的自动配置，无需人工介入操作，提高了客户端的GPU资源配置效率。同时，在为客户端配置GPU资源时，是根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态确定的，保证配置的目标GPU服务资源可以满足客户端的需求，GPU资源配置准确度更高。进一步地，在为客户端启动至少一个容器实体后，根据客户端的标识信息和所配置的容器实体之间的对应关系，生成该客户端的流量转发配置信息。如此，在后续数据处理过程中，可以通过该流量转发配置信息，快速有效地将客户端的访问流量转发给对应的容器实体进行处理。

基于上述实施例，参见图1c，客户端接入目标容器集群包括两种情况：

(1)客户端首次接入目标容器集群。

在首次接入时，客户端需要先在目标容器集群的注册中心进行注册，验证其身份合法性后，即可接入目标容器集群，由资源管理服务为其配置所需的目标GPU服务资源。

在此情况下，客户端的GPU资源需求信息和客户端的标识信息可以从目标容器集群的注册中心中获取。

(2)客户端注册完成后接入目标容器集群。

注册完成后，客户端可以基于自身的数据处理任务，向目标容器集群的代理服务发送接入请求，请求调用目标容器集群中的GPU服务资源处理数据。在此情况下，客户端的GPU资源需求信息和客户端的标识信息可以从目标容器集群的代理服务接收的接入请求中提取。

进一步地，代理服务将解析的GPU资源需求信息和标识信息发送给资源管理服务，由资源管理服务为其配置目标GPU服务资源。

但不论哪种情况，客户端在每次接入目标容器集群时，资源管理服务均会为其重新配置对应的目标GPU服务资源。且在客户端下线后，释放目标GPU服务资源。

在一个实施例中，针对上述情况(1)描述的客户端注册阶段，如图3所示，资源管理服务获取客户端的GPU资源需求信息和客户端的标识信息(对应上述步骤210)的实现过程，包括以下步骤：

步骤310：从目标容器集群中的注册中心获取客户端的注册信息。

其中，注册信息包括客户端的名称、ID、标识、注册地址、访问量、负载均衡策略、服务高可用策略、GPU资源最大需求量、GPU资源最小需求量等，本实施例对此不做限制。

在一种可能的实现方式中，步骤310的实现过程可以为：资源管理服务实时/定时监听注册中心的客户端注册情况，当监听到有新客户端注册时，从注册中心读取新注册客户端的注册信息。

步骤320：根据注册信息，确定客户端的GPU资源需求信息和客户端的标识信息。

在该步骤中，资源管理服务获取到客户端的注册信息后，从注册信息中解析客户端的GPU资源需求信息和标识信息。

在本实施例中，资源管理服务可以利用目标容器集群的注册中心，获取新注册客户端的标识信息和GPU资源需求信息。由于注册中心在客户端注册时，会验证其身份的合法性，因此，从注册中心中获取的客户端信息更为准确。

在一个实施例中，如图4所示，资源管理服务为客户端配置目标GPU服务资源(对应上述步骤220)的实现过程，包括以下步骤：

步骤410：根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中确定至少一个目标GPU服务。

其中，每个目标GPU服务对应一个容器实体。目标容器集群的GPU资源使用状态包括目标容器集群的GPU资源整体使用率和目标容器集群中各GPU服务上的GPU资源使用率。

进一步地，资源使用状态还可以包括目标容器集群中的各GPU服务的已使用GPU资源和空闲GPU资源。

在一种可能的实现方式中，步骤410的实现过程可以为：资源管理服务获取目标容器集群中各GPU服务的资源使用率，确定各GPU服务的空闲GPU资源。然后基于客户端的GPU资源需求信息，从目标容器集群中为该客户端确定至少一个目标GPU服务。

其中，至少一个目标GPU服务总的空闲GPU资源大于或等于客户端的GPU资源需求。

步骤420：根据各目标GPU服务中的空闲资源信息，确定目标GPU服务资源。

其中，空闲资源信息为各目标GPU服务中的空闲GPU资源。

在该步骤中，当目标GPU服务为一个时，目标GPU服务中的空闲GPU资源，即为目标GPU服务资源。当目标GPU服务为多个时，各目标GPU服务中的空闲GPU资源之和，即为目标GPU服务资源。

作为一个示例，若目标GPU服务包括第一GPU服务、第二GPU服务和第三GPU服务，则目标GPU服务资源即为第一GPU服务的空闲资源、第二GPU服务的空闲资源和第三GPU服务的空闲资源之和。

在本实施例中，资源管理服务结合客户端的GPU资源需求和目标容器集群中的GPU资源使用状态为客户端配置目标GPU服务资源，可以保证目标GPU服务资源满足客户端处理数据任务时的GPU资源需求；同时，还可以充分调用目标容器集群中的GPU服务，提高了目标容器集群中的GPU资源利用率。

综合上述各方法实施例，在一个实施例中，如图5所示，本申请还提供了另一种资源配置方法，该方法同样应用于图1c中的资源管理服务220对应的底层计算机设备，资源管理服务用于管理目标容器集群的GPU资源，该方法包括以下步骤：

步骤510：从目标容器集群中的注册中心获取客户端的注册信息；

步骤520：根据注册信息，确定客户端的GPU资源需求信息和客户端的标识信息；

步骤530：根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中确定至少一个目标GPU服务；每个目标GPU服务对应一个容器实体；

步骤540：根据各目标GPU服务中的空闲资源信息，确定目标GPU服务资源；

步骤550：根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

本实施例提供的资源配置方法中各步骤的实现原理和技术效果与前面各方法实施例相类似，具体的限定和解释可参见前面各方法实施例，在此不再赘述。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于上述任一实施例示出的资源配置方法，为提高GPU资源利用率，可以对目标容器集群和客户端的GPU服务资源进行调整，以保证目标容器集群的GPU服务可以满足接入客户端的GPU资源需求，同时，保证为每个客户端配置的目标GPU服务资源也可以得到有效利用。

在一个实施例中，如图6所示，对目标容器集群包括的GPU服务进行调整具体为根据接入客户端的需求，增加目标容器集群中的GPU服务数量，包括以下步骤：

步骤610：根据目标容器集群的GPU资源使用状态，确定目标容器集群的第一GPU资源使用率。

其中，目标容器集群的GPU资源使用状态可以包括整个目标容器集群的总GPU资源、已用GPU资源和空闲GPU资源。

需要说明的是，整个目标容器集群的总GPU资源可以根据目标容器集群底层中各物理服务器上配置的GPU显卡数量和各GPU显卡对应的GPU资源确定。

在该步骤中，基于目标容器集群的总GPU资源和已用GPU资源，即可确定目标容器集群的第一GPU资源使用率。第一GPU资源使用率可以表征目标容器集群所包括的容器实体的GPU资源使用情况。

步骤620：若第一GPU资源使用率大于预设的第一资源阈值，则发送资源告警信息；资源告警信息用于指示在目标容器集群中新增至少一个GPU服务。

其中，第一资源阈值为预先设置的GPU资源使用率阈值，比如，70％、80％或者90％，可以根据目标容器集群的运行安全情况进行设定，其表征目标容器集群可以对外提供的GPU服务资源的最大量。

在该步骤中，当第一GPU资源使用率大于第一资源阈值时，表征目标容器集群的GPU资源的使用已饱和，无法再为接入的客户端提供相应的GPU服务。此时，为保证目标容器集群可以为客户端提供GPU服务，需要在目标容器集群中新增至少一个GPU服务。

其中，新增GPU服务可以通过在目标容器集群的底层物理服务器上增加GPU显卡，或者，在目标容器集群中的底层硬件中增加物理服务器，且新增物理服务器上包括至少一个GPU显卡。

可选地，在目标容器集群中新增GPU服务时，可以按照预设的扩容步长，多次增加GPU服务；也可以按照预设的扩充数量进行增加，在一次扩容操作中为目标容器集群新增多个GPU服务，本实施例对此不做限制。

在该步骤中，当第一GPU资源使用率小于第一资源阈值时，表征目标容器集群中尚且存在空闲GPU服务，空闲GPU服务的GPU服务资源可以供给客户端使用，此时则无需对目标容器集群进行扩容。

在本实施例中，通过检测目标容器集群的GPU资源使用状态，在目标容器集群的GPU资源饱和或负荷状态时，对目标容器集群进行及时扩容，以增加目标容器集群中的GPU服务数量，保证目标容器集群的GPU服务可以满足客户端的需求。

另外，客户端的GPU服务资源进行调整包括对客户端已配置的容器实体进行扩充和缩容，具体的调整过程，可以参见下述图7和图8对应的实施例。

在一个实施例中，如图7所示，通过增加客户端对应的容器实体数量，对客户端的目标GPU服务资源进行扩容，包括以下步骤：

步骤710：针对客户端对应的至少一个容器实体，获取客户端的GPU资源使用率。

其中，客户端的GPU资源使用率包括以下两种情况：

(1)GPU资源使用率包括客户端对应的各容器实体的第二GPU资源使用率。

其中，容器实体的第二GPU资源使用率表征该容器实体中GPU资源的实际使用情况，可以根据该容器实体的总GPU资源和已用GPU资源之间的比值确定。

作为一个示例，若客户端对应三个容器实体：容器实体A、容器实体B和容器实体C，则在此情况中获取的客户端的GPU资源使用率包括：容器实体A的第二GPU资源使用率、容器实体B的第二GPU资源使用率和容器实体C的第二GPU资源使用率。

进一步地，若容器实体A的总GPU资源为5G，已用GPU资源为1G，则容器实体A的第二GPU资源使用率为20％。

即，在情况(1)中，客户端的GPU资源使用率为20％、20％、20％。

(2)GPU资源使用率包括客户端对应的所有容器实体的总GPU资源使用率。

其中，总GPU资源使用率是根据各容器实体的总GPU资源和已用GPU资源确定的。

作为一个示例，若客户端对应三个容器实体：容器实体A、容器实体B和容器实体C，则在此情况下，可以根据容器实体A、容器实体B和容器实体C各自的总GPU资源和已用GPU资源来计算该客户端的总GPU资源使用率。

进一步地，若容器实体A的总GPU资源为5G，已用GPU资源为1G；容器实体B的总GPU资源为5G，已用GPU资源为2G；容器实体C的总GPU资源为5G，已用GPU资源为3G，则该客户端的总GPU资源使用率可以通过下述公式(1)计算：

即，在情况(2)中，客户端的GPU资源使用率为40％。

针对上述情况(1)，对客户端的容器实体数量进行扩容，可以通过下述步骤720来实现；针对上述情况(2)，对客户端的容器实体数量进行扩充，可以通过下述步骤730来实现。

步骤720：若存在至少一个第二GPU资源使用率大于预设的第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照预设的扩容步长，增加客户端对应的容器实体的数量。

需要说明的是，针对该客户端的任一容器实体，当容器实体的第二GPU资源使用率大于预设的第二资源阈值时，表征该容器实体处于负荷状态，其GPU资源已无法满足客户端的需求；而第一GPU资源使用率小于第一资源阈值，表征目标容器集群中还存在空闲GPU服务的GPU资源可以供该客户端进行扩容。

因此，对客户端的所有容器实体而言，若存在至少一个第二GPU资源使用率大于第二资源阈值，且第一GPU资源使用率小于第一资源阈值，即增加客户端的容器实体数量，以为其配置更多的目标GPU服务资源。

应该理解的是，当客户端的容器实体为多个时，只要存在一个容器实体的第二GPU资源使用率大于第二资源阈值，则需要增加该客户端的实体容器的数量。

步骤730：若总GPU资源使用率大于第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照扩容步长，增加客户端对应的容器实体的数量。

需要说明的是，针对该客户端的所有容器实体，当所有容器实体的总GPU资源使用率大于第二资源阈值时，表征该客户端的存在至少一个容器实体处于负荷状态，GPU资源已无法满足客户端的需求；而第一GPU资源使用率小于第一资源阈值，表征目标容器集群中还存在空闲GPU服务的GPU资源可以供该客户端进行扩容。

作为一个示例，本实施例中的第二资源阈值可以为60％，预设的扩容步长可以为1。当客户端任一容器实体的第二GPU资源使用率，或者客户端所有容器实体的总GPU资源使用率大于60％时，即为该客户端新增一个容器实体。当然，第二资源阈值和扩充步长也可以为其他数值，本实施例对此不做限制。

在本实施例中，通过检测客户端的GPU资源使用率，可以确定客户端的实时GPU资源需求量，进而根据客户端的实际需求及时增加客户端的容器实体数量，以保证配置的容器实体的GPU资源可以满足客户端的GPU资源需求。

在一个实施例中，如图8所示，通过减少客户端对应的容器实体数量，对客户端的目标GPU服务资源进行缩容，包括以下步骤：

步骤810：针对客户端对应的至少一个容器实体，获取各容器实体的第二GPU资源使用率。

其中，针对客户端的任一容器实体，容器实体的第二GPU资源使用率表征该容器实体中GPU资源的实际使用情况，可以根据该容器实体的总GPU资源和已用GPU资源之间的比值确定。

步骤820：若各容器实体的第二GPU资源使用率均小于第二资源阈值，则按照预设的缩容步长，减少客户端对应的容器实体的数量。

需要说明的是，针对客户端的任意一个容器实体，当该容器实体的第二GPU资源使用率小于预设的第二资源阈值，表征该容器实体的GPU资源未得到有效利用，尚且存在空闲GPU资源。因此，在客户端对应的至少一个容器实体中，每个容器实体的第二GPU资源使用率均小于第二资源阈值时，可以适当减少客户端的容器实体数量，以节约目标容器集群中的GPU服务资源，使得空闲GPU资源得到有效利用。

作为一个示例，第二资源阈值可以为40％，预设的缩容步长可以为1。即当客户端对应的容器实体的GPU资源使用率均小于40％时，将该客户端的容器实体数量减少一个。当然，第二资源阈值和缩容步长也可以为其他数值，本实施例对此不做限制。

在本实施例中，通过检测客户端中各容器实体的GPU资源使用率，可以确定客户端的实时GPU资源需求量，进而根据客户端的实际需求减少客户端的容器实体数量，以保证为该客户端配置的容器实体的GPU资源可以得到有效利用，同时，节约目标容器集群中的GPU服务资源，以供更多客户端使用。

在一个实施例中，基于生成的流量转发配置信息，本申请还提供了一种数据处理方法。如图9所示，该方法可以用于图1c中的代理服务对应的底层计算机设备，代理服务用于转发客户端的访问流量，该方法包括以下步骤：

步骤910：接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务。

其中，数据处理请求中还可以携带客户端的标识信息和GPU资源需求信息，若未携带上述两种信息时，代理服务也可以从注册中心中获取。

需要说明的是，客户端发送的数据处理请求可以通过外部的四层代理服务进行转发，以保证数据安全。在目标容器集群内部，代理服务可以为七层代理，以写入更多的转发规则。

步骤920：根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体。

其中，流量转发配置信息是通过上述任一实施例所示的资源配置方法生成的，生成的流量转发配置信息可以存储在目标容器集群内部七层的代理服务中。

在一种可能的实现方式中，步骤920的实现过程可以为：代理服务根据客户端的标识信息，从流量转发配置信息中确定该客户端对应的目标容器实体。

步骤930：将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

其中，若客户端对应一个目标容器实体，则将数据处理请求中携带的医学影像处理任务发送给该目标容器实体进行处理。若客户端对应多个目标容器实体，则可以进一步根据负载均衡策略，将数据处理请求中的至少一个医学影像处理任务，分配给一个或者多个目标容器实体进行处理。

在本实施例中，代理服务在存储客户端和服务端之间的流量转发配置信息后，即可将客户端的医学影像处理任务转发给对应的目标容器实体进行处理。如此，通过为客户端快速且准确地转发数据处理请求到对应的目标容器实体，提高了数据处理效率。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的资源配置方法的资源配置装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个资源配置装置实施例中的具体限定可以参见上文中对于资源配置方法的限定，在此不再赘述。

在一个实施例中，如图10所示，提供了一种资源配置装置，该装置1000包括：获取模块1010、资源配置模块1020和流量配置模块1030，其中：

获取模块1010，用于响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

资源配置模块1020，用于根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

流量配置模块1030，根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

在其中一个实施例中，获取模块1010，包括：

获取单元，用于从目标容器集群中的注册中心获取客户端的注册信息；

第一确定单元，用于根据注册信息，确定客户端的GPU资源需求信息和客户端的标识信息。

在其中一个实施例中，资源配置模块1020，包括：

第二确定单元，用于根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中确定至少一个目标GPU服务；每个目标GPU服务对应一个容器实体；

第三确定单元，用于根据各目标GPU服务中的空闲资源信息，确定目标GPU服务资源。

在其中一个实施例中，该装置1000还包括：

第一确定模块，用于根据目标容器集群的GPU资源使用状态，确定目标容器集群的第一GPU资源使用率；

集群扩容模块，用于若第一GPU资源使用率大于预设的第一资源阈值，则发送资源告警信息；资源告警信息用于指示在目标容器集群中新增至少一个GPU服务。

在其中一个实施例中，该装置1000还包括：

第二确定模块，用于针对客户端对应的至少一个容器实体，获取客户端的GPU资源使用率；

GPU资源使用率包括客户端对应的各容器实体的第二GPU资源使用率；

GPU服务扩容模块，用于若存在至少一个第二GPU资源使用率大于预设的第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照预设的扩容步长，增加客户端对应的容器实体的数量；

或者，

GPU资源使用率包括客户端对应的所有容器实体的总GPU资源使用率；

若总GPU资源使用率大于第二资源阈值，且第一GPU资源使用率小于第一资源阈值，则按照扩容步长，增加客户端对应的容器实体的数量。

在其中一个实施例中，该装置1000还包括：

GPU服务缩容模块，用于针对客户端对应的至少一个容器实体，获取各容器实体的第二GPU资源使用率；

若各容器实体的第二GPU资源使用率均小于第二资源阈值，则按照预设的缩容步长，减少客户端对应的容器实体的数量。

上述资源配置装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

对应地，基于同样的发明构思，本申请还提供了一种用于实现上述所涉及的数据处理方法的数据处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个数据处理装置实施例中的具体限定可以参见上文中对于数据处理方法的限定，在此不再赘述。

在一个实施例中，如图11所示，提供了一种数据处理装置，该装置1100包括：接收模块1110、确定模块1120和流量转发模块1130，其中：

接收模块1110，用于接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

确定模块1120，用于根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过权利要求1-6的资源配置方法生成的；

流量转发模块1130，用于将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

上述数据处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图12所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种资源配置方法和数据处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

在另一个实施例中，处理器执行计算机程序时还实现以下步骤：

接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过本申请提供的资源配置方法生成的；

将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

上述实施例提供的一种计算机设备，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

在另一个实施例中，计算机程序被处理器执行时还实现以下步骤：

接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过本申请提供的资源配置方法生成的；

将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

上述实施例提供的一种计算机可读存储介质，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

响应于客户端的接入请求，获取客户端的GPU资源需求信息和客户端的标识信息；

根据客户端的GPU资源需求信息和目标容器集群的GPU资源使用状态，在目标容器集群中为客户端配置目标GPU服务资源；目标GPU服务资源对应至少一个容器实体；

根据客户端的标识信息和至少一个容器实体之间的对应关系，生成客户端的流量转发配置信息。

在另一个实施例中，计算机程序被处理器执行时还实现以下步骤：

接收客户端发送的数据处理请求，数据处理请求携带有至少一个医学影像处理任务；

根据预设的流量转发配置信息，在目标容器集群中确定客户端对应的目标容器实体；流量转发配置信息是通过本申请提供的资源配置方法生成的；

将数据处理请求转发给目标容器实体，以指示目标容器实体执行至少一个医学影像处理任务。

上述实施例提供的一种计算机程序产品，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种资源配置方法，其特征在于，应用于资源管理服务，所述资源管理服务用于管理目标容器集群的GPU资源；所述方法包括：

响应于客户端的接入请求，获取所述客户端的GPU资源需求信息和所述客户端的标识信息；

根据所述客户端的GPU资源需求信息和所述目标容器集群的GPU资源使用状态，在所述目标容器集群中为所述客户端配置目标GPU服务资源；所述目标GPU服务资源对应至少一个容器实体；

根据所述客户端的标识信息和所述至少一个容器实体之间的对应关系，生成所述客户端的流量转发配置信息。

2.根据权利要求1所述的方法，其特征在于，所述获取所述客户端的GPU资源需求信息和所述客户端的标识信息，包括：

从所述目标容器集群中的注册中心获取所述客户端的注册信息；

根据所述注册信息，确定所述客户端的GPU资源需求信息和所述客户端的标识信息。

3.根据权利要求1或2所述的方法，其特征在于，所述根据所述客户端的GPU资源需求信息和所述目标容器集群的GPU资源使用状态，在所述目标容器集群中为所述客户端配置目标GPU服务资源，包括：

根据所述客户端的GPU资源需求信息和所述目标容器集群的GPU资源使用状态，在所述目标容器集群中确定至少一个目标GPU服务；每个目标GPU服务对应一个容器实体；

根据各所述目标GPU服务中的空闲资源信息，确定所述目标GPU服务资源。

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

根据所述目标容器集群的GPU资源使用状态，确定所述目标容器集群的第一GPU资源使用率；

若所述第一GPU资源使用率大于预设的第一资源阈值，则发送资源告警信息；所述资源告警信息用于指示在所述目标容器集群中新增至少一个GPU服务。

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

针对所述客户端对应的至少一个容器实体，获取所述客户端的GPU资源使用率；

所述GPU资源使用率包括所述客户端对应的各所述容器实体的第二GPU资源使用率；

若存在至少一个所述第二GPU资源使用率大于预设的第二资源阈值，且所述第一GPU资源使用率小于所述第一资源阈值，则按照预设的扩容步长，增加所述客户端对应的容器实体的数量；

或者，

所述GPU资源使用率包括所述客户端对应的所有容器实体的总GPU资源使用率；

若所述总GPU资源使用率大于所述第二资源阈值，且所述第一GPU资源使用率小于所述第一资源阈值，则按照所述扩容步长，增加所述客户端对应的容器实体的数量。

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

针对所述客户端对应的至少一个容器实体，获取各所述容器实体的第二GPU资源使用率；

若各所述容器实体的第二GPU资源使用率均小于所述第二资源阈值，则按照预设的缩容步长，减少所述客户端对应的容器实体的数量。

7.一种数据处理方法，其特征在于，所述方法包括：

接收客户端发送的数据处理请求，所述数据处理请求携带有至少一个医学影像处理任务；

根据预设的流量转发配置信息，在所述目标容器集群中确定所述客户端对应的目标容器实体；所述流量转发配置信息是通过权利要求1至6中任一项所述的资源配置方法生成的；

将所述数据处理请求转发给所述目标容器实体，以指示所述目标容器实体执行所述至少一个医学影像处理任务。

8.一种资源配置装置，其特征在于，所述装置用于管理目标容器集群的GPU资源；所述装置包括：

获取模块，用于响应于客户端的接入请求，获取所述客户端的GPU资源需求信息和所述客户端的标识信息；

资源配置模块，用于根据所述客户端的GPU资源需求信息和所述目标容器集群的GPU资源使用状态，在所述目标容器集群中为所述客户端配置目标GPU服务资源；所述目标GPU服务资源对应至少一个容器实体；

流量配置模块，根据所述客户端的标识信息和所述至少一个容器实体之间的对应关系，生成所述客户端的流量转发配置信息。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤，或者，实现权利要求7中所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤，或者，实现权利要求7中所述方法的步骤。

Images