应用容器管理方法、装置及设备

技术领域

本申请涉及金融科技(Fintech)技术领域，尤其涉及一种应用容器管理方法、装置及设备。

背景技术

容器是物理计算节点资源分配与调度的基本单元。随着容器技术的不断发展，新虚拟化技术为业务提供高效运行环境，实现虚拟资源在不同服务器上的统一。其基本原理是将多个服务器对应的虚拟资源切分为多个应用容器，使得开发者可以打包应用到一个可移植的容器中，并发布到任意一个计算机上，实现应用的容器化。

目前，在金融科技领域中，Kubernetes容器调度平台可管理单个集群中多个服务器上的应用容器，实现应用的部署、规划、更新以及维护。然而，Kubernetes容器调度平台无法实现跨集群管理应用容器，需要大量的标签标注和规则制定才能够完成业务量大的应用容器部署，导致规则的制定和维护困难较大，无法灵活扩展规则，也使得应用容器的部署成本增加。

发明内容

本申请实施例提供一种应用容器管理方法、装置及设备，实现了应用容器跨越集群部署在服务器上运行的过程，还降低了前期规则制定和后期规则维护的成本。

第一方面，本申请实施例提供一种应用容器管理方法，包括：

接收应用容器的分配需求信息，分配需求信息用于表示为部署应用容器对目标服务器的需求；

获取多个服务器中每个服务器的相关信息，多个服务器属于不同集群；

基于多个服务器中每个服务器的相关信息，按照与分配需求信息相关的预设规则，将多个服务器中的一个服务器确定为目标服务器；

通知应用容器在目标服务器上运行。

通过第一方面提供的方法，通过获取属于不同集群的多个服务器的相关信息，可将全部服务器的虚拟资源看成一个大的资源池。由此，基于多个服务器的相关信息，按照应用容器的分配需求信息对应的规则，可为应用容器从多个服务器中选择一个服务器为目标服务器，并向业务人员通知应用容器在目标服务器上运行。从而，实现了应用容器在属于不同集群中的多个服务器上的部署，打破了无法跨越集群的问题，且预设规则与应用容器的部署相关，不仅简化了规则的制定过程，替代了需要进行大量的标签标注和规则制定的地方，有利于规则的后续维护，降低了规则制定和维护的成本，还能够及时调整预设规则，允许业务人员增减规则以及调整规则的优先级，使得预设规则具备良好的扩展性。

在一种可能的设计中，分配需求信息包括：指定的系统名称、指定的部署范围、指定的硬件资源需求和指定的亲和性属性；

基于多个服务器中每个服务器的相关信息，按照与分配需求信息相关的预设规则，将多个服务器中的一个服务器确定为目标服务器，包括：

基于多个服务器中每个服务器的相关信息，将多个服务器中符合强制性分配规则的服务器确定为第一服务器集合；其中，强制性分配规则与指定的部署范围、指定的硬件资源需求和指定的亲和性属性相关；将第一服务器集合中符合高可用规则的服务器确定为第二服务器集合；其中，高可用规则与指定的部署范围和指定的系统名称相关；将第二服务器集合中的一个服务器确定为目标服务器。

由此，基于强制性分配规则和高可用规则等必须满足的规则，对属于不同集群中的多个服务器进行筛选，基于应用容器的分配需求信息，将应用容器可部署在匹配亲和性的服务器上，远离匹配反亲和性的服务器，还将应用容器所属的系统对应的实例能够更加分散，使得应用容器能够良好运行，便于后期维护应用容器的部署。

在一种可能的设计中，将多个服务器中符合强制性分配规则的服务器确定为第一服务器集合，包括：

针对多个服务器中的任意一个服务器，在服务器的物理位置符合指定的部署范围，服务器的硬件信息符合指定的硬件资源需求以及服务器的亲和性属性符合指定的亲和性属性时，确定服务器属于第一服务器集合。

由此，管理平台可将多个服务器中不满足强制性分配规则的服务器剔除掉，有利于快速为应用容器分配服务器，提高了部署的速度。

在一种可能的设计中，将第一服务器集合中符合高可用规则的服务器确定为第二服务器集合，包括：

针对第一服务器集合中的任意一个服务器，在满足s+1＜预设最少实例数，或者，s+1≥预设最少实例数且(n+1)/(s+1)≤预设最高占比时，确定服务器属于第二服务器集合；其中，n为指定的部署范围中包含的与指定的系统名称对应的系统的实例的数量，s为第一服务器集合中包含的与指定的系统名称对应的系统的实例的数量，n和s为自然数。

由此，管理平台基于高可用规则，可以将与应用容器对应的系统的实例类型相同的多个实例分散部署，以便在服务器出现故障、网络出现故障或者部署区域出现断电等场景下，其余正常运行且运行有与该实例类型相同的服务器能够承接全部实例，使得应用容器能够顺利在前述服务器上运行，确保相应业务能够顺利实现，满足了多实例、高可用的冗余要求。

在一种可能的设计中，将第二服务器集合中的一个服务器确定为目标服务器，包括：

在第二服务器集合中只存在一个服务器时，将服务器确定为目标服务器；在第二服务器集合中存在多个服务器时，将第二服务器集合中符合阶梯评分规则的服务器确定为第三服务器集合；其中，阶梯评分规则与分配需求信息相关；将第三服务器集合中的一个服务器确定为目标服务器。

由此，基于阶梯评分规则等尽量满足的规则，对必须满足的规则输出的服务器进行评分，得到更适合应用容器运行的服务器，有利于将资源池的资源剩余比例趋于平均，避免服务器的压力过大或资源浪费。

在一种可能的设计中，将第二服务器集合中符合阶梯评分规则的服务器确定为第三服务器集合，包括：

基于指定的部署范围、指定的系统名称和指定的亲和性属性，对第二服务器集合中的每个服务器进行评分，并将分数最高的服务器确定为第五服务器集合；将第五服务器集合中满足预设条件的服务器确定为第三服务器集合。

由此，管理平台可基于应用容器的需求，为应用容器精准匹配服务器。

在一种可能的设计中，基于指定的部署范围、指定的系统名称和指定的亲和性属性，对第二服务器集合中的每个服务器进行评分，并将分数最高的服务器确定为第五服务器集合，包括：

针对第二服务器集合中的任意一个服务器，在服务器的物理位置属于指定的部署范围的下i级时，确定服务器的分数为当前的分数-n，并更新i＝i+1，直至i＝m为止；将第二服务器集合中分数最高的服务器确定为第四服务器集合；其中，n为服务器中包含的与指定的系统名称对应的系统的实例的数量，i的初值为1，m为位于指定的部署范围之下的等级总数，n、i和m为自然数；

针对第四服务器集合中的任意一个服务器，在服务器的亲和性属性符合指定的亲和性属性时，确定服务器的分数为当前的分数+1；将第四服务器集合中分数最高的服务器确定为第五服务器集合。

由此，基于应用容器的分配需求信息中的部署范围、系统名称和亲和性属性，对服务器进行评分，能够确定出更加契合应用容器的需求的服务器。

在一种可能的设计中，部署范围的等级由高到低的顺序包括数据中心、逻辑分区、机列、机架以及服务器。

在一种可能的设计中，将第五服务器集合中满足预设条件的服务器确定为第三服务器集合，包括：

在a>c时，确定第五服务器集合中bj最小的服务器为第三服务器集合；在a

由此，基于应用容器的分配需求信息中的硬件资源需求，不仅能够确定出更加契合应用容器的需求的服务器，还能够均衡全部服务器的剩余资源趋于平均，避免服务器的压力过大或资源浪费。

在一种可能的设计中，任意一个服务器的相关信息包括：服务器的物理位置、硬件信息、剩余可用资源、包含的与各个系统名称对应的实例清单以及亲和性属性。

第二方面，本申请实施例提供一种应用容器管理装置，包括：接收模块，用于接收应用容器的分配需求信息，分配需求信息用于表示为部署应用容器对目标服务器的需求；获取模块，用于获取多个服务器中每个服务器的相关信息，所述多个服务器属于不同集群；确定模块，用于基于多个服务器中每个服务器的相关信息，按照与分配需求信息相关的预设规则，将多个服务器中的一个服务器确定为目标服务器；通知模块，用于通知应用容器在目标服务器上运行。

在一种可能的设计中，分配需求信息包括：指定的系统名称、指定的部署范围、指定的硬件资源需求和指定的亲和性属性；确定模块，用于基于多个服务器中每个服务器的相关信息，将多个服务器中符合强制性分配规则的服务器确定为第一服务器集合；其中，强制性分配规则与指定的部署范围、指定的硬件资源需求和指定的亲和性属性相关；将第一服务器集合中符合高可用规则的服务器确定为第二服务器集合；其中，高可用规则与指定的部署范围和指定的系统名称相关；将第二服务器集合中的一个服务器确定为目标服务器。

在一种可能的设计中，确定模块，具体用于针对多个服务器中的任意一个服务器，在服务器的物理位置符合指定的部署范围，服务器的硬件信息符合指定的硬件资源需求以及服务器的亲和性属性符合指定的亲和性属性时，确定服务器属于第一服务器集合。

在一种可能的设计中，确定模块，具体用于针对第一服务器集合中的任意一个服务器，在满足s+1＜预设最少实例数，或者，s+1≥预设最少实例数且(n+1)/(s+1)≤预设最高占比时，确定服务器属于第二服务器集合；其中，n为指定的部署范围中包含的与指定的系统名称对应的系统的实例的数量，s为第一服务器集合中包含的与指定的系统名称对应的系统的实例的数量，n和s为自然数。

在一种可能的设计中，确定模块，具体用于在第二服务器集合中只存在一个服务器时，将服务器确定为目标服务器；在第二服务器集合中存在多个服务器时，将第二服务器集合中符合阶梯评分规则的服务器确定为第三服务器集合；其中，阶梯评分规则与分配需求信息相关；将第三服务器集合中的一个服务器确定为目标服务器。

在一种可能的设计中，确定模块，具体用于基于指定的部署范围、指定的系统名称和指定的亲和性属性，对第二服务器集合中的每个服务器进行评分，并将分数最高的服务器确定为第五服务器集合；将第五服务器集合中满足预设条件的服务器确定为第三服务器集合。

在一种可能的设计中，确定模块，具体用于针对第二服务器集合中的任意一个服务器，在服务器的物理位置属于指定的部署范围的下i级时，确定服务器的分数为当前的分数-n，并更新i＝i+1，直至i＝m为止；将第二服务器集合中分数最高的服务器确定为第四服务器集合；其中，n为服务器中包含的与指定的系统名称对应的系统的实例的数量，i的初值为1，m为位于指定的部署范围之下的等级总数，n、i和m为自然数；针对第四服务器集合中的任意一个服务器，在服务器的亲和性属性符合指定的亲和性属性时，确定服务器的分数为当前的分数+1；将第四服务器集合中分数最高的服务器确定为第五服务器集合。

在一种可能的设计中，部署范围的等级由高到低的顺序包括数据中心、逻辑分区、机列、机架以及服务器。

在一种可能的设计中，确定模块，具体用于在a>c时，确定第五服务器集合中bj最小的服务器为第三服务器集合；在a

在一种可能的设计中，任意一个服务器的相关信息包括：服务器的物理位置、硬件信息、剩余可用资源、包含的与各个系统名称对应的实例清单以及亲和性属性。

上述第二方面以及上述第二方面的各可能的设计中所提供的应用容器管理装置，其有益效果可以参见上述第一方面和第一方面的各可能的实施方式所带来的有益效果，在此不再赘述。

第三方面，本申请实施例提供一种电子设备，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得电子设备执行第一方面及第一方面任一种可能的设计中的应用容器管理方法。

第四方面，本申请实施例提供一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行第一方面及第一方面任一种可能的设计中的应用容器管理方法。

第五方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第一方面及第一方面任一种可能的设计中的应用容器管理方法。

第六方面，本申请实施例提供一种芯片系统，芯片系统包括：处理器；当处理器执行存储器中存储的计算机指令时，电子设备执行第一方面及第一方面任一种可能的设计中的应用容器管理方法。

附图说明

图1为本申请一实施例提供的一种应用容器管理方法的流程图；

图2A-图2B为本申请一实施例提供的人机交互界面示意图；

图3为本申请一实施例提供的应用容器管理装置的结构示意图。

具体实施方式

Kubernetes(简称K8s)容器调度平台中对应用容器进行分配的方法为：Kubernetes容器调度平台中的affinity机制可以管理应用容器在服务器上的部署过程。其中，affinity机制的管理规则包括如下内容：

1、管理规则可分为两个维度：必须满足的规则和尽量满足的规则。

2、管理规则中，根据应用容器的分配需求信息中对某个标签的服务器是亲和还是反亲和，对服务器进行评分。

3、管理规则中，根据应用容器的分配需求信息中对某个标签的应用容器是亲和性还是反亲和性，基于服务器中已部署的应用容器对服务器进行评分。

4、基于步骤2和步骤3得到服务器的最后评分，将应用容器分配到评分最高的服务器中。

基于上述过程，Kubernetes容器调度平台可为应用容器分配服务器，但存在如下缺点：

1、一个Kubernetes容器调度平台对应一个集群中的服务器，单个Kubernetes容器调度平台管理的服务器数量和资源容量均有限，且单个Kubernetes容器调度平台中的affinity机制无法跨越集群使用。

2、Kubernetes容器调度平台需要业务人员人工对服务器进行大量的标签标注和规则制定。在完成业务量大的应用容器部署时，管理规则的制定困难且维护困难。

3、Kubernetes容器调度平台中的affinity机制缺少扩展性。

4、Kubernetes容器调度平台中的affinity机制无法感知服务器的物理位置，无法满足系统对于多实例、高可用的冗余要求，无法应对服务器故障和物理环境故障等问题。

5、Kubernetes容器调度平台中的affinity机制有可能会让个别服务器出现处理压力过大或资源浪费的问题。

为了解决上述问题，本申请实施例提供一种应用容器管理方法、装置、设备、电子设备、计算机存储介质、计算机程序产品以及芯片系统，应用于金融科技领域，可以获取属于不同集群的多个服务器中每个服务器的相关信息，将全部服务器的虚拟资源看成一个大的资源池。基于所述多个服务器中每个服务器的相关信息，按照应用容器的分配需求信息对应的规则，可为应用容器从多个服务器中选择一个服务器为目标服务器，并向业务人员通知应用容器在目标服务器上运行。从而，实现了应用容器在属于不同集群中的多个服务器上的部署，打破了无法跨越集群的问题，且预设规则与应用容器的部署相关，不仅简化了规则的制定过程，替代了需要进行大量的标签标注和规则制定的地方，有利于规则的后续维护，降低了规则制定和维护的成本，还能够及时调整预设规则，允许业务人员增减规则以及调整规则的优先级，使得预设规则具备良好的扩展性。另外，利用预设规则中的高可用规则，可使得在服务器故障和如断电或断网等物理环境故障的场景下，其余正常运行且运行有与该实例类型相同的服务器能够承接全部实例，使得应用容器能够顺利在前述服务器上运行，确保相应业务能够顺利实现。并且，利用预设规则中的阶梯评分规则，可使得资源池的剩余资源趋于平均，避免了服务器的压力过大或资源浪费。

请参阅图1，图1为本申请一实施例提供的应用容器管理方法的流程示意图。如图1所示，以管理平台为执行主体，本申请实施例的应用容器管理方法可以包括：

S101、接收应用容器的分配需求信息。

在管理平台检测到某个应用容器出现异常，或者管理平台检测到业务人员手动触发为应用容器进行部署的指令时，管理平台可接收到应用容器的分配需求信息。

其中，应用容器可以对应于部署一个新业务，也可以对应于旧业务的业务量增加，本申请实施例对业务的类型不做限定。例如，在A地区的银行系统中不存在转账业务，但考虑到A地区扩展了转账业务，管理平台可为A地区的转账业务新增一个应用容器，实现A地区的转账业务。又如，在A地区的银行系统中，现有的转账业务对应的应用容器可支撑每天100笔交易，但考虑到A地区当前转账业务增加到了实际每天200笔的交易，业务人员可通过管理平台为A地区的转账业务新增一个应用容器，支撑每天多出来的100笔的交易，满足A地区当前的转账业务。

其中，分配需求信息用于请求为应用容器分配一个新的服务器(即目标服务器)，使得应用容器能够在该服务器上运行，且分配需求信息还表示为部署应用容器对该服务器的需求，如目标服务器的物理位置、硬件信息、剩余可用资源、包含的与各个系统名称对应的实例清单以及亲和性属性等信息。其中，分配需求信息可以包括但不限于：指定的系统名称、指定的部署范围、指定的硬件资源需求和指定的亲和性属性。

系统名称用于唯一表示某个系统，如与转账业务相关的转账指令接收系统、转账结果通知系统、转账逻辑控制系统。通常多个系统可实现一个业务，如前述多个系统相关结合可实现转账业务。

部署范围用于表示具体建设服务器的结构，部署范围的等级由高到低的顺序可以包括：数据中心、逻辑分区(相当于机房)、机列、机架以及服务器等，比如指定的部署范围可以为前述等级中的任意一个或者多个。其中，部署范围还可包括其他方式的等级划分，具体可由实际数据中心的建设结构来决定，本申请实施例对此不耦限定。

硬件资源需求可以包括但不限于中央处理器(central processing unit/processor，CPU)、内存、硬盘、图形处理器(graphics processing unit，GPU)等。

亲和性属性用于表示该应用容器对应的系统的资源特性，如CPU型、内存型、IO型(即硬盘的IO，主要实现数据的读写功能)，还用于表示该应用容器对应的系统希望与哪个类型的系统部署在一起和/或希望与哪个类型的系统不部署在一起，如系统A可用到系统B的功能，则管理平台可将系统A对应的服务器与系统B对应的服务器部署在一起，有利于降低网络延迟，又如，系统A与系统B均具有数据下载功能，则管理平台可将系统A对应的服务器与系统B对应的服务器不部署在一起，避免出现抢占下载资源的现象。需要说明的是，本申请实施例对应用容器的数量不做限定。为了便于说明，本申请实施例以一个应用容器为例进行示意。

S102、获取多个服务器中每个服务器的相关信息。其中，所述多个服务器属于不同集群。

管理平台在接收到步骤S101中的应用容器的分配需求信息后，可从获取属于不同集群的多个服务器中的每个服务器的相关信息，将属于不同集群的多个服务器看成一个资源池来综合编排。

其中，管理平台可采用如配置管理数据库(configuration managementdatabase，CMDB)等数据库预先存储有服务器清单，详细记录有每个服务器的相关信息。任意一个服务器的相关信息可以包括但不限于：服务器的物理位置、硬件信息、剩余可用资源、包含的与各个系统名称对应的实例清单以及亲和性属性。另外，管理平台也可以其他设备中获取属于不同集群的多个服务器中的每个服务器的相关信息，本申请实施例对此不做限定。

S103、基于多个服务器中每个服务器的相关信息，按照与分配需求信息相关的预设规则，将多个服务器中的一个服务器确定为目标服务器。

管理平台基于多个服务器中每个服务器的相关信息，按照与应用容器的分配需求信息相关的预设规则，从属于不同集群的多个服务器中选择一个服务器为目标服务器，将应用容器分配在目标服务器上运行。由此，有利于综合考虑全部服务器的虚拟资源和物理环境等因素，实现了为应用容器跨集群分配服务器的过程。

其中，预设规则预先设置在管理平台中，预设规则与分配需求信息相关，使得管理平台基于应用容器的分配需求信息自动为应用容器分配服务器，切实满足应用容器的实际需求，方便规则扩展和后期维护，降低了规则制定和维护的成本。

S104、通知应用容器在目标服务器上运行。

管理平台基于步骤S103确定了目标服务器后，可向业务人员通知应用容器可在目标服务器上运行，使得业务人员能够及时将应用容器部署在目标服务器上，完成应用容器在目标服务器上运行的过程。

其中，本申请实施例对管理平台向业务人员通知目标服务器的方式不做限定。例如，管理平台可向业务人员显示有目标服务器的相关信息的通知界面，或者，管理平台可以通过邮件、短信等形式向业务人员通知目标服务器的相关信息，或者，管理平台通过预先定义好的接口调用进行通知。另外，本申请实施例不限于前述通知方式。

需要说明的是，在管理平台没有为应用容器找到一个合适的服务器时，管理平台也可以向业务人员通知未成功为应用容器分配服务器以及分配失败的相关原因，以便业务人员及时调整应用容器的分配需求信息。

在一个具体的实施例中，结合图2A-图2B，介绍管理平台为应用容器分配目标服务器的具体实现过程。

请参阅图2A-图2B，图2A-图2B为本申请一实施例提供的人机交互界面示意图。

业务人员可登陆图2A示例性所示的管理平台的用户界面11，用户界面11用于向用户展示需要向管理平台提供应用容器的分配需求信息。其中，用户界面11中包括选项1、选项2、选项3和选项4，选项1用于提供应用容器的系统名称，选项2用于提供应用容器的部署范围，选项3用于提供应用容器的硬件资源需求，选项4用于提供应用容器的亲和性属性。

业务人员可在用户界面11中指定应用容器的分配需求信息，如业务人员选择了应用容器的系统名称、系统的资源类型、CPU、内存、部署范围和反亲和性属性，也可以在用户界面11中默认应用容器的分配需求信息，如业务人员默认亲和性属性，本申请实施例对此不做限定。

在业务人员指定完应用容器的分配需求信息之后，管理平台在接收到业务人员添加应用容器的分配需求信息的操作(如点击用户界面11中文字“提交”控件)后，可获取到应用容器的分配需求信息为：系统a，部署在数据中心n、逻辑分区1、机列x，3核CPU+6G内存，自身对应的系统的资源类型为IO型，必须不与IO型的系统混合部署，以便管理平台执行步骤S103，基于多个服务器中每个服务器的相关信息，从多个服务器中为应用容器分配一个服务器。

管理平台在按照与应用容器的分配需求信息相关的预设规则确定目标服务器后，可显示图2B示例性的用户界面12，用户界面12用于提示业务人员应用容器在目标服务器上运行，如显示提示信息(即如用户界面12示例性所示的界面)或者显示目标服务器的相关信息，使得业务人员可以及时获知目标服务器，方便业务人员在目标服务器中部署应用容器，使得应用容器可在目标服务器上运行。

需要说明的是，用户界面11/12可以包括但不限于上述内容，且本申请实施例对用户界面11/12的具体实现方式也不做限定。

本申请实施例提供的应用容器管理方法，通过获取属于不同集群的多个服务器的相关信息，可将全部服务器的虚拟资源看成一个大的资源池。由此，基于多个服务器的相关信息，按照应用容器的分配需求信息对应的规则，可为应用容器从多个服务器中选择一个服务器为目标服务器，并向业务人员通知应用容器在目标服务器上运行。从而，实现了应用容器在属于不同集群中的多个服务器上的部署，打破了无法跨越集群的问题，且预设规则与应用容器的部署相关，不仅简化了规则的制定过程，替代了需要进行大量的标签标注和规则制定的地方，有利于规则的后续维护，降低了规则制定和维护的成本，还能够及时调整预设规则，允许业务人员增减规则以及调整规则的优先级，使得预设规则具备良好的扩展性。在一些实施例中，预设规则可以包括如强制性分配规则和高可用规则等必须满足的规则。其中，强制性分配规则是指服务器的硬性指标必须满足的规则，强制性分配规则通常与部署范围、硬件资源需求和亲和性属性相关。高可用规则是指可承受服务器故障的程度，可对应于多实例、高可用的要求，高可用规则通常与部署范围和系统名称相关。

在步骤S103的一种可行的实现方式中，管理平台可基于多个服务器中每个服务器的相关信息，从多个服务器中选择符合强制性分配规则的服务器，并将符合强制性分配规则的服务器确定为第一服务器集合。管理平台再从第一服务器集合中选择符合高可用规则的服务器，并将符合高可用规则的服务器确定为第二服务器集合。从而，管理平台可将第二服务器集合中的一个服务器确定为目标服务器。

其中，本申请对第一服务器集合和第二服务器集合中服务器的数量和类型等参数不做限定。

需要说明的是，除了上述方式之外，管理平台也可先判断服务器是否符合高可用规则的步骤，再执行判断服务器是否符合强制性分配规则的步骤，还可以同时执行判断服务器是否符合强制性分配规则和高可用规则的步骤，本申请实施例对此不做限定。

其中，本申请实施例对强制性分配规则的具体实现方式不做限定。在一些实施例中，强制性分配规则可以预设三个筛选规则，分别为：

1、根据分配需求信息中指定的部署范围，从多个服务器中选择满足指定的部署范围内的服务器清单。

例如，分配需求信息中指定的部署范围为：数据中心n、逻辑分区1、机列x，则管理平台选择出来的服务器清单需要位于该指定的部署范围中。

2、根据分配需求信息中指定的硬件资源需求，从多个服务器中剔除无法满足硬件资源需求的服务器。

例如，分配需求信息中指定的硬件资源需求为：3核CPU+6G内存，则管理平台将剔除剩余资源小于3核CPU或6G内存的服务器。

3、根据分配需求信息中指定的亲和性规则，从多个服务器中选择匹配亲和性的服务器，并剔除匹配反亲和性的服务器。

例如，分配需求信息中指定的亲和性规则为：必须不与IO型的系统混合部署，则管理平台将IO型的系统对应的服务器全部剔除。

需要说明的是，上述三个筛选规则没有时序上的先后顺序，可以根据实际需要同时执行或者顺序执行。另外，管理平台还可以在任意一个位置加入额外的筛选规则。

从而，针对多个服务器中的任意一个服务器，管理平台在服务器的物理位置符合指定的部署范围，服务器的硬件信息符合指定的硬件资源需求以及服务器的亲和性属性符合指定的亲和性属性时，可以确定服务器属于第一服务器集合。

需要说明的是，强制性分配规则中还可添加或删除其他参数，且允许业务人员删减规则和调整规则的优先级，使得强制性分配规则具备良好的扩展性。

其中，本申请实施例对高可用规则的具体实现方式不做限定。在一些实施例中，高可用规则中包含三个参数：高可用计算单元、单元内最高占比、最少实例数。

1、高可用计算单元：与指定的部署范围相对应。例如，高可用计算单元可以包括：数据中心、逻辑分区、机列、机架以及服务器等中的至少一个级别进行计算，即管理平台可以设置一个或者多个高可用计算单元。

2、单元内最高占比：在任意一个高可用计算单元内系统对应的实例的数量占在当前进行校验的服务器中系统对应的实例的数量的比值不能超过预设最高占比。

3、最少实例数：在多个服务器中系统对应的实例的数量不超过预设最小实例数时，可不进行高可用规则的校验。其中，预设最小实例数≥(1/预设最高占比)。

在一些实施例中，经过强制性分配规则的筛选，对第一服务器集合中的服务器进行高可用规则的校验包括如下步骤：

1、管理平台判断在第一服务器集合中系统对应的实例的数量是否小于预设最小实例数。

2、若否，则不需进行高可用规则的校验，可确定第一服务器集合中的服务器符合高可用规则。若是，则判断在任意一个高可用计算单元内系统对应的实例的数量占在第一服务器集合中系统对应的实例的数量的比值是否小于等于预设最高占比。

3、若是，则可确定第一服务器集合中的服务器符合高可用规则。若否，则可确定第一服务器集合中的服务器不符合高可用规则，便可将对应的服务器剔除。

从而，针对第一服务器集合中的任意一个服务器，管理平台在满足s+1＜预设最少实例数，或者，s+1≥预设最少实例数且(n+1)/(s+1)≤预设最高占比时，可以确定服务器属于第二服务器集合。

其中，n为指定的部署范围中包含的与指定的系统名称对应的系统的实例的数量，s为第一服务器集合中包含的与指定的系统名称对应的系统的实例的数量，n和s为自然数。

在一个具体的实施例中，若管理平台设置两个高可用计算单元，则管理平台设置有两条高可用规则，分别为：

规则一：高可用计算单元：数据中心；预设最高占比：50％；预设最少实例数：2。其中，注意到这里2≥(1/50％)。

规则二：高可用计算单元：机架；预设最高占比：33％；预设最少实例数：3。其中，注意到这里3≥(1/33％)。

1、假设此时来了一个应用容器A1的分配需求信息x，是属于一个全新的系统a的。由于多个服务器中的当前环境尚未存在系统a对应的实例，因此，1＜2，1＜3。从而，管理平台无需进行规则一和规则二的校验。

2、接下来，又来了一个应用容器A2的分配需求信息y，仍是属于系统a的。那么对于规则一来说，2＝2，则管理平台便会要求将应用容器A2分配到与应用容器A1不同的数据中心中，否则便无法满足规则一。那么对于规则一来说，2＜3，管理平台无需进行规则二的校验。

3、接下来，又来了一个应用容器A3的分配需求信息z，仍是属于系统a的。那么对于规则一来说，3＞2，则管理平台便会要求将应用容器A3分配到与应用容器A1和应用容器A2均不同的数据中心中，否则便无法满足规则一。

在一些实施例中，预设规则还可以包括如阶梯评分规则等尽量满足的规则。其中，阶梯评分规则是指对经过必须满足的规则筛选后的服务器进行评分的规则，以便获得最适合部署应用容器的服务器，阶梯评分规则与分配需求信息相关。

其中，本申请实施例对阶梯评分规则的具体实现方式不做限定。在一些实施例中，阶梯评分规则包括如下内容：

1、按照每一级规则，对可用的服务器进行评分，得到分数最高的服务器。若是一个服务器，则管理平台将该服务器确定为目标服务器。若是多个服务器，则管理平台将多个服务器作为进行下一级规则的可用的服务器。另外，当管理平台计算完最后一级规则时，仍存在分数最高的多个服务器，则管理平台可从这些服务器中随机选择一个服务器作为目标服务器。

2、每一级规则中，管理平台可以设置一个或者多个评分的规则。若A规则优先于B规则时，管理平台可将A规则设置在比B规则更早的阶梯；若A规则与B规则的优先级相同时，管理平台可将A规则设置在与B规则相同的阶梯，但管理平台可基于多个服务器的资源等因素，对A规则和B规则的评分权重进行设置。

3、阶梯评分规则可包括如下三级规则，具体内容如下：

第一阶梯——尽量分散规则：从应用容器的分配需求信息中指定的部署范围的下一级开始，计算指定的部署范围的下一级中已存在的系统对应的实例的数量，每当有一个实例则给指定的部署范围的下一级中的服务器减1分；计算完指定的部署范围的下一级后，选择分数最高的服务器，再对指定的部署范围的下两级进行上述过程同样的计算，直到指定的部署范围的最低一级。

比如，部署范围包含数据中心、逻辑分区、机列、机架、服务器。分配需求信息指定到机列的级别，那么，管理平台可先从机架这个级别开始，计算同一个机架中已存在的系统对应的实例的数量，每当有一个实例则给机架中的服务器减1分，并选择分数最高的服务器。然后，管理平台接着从机架内的每个服务器开始，计算同一个服务器中已存在的系统对应的实例的数量，每当有一个实例则给服务器减1分，并选择分数最高的服务器。

第二阶梯——亲和性规则：针对任意一个服务器，每当匹配上指定的亲和性属性中的一个亲和性时，该服务器加1分；每当匹配上指定的亲和性属性中的一个反亲和性时，该服务器减1分；管理平台输出分数最高的服务器。

第三阶梯——高使用率规则：管理平台先计算出该批服务器中所有服务器的CPU总和与内存总和的比值a。其中，a值的含义是最适合分配至该批服务器的CPU、内存比值的标准规格。接着，管理平台计算该批服务器中每台服务器的剩余CPU占比和剩余内存占比的比值b。然后，管理平台将a与分配需求信息中指定的硬件资源需求的CPU与内存的比值c相比。

若a>c，则管理平台选择b值最小的服务器；若a

从而，在第二服务器集合中只存在一个服务器时，管理平台可将服务器确定为目标服务器。在第二服务器集合中存在多个服务器时，管理平台可将第二服务器集合中符合阶梯评分规则的服务器确定为第三服务器集合，并将第三服务器集合中的一个服务器确定为目标服务器。

需要说明的是，阶梯评分规则中还可添加或删除任意一级规则，且允许业务人员删减规则和调整规则的优先级，使得阶梯评分规则具备良好的扩展性。

在一些实施例中，管理平台基于指定的部署范围、指定的系统名称和指定的亲和性属性，可对第二服务器集合中的每个服务器进行评分，并将分数最高的服务器确定为第五服务器集合。

具体地，针对第二服务器集合中的任意一个服务器，管理平台在服务器的物理位置属于指定的部署范围的下i级时，可确定服务器的分数为当前的分数-n，并更新i＝i+1，直至i＝m为止，并将第二服务器集合中分数最高的服务器确定为第四服务器集合。

其中，n为服务器中包含的与指定的系统名称对应的系统的实例的数量，i的初值为1，m为位于指定的部署范围之下的等级总数，n、i和m为自然数。

针对第四服务器集合中的任意一个服务器，管理平台在服务器的亲和性属性符合指定的亲和性属性时，可以确定服务器的分数为当前的分数+1，并将第四服务器集合中分数最高的服务器确定为第五服务器集合。

接着，管理平台可将第五服务器集合中满足预设条件的服务器确定为第三服务器集合。

在a>c时，管理平台可确定第五服务器集合中bj最小的服务器为第三服务器集合。在a

其中，a为第五服务器集合中全部的服务器的CPU总和与内存总和的比值，bj为第五服务器集合中第j个服务器的剩余CPU与剩余内存的比值，j的初值为1，j取遍大于等于1且小于等于p的正整数，p为第五服务器集合中服务器的总数，j和p为正整数，c为指定的硬件资源需求中的CPU与内存的比值。

其中，本申请实施例对第三服务器集合、第四服务器集合和第五服务器集合中服务器的数量和类型等参数不做限定。

在一个具体的实施例中，如表1所示，第五服务器集合包括服务器1、服务器2和服务器3，管理平台可计算出a＝0.458，即对第五服务器集合中的服务器来说，标准规格为0.458核CPU+1G内存(及其同比放大的规格)。

表1第五服务器集合中的服务器

基于表1的内容，针对服务器1而言，CPU和内存分配的相对平均。针对服务器2，内存分配的速度快于CPU。针对服务器3而言，CPU分配的速度快于内存。

1、若有一个需求为1核CPU+1G内存的应用容器的分配需求信息，管理平台可计算应用容器的分配需求信息的c＝1，a

2、若有一个需求为1核CPU+3G内存的应用容器的分配需求信息，管理平台可计算该分配需求的c＝0.33，a>c，因此，管理平台可选择b值最小的服务器(即服务器1)，以便使得服务器1的CPU分配速度较快的现象缓解。

示例性地，本申请实施例还提供一种应用容器管理装置。

请参阅图3，图3为本申请一实施例提供的应用容器管理装置的结构示意图。

本申请实施例的应用容器管理装置可设置在服务器中，可实现上述应用容器管理方法实施例对应于管理平台的操作。如图3所示，本申请实施例的应用容器管理装置可以包括：接收模块101、获取模块102、确定模块103和通知模块104。

接收模块101，用于接收应用容器的分配需求信息，分配需求信息用于表示为应用容器部署对目标服务器的需求。

获取模块102，用于获取多个服务器中每个服务器的相关信息，多个服务器属于不同集群。

确定模块103，用于基于多个服务器中每个服务器的相关信息，按照与分配需求信息相关的预设规则，将多个服务器中的一个服务器确定为目标服务器。

通知模块104，用于通知应用容器在目标服务器上运行。

在一些实施例中，分配需求信息包括：指定的系统名称、指定的部署范围、指定的硬件资源需求和指定的亲和性属性。

确定模块103，用于基于多个服务器中每个服务器的相关信息，将多个服务器中符合强制性分配规则的服务器确定为第一服务器集合；其中，强制性分配规则与指定的部署范围、指定的硬件资源需求和指定的亲和性属性相关；将第一服务器集合中符合高可用规则的服务器确定为第二服务器集合；其中，高可用规则与指定的部署范围和指定的系统名称相关；将第二服务器集合中的一个服务器确定为目标服务器。

在一些实施例中，确定模块103，具体用于针对多个服务器中的任意一个服务器，在服务器的物理位置符合指定的部署范围，服务器的硬件信息符合指定的硬件资源需求以及服务器的亲和性属性符合指定的亲和性属性时，确定服务器属于第一服务器集合。

在一些实施例中，确定模块103，具体用于针对第一服务器集合中的任意一个服务器，在满足s+1＜预设最少实例数，或者，s+1≥预设最少实例数且(n+1)/(s+1)≤预设最高占比时，确定服务器属于第二服务器集合；其中，n为指定的部署范围中包含的与指定的系统名称对应的系统的实例的数量，s为第一服务器集合中包含的与指定的系统名称对应的系统的实例的数量，n和s为自然数。

在一些实施例中，确定模块103，具体用于在第二服务器集合中只存在一个服务器时，将服务器确定为目标服务器；在第二服务器集合中存在多个服务器时，将第二服务器集合中符合阶梯评分规则的服务器确定为第三服务器集合；其中，阶梯评分规则与分配需求信息相关；将第三服务器集合中的一个服务器确定为目标服务器。

在一些实施例中，确定模块103，具体用于基于指定的部署范围、指定的系统名称和指定的亲和性属性，对第二服务器集合中的每个服务器进行评分，并将分数最高的服务器确定为第五服务器集合；将第五服务器集合中满足预设条件的服务器确定为第三服务器集合。

在一些实施例中，确定模块103，具体用于针对第二服务器集合中的任意一个服务器，在服务器的物理位置属于指定的部署范围的下i级时，确定服务器的分数为当前的分数-n，并更新i＝i+1，直至i＝m为止；将第二服务器集合中分数最高的服务器确定为第四服务器集合；其中，n为服务器中包含的与指定的系统名称对应的系统的实例的数量，i的初值为1，m为位于指定的部署范围之下的等级总数，n、i和m为自然数；针对第四服务器集合中的任意一个服务器，在服务器的亲和性属性符合指定的亲和性属性时，确定服务器的分数为当前的分数+1；将第四服务器集合中分数最高的服务器确定为第五服务器集合。

在一些实施例中，部署范围的等级由高到低的顺序包括数据中心、逻辑分区、机列、机架以及服务器。

在一些实施例中，确定模块103，具体用于在a>c时，确定第五服务器集合中bj最小的服务器为第三服务器集合；在a

在一些实施例中，任意一个服务器的相关信息包括：服务器的物理位置、硬件信息、剩余可用资源、包含的与各个系统名称对应的实例清单以及亲和性属性。

本申请实施例中可以根据上述方法示例对应用容器管理装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请各实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请实施例的应用容器管理装置，可以用于执行前文提及的应用容器管理方法中管理平台的技术方案，其实现原理和技术效果类似，其中各个模块的实现的操作可以进一步参考方法实施例的相关描述，此处不再赘述。此处的模块也可以替换为部件或者电路。

示例性地，本申请实施例还提供一种电子设备，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得电子设备执行前文实施例中的应用容器管理方法。

示例性地，本申请实施例还提供一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行前文实施例中的应用容器管理方法。

示例性地，本申请实施例还提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行前文实施例中的应用容器管理方法。

示例性地，本申请实施例提供一种芯片系统，芯片系统包括：处理器；当处理器执行存储器中存储的计算机指令时，电子设备执行前文实施例中的应用容器管理方法。

在上述实施例中，全部或部分功能可以通过软件、硬件、或者软件加硬件的组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。