一种数据处理方法、装置、电子设备以及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种数据处理方法、装置、电子设备以及存储介质。

背景技术

数据服务作为统一数据中台建设的最上层，能够将数据仓库数据以服务化、接口化的方式提供给数据使用方，屏蔽底层数据存储、计算的诸多细节，简化和加强数据的使用；同时避免烟囱式建设、加强数据API的开发和交付效率，提升数据利用率。

现有技术中，采用Kubernets(一种开源式容器编排系统)+docker(一种开源式应用容器引擎)的技术，基于云主机搭建宿主机进行容器化部署，为用户提供数据服务。

然而，上述方案容器化后整个容器是一体的，容器内没有进行数据隔离，存在数据污染的问题。

发明内容

本申请提供了一种数据处理方法、装置、电子设备以及存储介质，用以避免数据污染的问题。

第一方面，本申请实施例提供一种数据处理方法，所述方法包括：

接收目标数据服务应用程序编程接口(Application Programming Interface，API)的数据请求；

根据建立的数据服务API以及资源组之间的第一对应关系，确定所述目标数据服务API对应的目标资源组；

根据资源组与集群之间的第二对应关系，确定所述目标资源组对应的目标集群；

通过所述目标集群，对所述数据请求进行数据处理。

在一些可选的实施方式中，相同场景的集群放置在同一环境池中。

在一些可选的实施方式中，接收目标数据服务API的数据请求之前，还包括：

响应于所述目标数据服务API创建指令，建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系。

在一些可选的实施方式中，若所述目标资源组不是已有的资源组，则在建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系之前，还包括：

创建所述目标资源组。

在一些可选的实施方式中，创建所述目标资源组之后，还包括：

确定所述目标集群对应的初始数量的服务器；

根据所述初始数量的服务器，构建所述目标集群；

建立所创建的目标资源组与所述目标集群之间的第二对应关系。

在一些可选的实施方式中，根据所述初始数量的服务器，构建所述目标集群，包括：

若所述目标集群对应的资源池中有所述初始数量的未被占用的服务器，则从对应的资源池中镜像所述初始数量的服务器，并将镜像的服务器部署到所述目标集群中；

若所述目标集群对应的资源池没有所述初始数量的未被占用的服务器，则在对应的资源池中生成所述初始数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述目标集群中。

在一些可选的实施方式中，通过所述目标集群，对所述数据请求进行数据处理之后，还包括：

确定处理所述数据请求的目标集群中的服务器的处理结果，并通过所述目标数据服务API返回所述处理结果。

在一些可选的实施方式中，所述方法还包括：

基于监控的各集群的运行信息，确定各集群对应的调整数据；所述调整数据包括扩缩信息以及调整数量；

根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量。

在一些可选的实施方式中，根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量，包括：

针对任一待调整集群，若所述扩缩信息表征缩容，则从所述待调整集群中释放所述调整数量的服务器到对应的资源池；

若所述扩缩信息表征扩容，且对应的资源池中有所述调整数量的未被占用的服务器，则从对应的资源池中镜像所述调整数量的服务器，并将镜像的服务器部署到所述待调整集群中；或者，若所述扩缩信息表征扩容，且对应的资源池中没有所述调整数量的未被占用的服务器，则在对应的资源池中生成所述调整数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述待调整集群中。

在一些可选的实施方式中，基于监控的各集群的运行信息，确定各集群对应的调整数据，包括：

针对任一集群，根据所述运行信息中中央处理器(Central Processing Unit，CPU)指标确定CPU状态；

若所述CPU状态为繁忙，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若所述CPU状态为正常，则根据所述运行信息中虚拟机(Java Virtual Machine，JVM)指标确定所述集群对应的扩缩信息以及调整数量；

若所述CPU状态为空闲，则根据预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，若CPU指标包括CPU利用率，则根据所述运行信息中CPU指标确定CPU状态，包括：

若所述CPU利用率大于第一利用率，则确定CPU状态为繁忙；

若所述CPU利用率小于第二利用率，则确定CPU状态为空闲；

若所述CPU利用率在所述第一利用率以及所述第二利用率之间的范围内，则确定CPU状态为正常；

其中，所述第一利用率大于所述第二利用率。

在一些可选的实施方式中，若CPU指标包括CPU等待信息，则根据所述运行信息中CPU指标确定CPU状态，包括：

若所述CPU等待信息大于第一等待值，则确定CPU状态为繁忙；

若所述CPU等待信息小于第二等待值，则确定CPU状态为空闲；

若所述CPU等待信息在所述第一等待值以及所述第二等待值之间的范围内，则确定CPU状态为正常；

其中，所述第一等待值大于所述第二等待值。

在一些可选的实施方式中，若所述JVM指标包括第一预设时长内的内存回收时长以及内存回收次数，则根据所述运行信息中JVM指标确定所述集群对应的扩缩信息以及调整数量，包括：

若第一预设时长内的内存回收时长大于第一时长，且内存回收次数大于第一次数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第一预设时长内的内存回收时长小于第二时长，且内存回收次数小于第二次数，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第一预设时长内的内存回收时长在所述第一时长以及所述第二时长之间的范围内，且内存回收次数在所述第一次数以及所述第二次数之间的范围内，则根据所述运行信息中系统吞吐量(Transactions Per Second，TPS)指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一时长大于所述第二时长，且所述第一次数大于第二次数。

在一些可选的实施方式中，若所述JVM指标包括第二预设时长内的运行线程占比峰值以及堵塞线程数量，则根据所述运行信息中JVM指标确定所述集群对应的扩缩信息以及调整数量，包括：

若第二预设时长内的运行线程占比峰值大于第一比例，或者堵塞线程数量大于第一数量，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第二预设时长内的运行线程占比峰值小于第二比例，或者堵塞线程数量小于第二数量，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第二预设时长内的运行线程占比峰值在所述第一比例以及所述第二比例之间的范围内，或者堵塞线程数量在所述第一数量以及所述第二数量之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一比例大于第二比例，且所述第一数量大于第二数量。

在一些可选的实施方式中，若所述TPS指标包括第三预设时长内的TPS峰值以及请求响应平均时长，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量，包括：

若第三预设时长内的TPS峰值大于预设吞吐量，且请求响应平均时长大于第三时长，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第三预设时长内的TPS峰值小于等于所述预设吞吐量，且请求响应平均时长小于等于所述第三时长，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量，包括：

将所述各待调整集群对应的调整数据发送至Git Repo(一种代码托管平台)，通过所述Git Repo对所述各待调整集群对应的调整数据进行托管；

通过Tekton CD(一种原生开源框架)将从所述Git Repo获取的所述各待调整集群对应的调整数据，生成各待调整集群对应的目标格式的报文；

通过云原生k8s系统将从所述Tekton CD获取的各待调整集群对应的目标格式的报文进行解析，并将解析后的数据进行编排，按照次序通过云原生k8s系统中k8s组件，调整对应待调整集群中服务器的数量。

第二方面，本申请实施例提供一种数据处理装置，包括：

接收模块，用于接收目标数据服务API的数据请求；

确定模块，用于根据建立的数据服务API以及资源组之间的第一对应关系，确定所述目标数据服务API对应的目标资源组；

确定模块，还用于根据资源组与集群之间的第二对应关系，确定所述目标资源组对应的目标集群；

处理模块，用于通过所述目标集群，对所述数据请求进行数据处理。

在一些可选的实施方式中，相同场景的集群放置在同一环境池中。

在一些可选的实施方式中，还包括创建模块，用于在接收模块接收目标数据服务API的数据请求之前，响应于所述目标数据服务API创建指令，建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系。

在一些可选的实施方式中，若所述目标资源组不是已有的资源组，则所述创建模块在建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系之前，还用于：

创建所述目标资源组。

在一些可选的实施方式中，所述创建模块在创建所述目标资源组之后，还用于：

确定所述目标集群对应的初始数量的服务器；

根据所述初始数量的服务器，构建所述目标集群；

建立所创建的目标资源组与所述目标集群之间的第二对应关系。

在一些可选的实施方式中，所述创建模块，具体用于：

若所述目标集群对应的资源池中有所述初始数量的未被占用的服务器，则从对应的资源池中镜像所述初始数量的服务器，并将镜像的服务器部署到所述目标集群中；

若所述目标集群对应的资源池没有所述初始数量的未被占用的服务器，则在对应的资源池中生成所述初始数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述目标集群中。

在一些可选的实施方式中，处理模块在通过所述目标集群，对所述数据请求进行数据处理之后，还用于：

确定处理所述数据请求的目标集群中的服务器的处理结果，并通过所述目标数据服务API返回所述处理结果。

在一些可选的实施方式中，还包括调整模块，用于：

基于监控的各集群的运行信息，确定各集群对应的调整数据；所述调整数据包括扩缩信息以及调整数量；

根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量。

在一些可选的实施方式中，所述调整模块，具体用于：

针对任一待调整集群，若所述扩缩信息表征缩容，则从所述待调整集群中释放所述调整数量的服务器到对应的资源池；

若所述扩缩信息表征扩容，且对应的资源池中有所述调整数量的未被占用的服务器，则从对应的资源池中镜像所述调整数量的服务器，并将镜像的服务器部署到所述待调整集群中；或者，若所述扩缩信息表征扩容，且对应的资源池中没有所述调整数量的未被占用的服务器，则在对应的资源池中生成所述调整数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述待调整集群中。

在一些可选的实施方式中，所述调整模块，具体用于：

针对任一集群，根据所述运行信息中CPU指标确定CPU状态；

若所述CPU状态为繁忙，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若所述CPU状态为正常，则根据所述运行信息中JVM指标确定所述集群对应的扩缩信息以及调整数量；

若所述CPU状态为空闲，则根据预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，若CPU指标包括CPU利用率，则所述调整模块，具体用于：

若所述CPU利用率大于第一利用率，则确定CPU状态为繁忙；

若所述CPU利用率小于第二利用率，则确定CPU状态为空闲；

若所述CPU利用率在所述第一利用率以及所述第二利用率之间的范围内，则确定CPU状态为正常；

其中，所述第一利用率大于所述第二利用率。

在一些可选的实施方式中，若CPU指标包括CPU等待信息，则所述调整模块，具体用于：

若所述CPU等待信息大于第一等待值，则确定CPU状态为繁忙；

若所述CPU等待信息小于第二等待值，则确定CPU状态为空闲；

若所述CPU等待信息在所述第一等待值以及所述第二等待值之间的范围内，则确定CPU状态为正常；

其中，所述第一等待值大于所述第二等待值。

在一些可选的实施方式中，若所述JVM指标包括第一预设时长内的内存回收时长以及内存回收次数，则所述调整模块，具体用于：

若第一预设时长内的内存回收时长大于第一时长，且内存回收次数大于第一次数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第一预设时长内的内存回收时长小于第二时长，且内存回收次数小于第二次数，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第一预设时长内的内存回收时长在所述第一时长以及所述第二时长之间的范围内，且内存回收次数在所述第一次数以及所述第二次数之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一时长大于所述第二时长，且所述第一次数大于第二次数。

在一些可选的实施方式中，若所述JVM指标包括第二预设时长内的运行线程占比峰值以及堵塞线程数量，则所述调整模块，具体用于：

若第二预设时长内的运行线程占比峰值大于第一比例，或者堵塞线程数量大于第一数量，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第二预设时长内的运行线程占比峰值小于第二比例，或者堵塞线程数量小于第二数量，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第二预设时长内的运行线程占比峰值在所述第一比例以及所述第二比例之间的范围内，或者堵塞线程数量在所述第一数量以及所述第二数量之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一比例大于第二比例，且所述第一数量大于第二数量。

在一些可选的实施方式中，若所述TPS指标包括第三预设时长内的TPS峰值以及请求响应平均时长，则所述调整模块，具体用于：

若第三预设时长内的TPS峰值大于预设吞吐量，且请求响应平均时长大于第三时长，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第三预设时长内的TPS峰值小于等于所述预设吞吐量，且请求响应平均时长小于等于所述第三时长，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，所述调整模块，具体用于：

将所述各待调整集群对应的调整数据发送至Git Repo，通过所述Git Repo对所述各待调整集群对应的调整数据进行托管；

通过Tekton CD将从所述Git Repo获取的所述各待调整集群对应的调整数据，生成各待调整集群对应的目标格式的报文；

通过云原生k8s系统将从所述Tekton CD获取的各待调整集群对应的目标格式的报文进行解析，并将解析后的数据进行编排，按照次序通过云原生k8s系统中k8s组件，调整对应待调整集群中服务器的数量。

第三方面，本申请实施例提供一种电子设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行如上述第一方面任一项所述的数据处理方法。

第四方面，本申请实施例提供一种存储介质，其存储有可由电子设备执行的计算机程序，当所述程序在所述电子设备上运行时，使得所述电子设备执行如上述第一方面任一项所述的数据处理方法。

本申请实施例提供的数据处理方法、装置、电子设备以及存储介质，具有以下有益效果：

本申请实施例建立了数据服务API与资源组之间的第一对应关系，以及资源组与集群之间的第二对应关系，即通过资源组实现了数据服务API与集群之间的关联，资源组所对应的数据服务API，均部署到同一个集群下，也就是说同一资源组所对应的目标数据服务API的数据请求均由同一集群处理，不同资源组所对应的目标数据服务API的数据请求由不同的集群各自处理，由于集群之间是相互独立的，因此实现了不同资源组对应的数据之间的隔离，从而避免了数据污染的问题。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1是本申请实施例提供的应用场景示意图；

图2是本申请实施例提供的第一种数据服务API、资源组以及集群之间的对应关系示意图；

图3是本申请实施例提供的第一种数据处理方法流程示意图；

图4是本申请实施例提供的容器池和环境池示意图；

图5是本申请实施例提供的第二种数据处理方法流程示意图；

图6是本申请实施例提供的第二种数据服务API、资源组以及集群之间的对应关系示意图；

图7是本申请实施例提供的第三种数据服务API、资源组以及集群之间的对应关系示意图；

图8是本申请实施例提供的一种集群中服务器数量调整方法的流程示意图；

图9是本申请实施例提供的云原生系统架构图；

图10是本申请实施例提供的数据处理装置示意图；

图11是本申请实施例提供的电子设备结构示意图；

图12是本申请实施例提供的程序产品示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本申请的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本申请可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

在本文中，需要理解的是，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本申请的若干代表性实施方式，详细阐释本申请的原理和精神。

数据服务作为统一数据中台建设的最上层，能够将数据仓库数据以服务化、接口化的方式提供给数据使用方，屏蔽底层数据存储、计算的诸多细节，简化和加强数据的使用；同时避免烟囱式建设、加强数据API的开发和交付效率，提升数据利用率。现有技术中，采用Kubernets+docker的技术，基于云主机搭建宿主机进行容器化部署，为用户提供数据服务。

在实施中，经常需要进行数据隔离，以避免数据之间存在污染。然而上述方案容器化后整个容器是一体的，容器内没有进行数据隔离，存在数据污染的问题。

鉴于此，本申请实施例提供了一种数据处理方法、装置、电子设备以及存储介质，本申请实施例建立了数据服务API与资源组之间的第一对应关系，以及资源组与集群之间的第二对应关系，即通过资源组实现了数据服务API与集群之间的关联，资源组所对应的数据服务API，均部署到同一个集群下，也就是说同一资源组所对应的目标数据服务API的数据请求均由同一集群处理，不同资源组所对应的目标数据服务API的数据请求由不同的集群各自处理，由于集群之间是相互独立的，因此实现了不同资源组对应的数据之间的隔离，从而避免了数据污染的问题。

在介绍了本申请的基本原理之后，下面具体介绍本申请的各种非限制性实施方式。

本申请实施例提供的数据处理方法可应用于图1所示的场景，参阅图1所示，数据服务作为统一数据中台建设的最上层，将数据仓库数据以服务化、接口化的方式提供给业务系统。

云原生系统接收目标数据服务API的数据请求后，根据建立的数据服务API以及资源组之间的第一对应关系，确定该目标数据服务API对应的目标资源组；之后根据资源组与集群之间的第二对应关系，确定上述目标资源组对应的目标集群；再通过该目标集群，对上述数据请求进行数据处理。

上述云原生系统，是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps(开发和运维组合)等技术为基础建立的一套云技术产品体系。

参阅图2所示，上述第一对应关系为至少一个数据服务API对应一个资源组，上述第二对应关系为一个资源组对应一个集群。图2中的资源组1所对应的数据服务API101、数据服务API102以及数据服务API103，部署到资源组1所对应的集群1下；资源组2所对应的数据服务API201以及数据服务API202，部署到资源组2所对应的集群2下。

资源组1所对应的3个数据服务API的数据请求由集群1处理，资源组2所对应的2个数据服务API的数据请求由集群2处理，集群1与集群2之间是相互独立的，因此资源组1和资源组2的数据之间相互隔离。

可以理解，图2只是示例性说明第一对应关系以及第二对应关系的一种可能的实现方式，本申请对此不做具体限定。

图3是根据一示例性实施例示出的第一种数据处理方法的流程示意图，该方法包括以下步骤：

步骤S301：接收目标数据服务API的数据请求。

参阅图1所示，通过数据服务API可以发送多种类型的数据请求，如简单查询服务、复杂查询服务或者混合查询服务等。

步骤S302：根据建立的数据服务API以及资源组之间的第一对应关系，确定所述目标数据服务API对应的目标资源组。

本实施例，建立了数据服务API与资源组之间的第一对应关系，因此，可以根据该第一对应关系，确定上述目标数据服务API所对应的目标资源组。还是以上述图2为例：

如果目标数据服务API为上述数据服务API101、数据服务API102或者数据服务API103，目标资源组为上述资源组1；如果目标数据服务API为上述数据服务API201或者数据服务API202，目标资源组为上述资源组2。

上述示例只是以图2为例对如何确定目标资源组进行说明，本申请对此不做具体限定。

步骤S303：根据资源组与集群之间的第二对应关系，确定所述目标资源组对应的目标集群。

本实施例，还建立了资源组与集群之间的第二对应关系，因此，可以根据该第二对应关系，确定上述目标资源组所对应的目标集群。还是以上述图2为例：

如果目标资源组为资源组1，目标集群就是上述集群1；如果目标资源组为资源组2，目标集群就是上述集群2。

上述示例只是以图2为例对如何确定目标集群进行说明，本申请对此不做具体限定。

步骤S304：通过所述目标集群，对所述数据请求进行数据处理。

上述方案，建立了数据服务API与资源组之间的第一对应关系，以及资源组与集群之间的第二对应关系，即通过资源组实现了数据服务API与集群之间的关联，资源组所对应的数据服务API，均部署到同一个集群下，也就是说同一资源组所对应的目标数据服务API的数据请求均由同一集群处理，不同资源组所对应的目标数据服务API的数据请求由不同的集群各自处理，由于集群之间是相互独立的，因此实现了不同资源组对应的数据之间的隔离，从而避免了数据污染的问题。

一些可选的实施方式中，通过目标集群，对数据请求进行数据处理之后，还需要确定处理该数据请求的目标集群中的服务器的处理结果，并通过上述目标数据服务API返回上述处理结果(如用户查询的数据等)，从而响应于用户的数据请求。

实施中，有时需要在不同场景下进行数据隔离，基于此，在一些可选的实施方式中，相同场景的集群放置在同一环境池中。具体的，容器池内设置有多个环境池，每个环境池对应一种场景。

参阅图4所示，容器池中设置两个环境池：开发环境池以及测试环境池。集群A、集群B、集群C都属于开发环境的集群，放置在开发环境池中；集群D、集群E、集群F都属于测试环境的集群，放置在测试环境池中。

上述图4只是以两个环境池为例进行说明，实际应用中可以设置更多的环境池。

上述方案，通过将相同场景的集群放置在同一环境池中，不仅进行了数据隔离，还针对不同场景，进行了环境隔离。

针对任一数据服务API，在接收该数据服务API的数据请求之前，需要先建立其与资源组，该资源组与集群之间的对应关系。基于此，图5是根据一示例性实施例示出的第二种数据处理方法的流程示意图，该方法包括以下步骤：

步骤S501：响应于所述目标数据服务API创建指令，建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系。

一些实施例中，目标资源组可能是已有的资源组，这时就可以直接建立目标数据服务API与已有的目标资源组之间的第一对应关系；

另外一些实施例中，目标资源组可能不是已有的资源组，这时需要先创建目标资源组，才能建立目标数据服务API与创建的目标资源组之间的第一对应关系。

如果目标资源组不是已有的资源组，其与集群的对应关系还没有建立。基于此，在一些可选的实施方式中，创建所述目标资源组之后，还包括以下步骤：

确定所述目标集群对应的初始数量的服务器；

根据所述初始数量的服务器，构建所述目标集群；

建立所创建的目标资源组与所述目标集群之间的第二对应关系。

上述根据所述初始数量的服务器，构建所述目标集群，可通过但不限于如下方式实现：

1)若所述目标集群对应的资源池中有所述初始数量的未被占用的服务器，则从对应的资源池中镜像所述初始数量的服务器，并将镜像的服务器部署到所述目标集群中；

上述资源池包括图4所示的环境池和/或容器池。

示例性的，采用并行优先模式，预先生成一定数量的服务器在资源池中，例如：可以在上述容器池中生成第三数量的服务器；或者在各环境池分别生成第四数量的服务器；或者既在上述容器池中生成第三数量的服务器，又在各环境池分别生成第四数量的服务器。环境池中的服务器可以被对应环境的集群占用，容器池中的服务器可以被各环境的集群占用。下面以目标集群对应5个服务器(即需要在目标集群中部署5个服务器)，且对应测试环境为例，对不同的情况分别进行说明：

第一种情况

测试环境池中有10个未被占用的服务器，直接从测试环境池中镜像5个服务器，再将镜像的服务器部署到上述目标集群中。

第二种情况

测试环境池中有2个未被占用的服务器，容器池中有20个未被占用的服务器，从测试环境池中镜像2个服务器，并从容器池中镜像3个服务器，再将镜像的服务器部署到上述目标集群中；或者直接从容器池中镜像5个服务器，再将镜像的服务器部署到上述目标集群中。

第三种情况

测试环境池中没有未被占用的服务器，容器池中有20个未被占用的服务器，直接从容器池中镜像5个服务器，再将镜像的服务器部署到上述目标集群中。

本实施例只是对上述三种情况进行了示例性说明，实际应用中可能会出现其他的情况，此处不再一一举例。

2)若所述目标集群对应的资源池没有所述初始数量的未被占用的服务器，则在对应的资源池中生成所述初始数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述目标集群中。

示例性的，采用响应优先模式，集群需要服务器时，才会在资源池中生成所需数量的服务器，以便镜像生成的服务器，并部署到对应的集群中。

还是以上述图2为例：

如果新创建的数据服务API104，所对应的目标资源组为已有的资源组1，这时无需再创建资源组1，建立数据服务API104与资源组1之间的第一对应关系即可。

另外，由于资源组1是已有的资源组，其与集群的对应关系已经建立，不需要再创建集群1，也不需要再建立资源组1与集群1之间的第二对应关系。

此时数据服务API、资源组以及集群之间的对应关系可参阅图6所示。

如果新创建的数据服务API301，所对应的目标资源组为资源组3(不是已有的资源组)，先创建资源组3，再建立数据服务API301与资源组3之间的第一对应关系。

另外，由于资源组3不是已有的资源组，其与集群的对应关系还没建立，需要先创建集群3(创建集群的过程可参照上述实施例)，进而建立资源组3与集群3之间的第二对应关系。

此时数据服务API、资源组以及集群之间的对应关系可参阅图7所示。

上述两个示例只是为了更清楚地说明如何建立第一对应关系以及第二对应关系，本实施例并不以此为限。

实施中，在创建新的集群后，可返回集群的标识。其中，集群的标识可以根据实际应用场景设置，如将应用名称-机房信息-环境信息作为集群的标识，集群中的服务器会动态的匹配到Nginx(一种网站服务器)的upstream(上游)，对外利用域名访问Nginx，实现数据访问。

步骤S502：接收目标数据服务API的数据请求。

步骤S503：根据建立的数据服务API以及资源组之间的第一对应关系，确定所述目标数据服务API对应的目标资源组。

步骤S504：根据资源组与集群之间的第二对应关系，确定所述目标资源组对应的目标集群。

步骤S505：通过所述目标集群，对所述数据请求进行数据处理。

该步骤S502～505的具体实现方式可参照上述实施例，此处不再赘述。

如上所述，需要通过各集群中的服务器对所对应的数据请求进行数据处理，由于每个数据服务API的数据请求的数量不同，请求类型不同，集群中的服务器使用情况也不同，有些集群中服务器数量比较多，但需要处理的数据请求较少，就会造成服务器的资源浪费；有些集群中服务器数量比较少，但需要处理的数据请求较多，就会造成服务器的性能较差。

如果手动设置集群中的服务器数量，可能会无法及时、合理地调整各集群中的服务器数量，基于此，在上述实施例的基础上，图8示出一种集群中服务器数量调整方法的流程示意图，该方法包括以下步骤：

步骤S801：基于监控的各集群的运行信息，确定各集群对应的调整数据；所述调整数据包括扩缩信息以及调整数量。

本实施例，各集群的运行信息表征了服务器的使用情况，即各集群中服务器对数据请求的处理情况，基于此可以确定如何对各集群中的服务器的数量进行调整，如：集群是否需要扩容(增加服务器)，在需要增加服务器时增加的数量；以及集群是否需要缩容(减少服务器)，在需要减少服务器时减少的数量。

本实施例对上述运行信息不做具体限定，如可以包括CPU指标、JVM指标以及TPS指标中的至少一项。

本实施例对获取上述监控的各集群的运行信息的具体实现方式不做限定，如通过消息中间件获取监控设备监控的各集群的运行信息。

步骤S802：根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量。

上述监控的集群中，可能有些集群的扩缩信息表征扩容，也可能有些集群的扩缩信息表征缩容，对于这两类集群来说都是需要调整服务器数量的待调整集群，需要根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量。

上述方案，基于监控的各集群的运行信息，实时确定出各集群对应的扩缩信息以及调整数量；进而根据该各待调整集群对应的扩缩信息以及调整数量，及时、合理地调整对应待调整集群中服务器的数量，在集群中服务器不能满足数据请求时，通过及时扩容，减少了服务器的性能较差的情况；在集群中服务器数量比较多，但需要处理的数据请求较少时，通过及时缩容，减少了服务器的资源浪费的情况，提高了服务的稳定性和可用性，实现资源的合理利用。

一些可选的实施方式中，上述步骤S801可通过但不限于如下方式实现：

针对任一集群，根据所述运行信息中CPU指标确定CPU状态；

若所述CPU状态为繁忙，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若所述CPU状态为正常，则根据所述运行信息中JVM指标确定所述集群对应的扩缩信息以及调整数量；

若所述CPU状态为空闲，则根据预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

其中，上述CPU指标可以包括CPU利用率，对应的，可通过以下方式确定CPU状态：

若所述CPU利用率大于第一利用率，则确定CPU状态为繁忙；

若所述CPU利用率小于第二利用率，则确定CPU状态为空闲；

若所述CPU利用率在所述第一利用率以及所述第二利用率之间的范围内，则确定CPU状态为正常；

其中，所述第一利用率大于所述第二利用率。

由于第一利用率大于第二利用率，如果集群中CPU利用率比第一利用率还大，说明该集群中CPU利用率过高，确定CPU状态为繁忙；如果集群中CPU利用率比第二利用率还小，说明该集群中CPU利用率过低，确定CPU状态为空闲；如果CPU利用率在第一利用率以及第二利用率之间的范围内，说明当前的CPU利用率较为合适，确定CPU状态为正常。

具体的，上述CPU利用率可以为95％的CPU利用率。

上述第一利用率以及第二利用率可以根据实际应用场景设定，例如第一利用率为0.5，第二利用率为0.2，本申请对此不做具体限定。

上述CPU指标也可以包括CPU等待信息，对应的，可通过以下方式确定CPU状态：

若所述CPU等待信息大于第一等待值，则确定CPU状态为繁忙；

若所述CPU等待信息小于第二等待值，则确定CPU状态为空闲；

若所述CPU等待信息在所述第一等待值以及所述第二等待值之间的范围内，则确定CPU状态为正常；

其中，所述第一等待值大于所述第二等待值。

由于第一等待值大于第二等待值，如果集群中CPU等待信息比第一等待值还大，说明该集群中CPU等待信息过大，确定CPU状态为繁忙；如果集群中CPU等待信息比第二等待值还小，说明该集群中CPU等待信息过小，确定CPU状态为空闲；如果CPU等待信息在第一等待值以及第二等待值之间的范围内，说明当前的CPU等待信息较为合适，确定CPU状态为正常。

具体的，上述CPU等待信息可以为95％的CPU低等待值。

上述第一等待值以及第二等待值可以根据实际应用场景设定，例如第一等待值为0.3，第二等待值为0.1，本申请对此不做具体限定。

其中，上述JVM指标可以包括第一预设时长内的内存回收时长以及内存回收次数，对应的，可通过以下方式根据JVM指标确定集群对应的扩缩信息以及调整数量：

若第一预设时长内的内存回收时长大于第一时长，且内存回收次数大于第一次数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第一预设时长内的内存回收时长小于第二时长，且内存回收次数小于第二次数，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第一预设时长内的内存回收时长在所述第一时长以及所述第二时长之间的范围内，且内存回收次数在所述第一次数以及所述第二次数之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一时长大于所述第二时长，且所述第一次数大于第二次数。

由于第一时长大于第二时长，且第一次数大于第二次数，如果第一预设时长内的内存回收时长大于第一时长，且内存回收次数大于第一次数，说明该集群中内存回收过于频繁，需要增加集群中服务器的数量，因此确定集群对应的扩缩信息表征扩容，调整数量为所述集群中当前的服务器数量的预设倍数，以减少该集群中内存回收的时长和次数；如果第一预设时长内的内存回收时长小于第二时长，且内存回收次数小于第二次数，说明该集群中很少进行内存回收，需要根据上述预设条件确定调整数据；如果第一预设时长内不满足上述两种情况，说明该集群中内存回收正常，需要进一步根据TPS指标确定调整数据。

上述第一时长、第二时长、第一次数以及第二次数可以根据实际应用场景设定，例如第一时长为20ms，第二时长为10ms，第一次数为10次，第二次数为2次，本申请对此不做具体限定。

上述JVM指标也可以包括第二预设时长内的运行线程占比峰值以及堵塞线程数量，对应的，可通过以下方式根据JVM指标确定集群对应的扩缩信息以及调整数量：

若第二预设时长内的运行线程占比峰值大于第一比例，或者堵塞线程数量大于第一数量，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第二预设时长内的运行线程占比峰值小于第二比例，或者堵塞线程数量小于第二数量，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第二预设时长内的运行线程占比峰值在所述第一比例以及所述第二比例之间的范围内，或者堵塞线程数量在所述第一数量以及所述第二数量之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一比例大于第二比例，且所述第一数量大于第二数量。

由于第一比例大于第二比例，且第一数量大于第二数量，如果第二预设时长内运行线程占比峰值大于第一比例，说明该集群中运行线程过多，如果堵塞线程数量大于第一数量，说明该集群中出现大量堵塞线程，需要增加集群中服务器的数量，以减少该集群中运行线程、堵塞线程；如果第一预设时长内的运行线程占比峰值小于第二比例，说明该集群中运行线程过少，如果堵塞线程数量小于第二数量，说明该集群中基本没有堵塞线程，需要根据上述预设条件确定调整数据；如果第二预设时长内不满足上述两种情况，说明该集群中线程正常，需要进一步根据TPS指标确定调整数据。

上述第一比例、第二比例、第一数量以及第二数量可以根据实际应用场景设定，例如第一比例为50％，第二比例为30％，第一数量为10个，第二数量为0个，本申请对此不做具体限定。

一些可选的实施方式中，上述TPS指标包括第三预设时长内的TPS峰值以及请求响应平均时长，可通过但不限于以下方式根据TPS指标确定集群对应的扩缩信息以及调整数量：

若第三预设时长内的TPS峰值大于预设吞吐量，且请求响应平均时长大于第三时长，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第三预设时长内的TPS峰值小于等于所述预设吞吐量，且请求响应平均时长小于等于所述第三时长，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

如果第三预设时长内TPS峰值大于预设吞吐量，且请求响应平均时长大于第三时长，说明该集群中TPS吞吐量过高，请求响应速度慢，需要增加集群中服务器的数量，以降低TPS吞吐量，提高请求响应速度；如果第三预设时长内的TPS峰值小于等于预设吞吐量，且请求响应平均时长小于等于第三时长，说明该集群中TPS吞吐量正常，请求响应速度也正常，需要根据上述预设条件确定调整数据。

上述预设吞吐量以及第三时长可以根据实际应用场景设定，例如预设吞吐量为1000个/s，第三时长为1000ms，本申请对此不做具体限定。

上述第一预设时长、第二预设时长以及第三预设时长可以相同，可以不同，本申请对此不做具体限定。

一些示例性的实施方式中，上述预设条件可以为以下公式：

调整值C＝{(M*K/T)+L-N}，M为第四预设时长内的TPS峰值，K为所述集群的服务类型对应的放大倍数，T为所述集群中服务器的平均TPS值，L为所述集群对应的调整系数，N为所述集群中当前的服务器数量，{}为取整运算，T＝M/N。

其中，上述集群对应的调整系数L受上述CPU指标以及JVM指标影响，示例性的，其他参数相同时，CPU利用率越大，L越大；其他参数相同时，CPU等待信息越大，L越大；其他参数相同时，内存回收时长、内存回收次数越大，L越大；其他参数相同时，运行线程占比峰值、堵塞线程数量越大，L越大。

上述第四预设时长可以根据实际应用场景设定，例如第四预设时长为7天，本申请对此不做具体限定。

上述集群的服务类型对应的放大倍数K＝F+1，其中F为流量比，受集群的服务类型影响，例如：集群处理超文本传输协议(Hyper Text Transfer Protocol，HTTP)数据时，F＝3/7；集群处理远程过程调用(Remote Procedure Call，RPC)数据时，F＝4/6。

下面一个具体的示例进行说明：

第四预设时长为7天，M＝1200个/s，集群中当前有3个服务器数量，且集群处理HTTP数据，对应的放大倍数为1.43，集群对应的调整系数为1.5；

(M*K/T)+L-N＝(1200*1.43/400)+1.5-N＝2.786。

由于服务器的数量为整数，因此需要对上述计算结果进行取整运算，最终确定调整值为3。调整值为正数，因此集群对应的扩缩信息表征扩容，且集群对应的调整数量为3。

上述示例只是根据预设条件确定调整值的一种可能的实现方式，本申请并不以此为限。

一些可选的实施方式中，步骤S802可通过但不限于如下方式实现：

针对任一待调整集群，若所述扩缩信息表征缩容，则从所述待调整集群中释放所述调整数量的服务器到对应的资源池；

若所述扩缩信息表征扩容，且对应的资源池中有所述调整数量的未被占用的服务器，则从对应的资源池中镜像所述调整数量的服务器，并将镜像的服务器部署到所述待调整集群中；或者，若所述扩缩信息表征扩容，且对应的资源池中没有所述调整数量的未被占用的服务器，则在对应的资源池中生成所述调整数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述待调整集群中。

上述扩容过程与上述根据初始数量的服务器构建目标集群的过程类似，此处不再赘述。

如上所述，上述资源池包括环境池和/或容器池。

如果扩缩信息表征缩容，从待调整集群中释放调整数量的服务器到该待调整集群所在的环境池中，或者从待调整集群中释放调整数量的服务器到容器池中。

应用于如图9所示的云原生系统，可通过以下方式确定调整对应待调整集群中服务器的数量：

将所述各待调整集群对应的调整数据发送至Git Repo，通过所述Git Repo对所述各待调整集群对应的调整数据进行托管；

通过Tekton CD将从所述Git Repo获取的所述各待调整集群对应的调整数据，生成各待调整集群对应的目标格式的报文；

通过云原生k8s系统将从所述Tekton CD获取的各待调整集群对应的目标格式的报文进行解析，并将解析后的数据进行编排，按照次序通过云原生k8s系统中k8s组件，调整对应待调整集群中服务器的数量。

示例性的，Pipeline(管线)由多个Task(任务)组成，在进行扩容或者构建目标集群时，通过调度执行生成一条PipelineRun(调用Pipeline的函数)，其控制的TaskRun(调用Task的函数)将根据容器初始化模式创建服务器。

一些可选的实施方式中，还可配置表征开启或者关闭的信息，以便根据实际应用需求，应用上述动态调整集群中服务器的数量的机制。例如：通过配置表征开启的信息，应用上述动态调整集群中服务器的数量的机制；通过配置表征关闭的信息，不应用上述动态调整集群中服务器的数量的机制。

基于同一发明构思，本申请实施例中还提供了一种数据处理装置，该数据处理装置实施例可以继承前述方法实施例描述的内容。基于上述实施例，如图10所示为本申请实施例提供的一种数据处理装置的结构示意图，该数据处理装置1000具体包括：

接收模块1001，用于接收目标数据服务API的数据请求；

确定模块1002，用于根据建立的数据服务API以及资源组之间的第一对应关系，确定所述目标数据服务API对应的目标资源组；

确定模块1002，还用于根据资源组与集群之间的第二对应关系，确定所述目标资源组对应的目标集群；

处理模块1003，用于通过所述目标集群，对所述数据请求进行数据处理。

在一些可选的实施方式中，相同场景的集群放置在同一环境池中。

在一些可选的实施方式中，还包括创建模块1004，用于在接收模块接收目标数据服务API的数据请求之前，响应于所述目标数据服务API创建指令，建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系。

在一些可选的实施方式中，若所述目标资源组不是已有的资源组，则所述创建模块1004在建立所创建的目标数据服务API与所述目标资源组之间的第一对应关系之前，还用于：

创建所述目标资源组。

在一些可选的实施方式中，所述创建模块1004在创建所述目标资源组之后，还用于：

确定所述目标集群对应的初始数量的服务器；

根据所述初始数量的服务器，构建所述目标集群；

建立所创建的目标资源组与所述目标集群之间的第二对应关系。

在一些可选的实施方式中，所述创建模块1004，具体用于：

若所述目标集群对应的资源池中有所述初始数量的未被占用的服务器，则从对应的资源池中镜像所述初始数量的服务器，并将镜像的服务器部署到所述目标集群中；

若所述目标集群对应的资源池没有所述初始数量的未被占用的服务器，则在对应的资源池中生成所述初始数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述目标集群中。

在一些可选的实施方式中，处理模块1003在通过所述目标集群，对所述数据请求进行数据处理之后，还用于：

确定处理所述数据请求的目标集群中的服务器的处理结果，并通过所述目标数据服务API返回所述处理结果。

在一些可选的实施方式中，还包括调整模块1005，用于：

基于监控的各集群的运行信息，确定各集群对应的调整数据；所述调整数据包括扩缩信息以及调整数量；

根据各待调整集群对应的调整数据，调整对应待调整集群中服务器的数量。

在一些可选的实施方式中，所述调整模块1005，具体用于：

针对任一待调整集群，若所述扩缩信息表征缩容，则从所述待调整集群中释放所述调整数量的服务器到对应的资源池；

若所述扩缩信息表征扩容，且对应的资源池中有所述调整数量的未被占用的服务器，则从对应的资源池中镜像所述调整数量的服务器，并将镜像的服务器部署到所述待调整集群中；或者，若所述扩缩信息表征扩容，且对应的资源池中没有所述调整数量的未被占用的服务器，则在对应的资源池中生成所述调整数量的服务器，从对应的资源池中镜像生成的所述服务器，并将镜像的服务器部署到所述待调整集群中。

在一些可选的实施方式中，所述调整模块1005，具体用于：

针对任一集群，根据所述运行信息中CPU指标确定CPU状态；

若所述CPU状态为繁忙，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若所述CPU状态为正常，则根据所述运行信息中JVM指标确定所述集群对应的扩缩信息以及调整数量；

若所述CPU状态为空闲，则根据预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，若CPU指标包括CPU利用率，则所述调整模块1005，具体用于：

若所述CPU利用率大于第一利用率，则确定CPU状态为繁忙；

若所述CPU利用率小于第二利用率，则确定CPU状态为空闲；

若所述CPU利用率在所述第一利用率以及所述第二利用率之间的范围内，则确定CPU状态为正常；

其中，所述第一利用率大于所述第二利用率。

在一些可选的实施方式中，若CPU指标包括CPU等待信息，则所述调整模块1005，具体用于：

若所述CPU等待信息大于第一等待值，则确定CPU状态为繁忙；

若所述CPU等待信息小于第二等待值，则确定CPU状态为空闲；

若所述CPU等待信息在所述第一等待值以及所述第二等待值之间的范围内，则确定CPU状态为正常；

其中，所述第一等待值大于所述第二等待值。

在一些可选的实施方式中，若所述JVM指标包括第一预设时长内的内存回收时长以及内存回收次数，则所述调整模块1005，具体用于：

若第一预设时长内的内存回收时长大于第一时长，且内存回收次数大于第一次数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第一预设时长内的内存回收时长小于第二时长，且内存回收次数小于第二次数，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第一预设时长内的内存回收时长在所述第一时长以及所述第二时长之间的范围内，且内存回收次数在所述第一次数以及所述第二次数之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一时长大于所述第二时长，且所述第一次数大于第二次数。

在一些可选的实施方式中，若所述JVM指标包括第二预设时长内的运行线程占比峰值以及堵塞线程数量，则所述调整模块1005，具体用于：

若第二预设时长内的运行线程占比峰值大于第一比例，或者堵塞线程数量大于第一数量，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第二预设时长内的运行线程占比峰值小于第二比例，或者堵塞线程数量小于第二数量，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0；

若第二预设时长内的运行线程占比峰值在所述第一比例以及所述第二比例之间的范围内，或者堵塞线程数量在所述第一数量以及所述第二数量之间的范围内，则根据所述运行信息中TPS指标确定所述集群对应的扩缩信息以及调整数量；

其中，所述第一比例大于第二比例，且所述第一数量大于第二数量。

在一些可选的实施方式中，若所述TPS指标包括第三预设时长内的TPS峰值以及请求响应平均时长，则所述调整模块1005，具体用于：

若第三预设时长内的TPS峰值大于预设吞吐量，且请求响应平均时长大于第三时长，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述集群中当前的服务器数量的预设倍数；

若第三预设时长内的TPS峰值小于等于所述预设吞吐量，且请求响应平均时长小于等于所述第三时长，则根据所述预设条件确定调整值；若所述调整值为正数，则确定所述集群对应的扩缩信息表征扩容，且所述集群对应的调整数量为所述调整值；若所述调整值为负数，则确定所述集群对应的扩缩信息表征缩容，且所述集群对应的调整数量为所述调整值的绝对值；若所述调整值为0，则确定所述集群对应的扩缩信息表征不扩缩，且所述集群对应的调整数量为0。

在一些可选的实施方式中，所述调整模块1005，具体用于：

将所述各待调整集群对应的调整数据发送至Git Repo，通过所述Git Repo对所述各待调整集群对应的调整数据进行托管；

通过Tekton CD将从所述Git Repo获取的所述各待调整集群对应的调整数据，生成各待调整集群对应的目标格式的报文；

通过云原生k8s系统将从所述Tekton CD获取的各待调整集群对应的目标格式的报文进行解析，并将解析后的数据进行编排，按照次序通过云原生k8s系统中k8s组件，调整对应待调整集群中服务器的数量。

由于该数据处理装置即是本申请实施例中的方法中的数据处理装置，并且该数据处理装置解决问题的原理与该方法相似，因此该数据处理装置的实施可以参见方法的实施，重复之处不再赘述。

下面参照图11来描述根据本申请的这种实施方式的电子设备1100。图11所示的电子设备仅仅是一个示例，不对本申请实施例的功能和使用范围带来任何限制。

如图11所示，电子设备1100以通用计算装置的形式表现。电子设备1100的组件可以包括但不限于：至少一个处理器1101、至少一个存储器1102、连接不同系统组件(包括存储器1102和处理器1101)的总线1103。

总线1103表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器1102可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)11021和/或高速缓存存储器11022，还可以进一步包括只读存储器(ROM)11023。

存储器1102还可以包括具有一组(至少一个)程序模块11024的程序/实用工具11025，这样的程序模块11024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备1100也可以与一个或多个外部设备1104(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与电子设备1100交互的设备通信，和/或与使得该电子设备1100能与一个或多个其它计算装置进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1105进行。并且，电子设备1100还可以通过网络适配器1106与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1106通过总线1103与用于电子设备1100的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备1100使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在本申请实施例中，存储器1102存储有计算机程序，当该程序被处理器1101执行时，使得处理器1101执行上述任一实施例中的方法。

由于该电子设备即是本申请实施例中的方法中的电子设备，并且该电子设备解决问题的原理与该方法相似，因此该电子设备的实施可以参见方法的实施，重复之处不再赘述。

在一些可能的实施方式中，本申请的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在电子设备上运行时，程序代码用于使电子设备的处理器执行上述任一种数据处理方法的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图12所示，描述了根据本申请的实施方式的程序产品1200，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在电子设备上执行、部分地在电子设备上执行、作为一个独立的软件包执行、部分在电子设备上部分在远程设备上执行、或者完全在远程设备上执行。在涉及远程设备的情形中，远程设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到电子设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了系统的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

此外，尽管在附图中以特定顺序描述了本申请系统各模块的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些操作，将多个操作合并为一个操作执行，和/或将一个操作分解为多个操作执行。

虽然已经参考若干具体实施方式描述了本申请的精神和原理，但是应该理解，本申请并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本申请旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。