本申请涉及计算机技术领域，特别是涉及一种系统维护方法和装置。
背景技术：
在应用程序发布运行后，需要对运行应用程序的系统进行维护，根据应用程序的负载高低对应用程序的容量进行调整，避免负载过高，容量不足时无法满足用户需求的问题，以及负载较低时容量过大，造成系统资源浪费的问题。
现有技术中，主要采用虚拟机技术进行应用程序的发布，即在系统的服务器中建立一定数量的虚拟机，在每个虚拟机中部署应用程序。在系统维护过程中，若应用程序的负载较高，由工作人员手动操作服务器增加虚拟机的数量，以增加应用程序的容量，满足用户需求，若应用程序负载较低，则由工作人员手动操作服务器减少虚拟机的数量，降低应用程序的容量，避免资源浪费。
在人工手动维护过程中，无法及时响应负载的变化，调整应用程序的容量，并且工作人员手动调整虚拟机的数量时，虚拟机的建立和应用程序的部署都需要较多的时间，难以满足实时性要求。
技术实现要素：
鉴于上述问题，本申请实施例提供一种系统维护方法，能够解决现有技术中系统维护时，无法满足实时性的问题。
相应的，本申请实施例还提供了一种系统维护装置，用以保证上述方法的实现及应用。
为了解决上述问题，本申请实施例公开了一种系统维护方法，应用于控制服务器，包括：
接收每个业务服务器分别发送的第一监测数据和第二监测数据，所述第一监测数据用于描述所述业务服务器中部署的目标应用程序的所有容器的负载高低，所述第二监测数据用于描述所述业务服务器的负载高低；
根据每个所述业务服务器发送的所述第一监测数据，计算得到第三监测数据，所述第三监测数据用于描述所述目标应用程序的负载高低；
在所述第三监测数据大于或等于第一预设阈值的情况下，根据所述第三监测数据和所述第一预设阈值确定需要在所有所述业务服务器中增加的所述容器的第一数量；
根据每个所述业务服务器发送的所述第二监测数据和所述第一数量，从所述至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在所述第一目标服务器中增加的所述容器的第二数量；
向所述第一目标服务器发送第一指令，以使所述第一目标服务器根据所述第一指令增加所述第二数量的所述容器。
相应的，本申请实施例还公开了一种系统维护装置，设置于控制服务器，包括：
接收模块，用于接收每个业务服务器分别发送的第一监测数据和第二监测数据，所述第一监测数据用于描述所述业务服务器中部署的目标应用程序的所有容器的负载高低，所述第二监测数据用于描述所述业务服务器的负载高低；
计算模块，用于根据每个所述业务服务器发送的所述第一监测数据，计算得到第三监测数据，所述第三监测数据用于描述所述目标应用程序的负载高低；
第一确定模块，用于在所述第三监测数据大于或等于第一预设阈值的情况下，根据所述第三监测数据和所述第一预设阈值确定需要在所有所述业务服务器中增加的所述容器的第一数量；
第二确定模块，用于根据每个所述业务服务器发送的所述第二监测数据和所述第一数量，从所述至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在所述第一目标服务器中增加的所述容器的第二数量；
发送模块，用于向所述第一目标服务器发送第一指令，以使所述第一目标服务器根据所述第一指令增加所述第二数量的所述容器。
本申请实施例还提供一种装置，包括处理器以及存储器，其中，
所述处理器执行所述存储器所存放的计算机程序代码，以实现本申请所述的系统维护方法。
本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现本申请所述的系统维护方法的步骤。
本申请实施例包括以下优点：
接收每个业务服务器分别发送的第一监测数据和第二监测数据，根据每个业务服务器发送的第一监测数据，计算得到第三监测数据，在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量，向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的容器。通过使用容器技术运行目标应用程序，在目标应用程序的运行过程中，实时监测目标应用程序的负载和业务服务器的负载，在目标应用程序的负载较高时，根据目标应用程序的负载和每个业务服务器的负载在相应的业务服务器中增加一定量的容器，对目标应用程序的容量进行扩展，可以实时的调整目标应用程序的容量，提高系统的稳定性，避免调整不及时导致的系统崩溃等问题。
附图说明
图1示出了本申请的一种系统维护方法的步骤流程图；
图2示出了本申请的一种应用程序系统的结构示意图；
图3示出了本申请的另一种系统维护方法的步骤流程图；
图4示出了本申请的一种系统维护装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1，示出了本申请的一种系统维护方法的步骤流程图，本实施例提供的系统维护方法适用于系统维护，以解决系统维护过程中的实时性问题。本实施例提供的系统维护方法可以由系统维护装置执行，系统维护装置可以设置于控制服务器。系统维护装置通常以软件和/或硬件的方式实现，该方法可以包括如下步骤：
步骤101，接收每个业务服务器分别发送的第一监测数据和第二监测数据。
其中，第一监测数据用于描述业务服务器中部署的目标应用程序的所有容器的负载高低，第二监测数据用于描述业务服务器的负载高低。
参照图2，图2示出了本申请的一种应用程序系统的结构示意图，如图2所示，应用程序系统可以包括一个控制服务器和至少一个业务服务器，控制服务器用于控制每个业务服务器运行目标应用程序，并对目标应用程序的运行过程进行维护。其中，目标应用程序以容器的形式运行在业务服务器中，例如控制服务器可以根据目标应用程序的源代码和容器镜像模生成与目标应用程序对应的容器镜像，将容器镜像发送至每个业务服务器，业务服务器根据容器镜像，在业务服务器中建立并运行与目标应用程序对应的多个容器，实现目标应用程序在业务服务器的运行。建立并运行容器的方法，可参考现有技术中使用容器技术运行应用程序的方法，本实施例对此不做详细描述。
本实施例中，第一监测数据用于描述业务服务器中运行的与目标应用程序对应的所有容器的负载总量。如图2所示，在业务服务器1中运行有与目标应用程序对应的容器1、容器2和容器3，则第一监测数据可以是容器1、容器2和容器3的吞吐量的总和/或tps(transactionpersecond，每秒事务处理量)的总和。业务服务器实时采集每个容器的吞吐量或tps，根据每个容器的吞吐量或tps获得第一监测数据，如业务服务器1可以分别采集容器1、容器2和容器3的吞吐量，将容器1、容器2和容器3的吞吐量相加后，获得第一监测数据。第二监测数据用于描述业务服务器的负载高低，例如，第二监测数据可以是业务服务器1的cpu(centralprocessingunit，中央处理器)和/或内存的使用率，表示业务服务器1的负载量。
业务服务器可以实时采集第一监测数据和第二监测数据，并发送至控制服务器。控制服务器可以接收每个业务服务器分别发送的第一监测数据和第二监测数据，用于确定每个业务服务器的负载高低，以及确定每个业务服务器中运行的目标应用程序的所有容器的负载高低。控制服务器接收业务服务器发送的第一监测数据和第二监测数据的过程可参考现有技术，本实施例对此不做限制。
实际使用时，第一监测数据和第二监测数据中包括的具体参数，可以根据实际需求选择，本实施例对此不做限制。
步骤102，根据每个业务服务器发送的第一监测数据，计算得到第三监测数据。
其中，第三监测数据用于描述目标应用程序的负载高低，表示运行在所有业务服务器中的，与目标应用程序对应的所有容器的负载总量。
本实施例中，控制服务器在接收到每个业务服务发送的第一监测数据后，可以根据每个业务服务器发送的第一监测数据，计算得到与目标应用程序对应的第三监测数据。结合步骤101，若第一监测数据选择容器的吞吐量参数，则控制服务器在接收到业务服务器1发送的容器1、容器2和容器3的吞吐量总和，业务服务器2发送的容器4、容器5和容器6的吞吐量总和，以及业务服务器3发送的容器7、容器8和容器9的吞吐量总和后，可以将业务服务器1、业务服务器2和业务服务器3分别发送的第一监测数据进行相加，得到第三监测数据，即容器1至容器9的吞吐量总和，容器1至容器9的吞吐量总和表示目标应用程序的总的吞吐量。
需要说明的是，根据第一监测数据计算得到第三监测数据的方法，可以根据第一监测数据中包括的具体参数进行设置，本实施例对此不做限制。
步骤103，在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量。
其中，第一数量表示针对目标应用程序，需要增加的容器数量，即需要扩大目标应用程序的容量时，需要在整个系统中增加的容器容量。
结合步骤101和步骤102，第三监测数据用于描述目标应用程序的负载，当第三监测数据大于或等于第一预设阈值时，表示目标应用程序的负载较高，需要扩大目标应用程序的容量。例如，可以设置第一预设阈值为100兆(预先设置的目标应用程序的总的吞吐量)，若第三监测数据为120兆，表示目标应用程序此时的吞吐量已经超过预先设置的吞吐量(第一预设阈值)，需要扩大目标应用程序的吞吐量。此时，可以确定第三监测数据和第一预设阈值之间的差值(20兆)，根据第三监测数据和第一预设阈值之间的差值，确定需要增加的容器数量。例如，若每增加一个容器可以增加5兆的吞吐量，则可以确定需要在业务服务器1、业务服务器2和业务服务器3中总共增加4个(第一数量)容器。第一预设阈值的大小和形式可以根据第三监测数据进行设置，本实施例对此不做限制。
实际使用时，根据第三监测数据和第一预设阈值确定第一数量的方法可以根据需求选择，本实施例对此不做限制。
步骤104，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量。
其中，第一目标服务器为扩大目标应用程序的容量时，所有业务服务器中可以增加容器的业务服务器，第二数量为第一目标服务器中可以增加的容器数量。
本实施例中，第二监测数据用于描述业务服务器的负载高低，在业务服务器中增加容器时，可以根据每个业务服务器的负载高低，在多个业务服务器中分配第一数量的容器。因此，需要从多个业务服务中确定第一目标服务器，即可以增加容器的业务服务器，并确定第一目标服务中可以增加的容器数量(第二数量)。结合步骤101至步骤103，若业务服务服务器1的cpu使用率为90％、业务服务器2的cpu使用率为80％、以及业务服务器3的cpu使用率为70％，则可以确定业务服务器1的负载较高，而业务服务器3的负载较低。此时，可以确定业务服务器3为第一目标服务器，在业务服务器3中增加4个(第二数量)容器。或者确定业务服务器2和业务服务器3为第一目标服务器，在业务服务器3中增加2个(第二数量)容器，在业务服务器2中增加2个(第二数量)容器。具体根据据每个业务服务器发送的第二监测数据和第一数量确定第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量的方法可以根据需求设置，本实施例对此不做限制。
步骤105，向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的容器。
本实施例中，在确定第一目标服务器，以及确定需要在第一目标服务器中增加的容器的第二数量后，可以向第一目标服务器发送第一指令，第一指令中可以包括第二数量，相应的，第一目标服务器在接收到第一指令后，可以解析第一指令，从而确定第二数量，并增加第二数量的容器。具体向第一目标服务器发送第一指令的过程，以及第一目标服务器根据第一指令建立第二数量容器的过程，可参考现有技术中建立容器的过程，本实施例对此不做限制。
综上所述，本申请实施例提供的系统维护方法，包括：接收每个业务服务器分别发送的第一监测数据和第二监测数据，根据每个业务服务器发送的第一监测数据，计算得到第三监测数据，在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量，向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的容器。通过使用容器技术运行目标应用程序，在目标应用程序的运行过程中，实时监测目标应用程序的负载和业务服务器的负载，在目标应用程序的负载较高时，根据目标应用程序的负载和业务服务器的负载在业务服务器中增加一定量的容器，对目标应用程序的容量进行扩展，可以实时的调整目标应用程序的容量，提高系统的稳定性，避免调整不及时导致的系统崩溃等问题。
参照图3，示出了本申请的另一种系统维护方法的步骤流程图，该方法包括如下步骤：
步骤301，向每个业务服务器分别发送第五指令。
其中，第五指令用于使每个业务服务器分别根据第五指令，建立并运行第八数量的容器，以部署目标应用程序，第八数量为用户预先设置的容器数量。
本实施例中，在目标应用程序的开发过程中，可以由开发人员将目标应用程序的源代码存储在存储仓库(gitlab)中。在发布目标应用程序时，控制服务器可以从存储仓库中获取目标应用程序的源代码，并从应用容器引擎(docker)中获取容器镜像模板(dockerfile)，根据容器镜像模板和目标应用程序的源代码生成容器镜像。控制服务器在生成容器镜像后，可以将容器镜像存储在容器镜像库中。例如，可以建立私有容器镜像库(harbor)，在生成容器镜像后，向容器镜像库发送容器镜像，使用容器镜像库存储容器镜像。具体生成容器镜像的过程，建立容器镜像库，并通过容器镜像库存储容器镜像的过程可参考现有技术，本实施例在此不做详细描述。
可选地，可以在每个业务服务器中建立容器镜像库。
如图2所示，可以分别在业务服务器1、业务服务器2和业务服务器3中建立容器镜像库，控制服务器可以分别向业务服务器1、业务服务器2和业务服务器3发送目标应用程序的容器镜像，以在每个业务服务器中分别存储目标应用程序的容器镜像。
本实施例中，第五指令中可以包括目标应用程序对应的容器镜像标识，第八数量和容器镜像配置信息。业务服务器在接收到第五指令后，可以解析第五指令，根据第八数量确定需要建立并运行的容器数量，据容器镜像标识从容器镜像库中获取对应的容器镜像，在获取到容器镜像后，根据容器镜像和容器配置信息建立第八数量的容器。例如，业务服务器3在接收到第五指令后，可以根据第五指令中包括的容器镜像标识，从业务服务器3中的容器镜像库3中获取与目标应用程序对应的容器镜像，根据获取的容器镜像和容器配置信息建立容器7、容器8和容器9。其中，在每个业务服务器中建立容器镜像库，并存储目标应用程序的容器镜像，使业务服务器在建立容器的时候，可以方便快速的获取容器镜像，快速的建立容器，提高效率。具体获取容器镜像，根据容器镜像和容器配置信息建立容器的过程可参考现有技术，本实施例对此不做限制。
步骤302，接收每个业务服务器分别发送的第一监测数据和第二监测数据。
步骤303，根据每个业务服务器发送的第一监测数据，计算得到第三监测数据。
步骤304，在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量。
步骤305，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量。
其中，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量的过程，可以通过如下方式实现：
根据每个业务服务器发送的第二监测数据，对每个业务服务器进行排序，得到排序结果；
根据排序结果，确定第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量。
本实施例中，可以根据每个业务服务器发送的第二监测数据，对所有业务服务器进行排序，以得到排序结果。结合步骤104，可以根据每个业务服务器的cpu使用率对业务服务器1、业务服务器2和业务服务器3进行排序，得到业务服务器1大于业务服务器2，业务服务器2大于业务服务器3的排序结果。可以根据排序结果确定每个业务服务器的负载的高低情况，以确定向每个业务服务器分配的容器的数量。如根据排序结果可知，业务服务器3的负载最低，可以向业务服务器3分配较多的容器，向业务服务器1分配较少的容器。具体的，可以向业务服务器1分配2个容器(第二数量)，分别向业务服务器1和业务服务器2分配1个容器(第二数量)。根据每个业务服务器发送的第二监测数据，对业务服务器进行排顺序，根据排序结果在多个业务服务器中分配第一数量的容器，可以更加合理的将第一数量的容器分配到每个业务服务器中，避免向负载较高的业务服务器中分配大量的容器，增加业务服务器的负载。具体根据排序结果分配容器的过程可根据实际需求设置，本实施例对此不做限制。
步骤306，向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的容器。
本实施例中，第一指令中可以包括容器镜像标识、第二数量和容器配置信息。业务服务器(第一目标服务器)在接收到第一指令后，可以解析第一指令，确定第一指令中包括的容器镜像标识、第二数量和容器配置信息。根据容器镜像标识从容器镜像库中获取对应的容器镜像，在获取到容器镜像后，根据容器镜像和容器配置信息建立第二数量的容器。例如，业务服务器1在接收到第一指令后，可以根据第一指令中包括的容器镜像标识，从业务服务器1中的容器镜像库1中获取与目标应用程序对应的容器镜像，根据获取的容器镜像和容器配置信息建立1个容器。
步骤307，在第三监测数据小于或等于第二预设阈值的情况下，根据第三监测数据和第二预设阈值确定需要在所有业务服务器中减少的容器的第三数量。
其中，第三数量表示针对目标应用程序，需要在所有业务服务器中减少的容器数量，即需要降低目标应用程序的容量时，需要减少的容器容量。
本实施例中，第三监测数据小于或等于第二预设阈值，表示目标应用程序的负载较低，目标应用程序中的部分资源被闲置，可以减少一定数量的容器，释放业务服务器的资源，使业务服务器进行其他业务，以提高业务服务器的使用效率。
结合实施例一，若第二预设阈值为20兆，第三监测数据为10兆，可以确定目标应用程序的负载较低，可以减少容器的数量。具体的，可以计算第三监测数据和第二预设阈值的差值(10兆)，根据第三监测数据和第二预设阈值的差值确定，可以在业务服务器1、业务服务器2和业务服务器3中总共减少2个(第三数量)容器，以降低目标应用程序的容量。根据第三监测数据和第二预设阈值确定第三数量的方法可以根据需求选择，本实施例对此不做限制
步骤308，根据每个业务服务器发送的第二监测数据和第三数量，从至少一个业务服务器中确定至少一个第二目标服务器，并确定需要在第二目标服务器中减少的容器的第四数量。
其中，第四数量表示在降低目标应用程序的容量时，需要在第二目标服务器中减少的容器数量。
结合实施例一，在减少目标应用程序的容器时，可以根据每个业务服务器负载的高低，在多个业务服务器中分配第三数量的容器。具体的，可以根据每个业务服务器发送的第二监测数据确定每个业务服务器的负载，根据每个业务服务器的负载，确定第二目标服务器，并确定在第二目标服务器中需要减少的容器的数量(第四数量)。结合前述举例，在确定业务服务器1的负载较高，业务服务器3的负载较低时，可以确定业务服务器1为第二目标服务器，直接在业务服务器1中减少2个(第四数量)容器。也可以同时确定业务服务器1和业务服务器2同时为第二目标服务器，在业务服务器1和业务服务器2分别减少1个(第四数量)容器。
需要说明的是，在减少目标应用程序的容器时，也可以根据第二监测数据对业务服务器进行排序，根据排序结果确定第二目标服务器，以及确定每个第二目标服务器对应的第四数量，本实施例对此不作限制。
步骤309，向第二目标服务器发送第二指令，以使第二目标服务器根据第二指令减少第四数量的容器。
本实施例中，第二指令中可以包括第四数量和容器标识。实际使用中，业务服务器可以同时运行多个目标应用程序的容器。第二指令中包括第四数量和容器标识，业务服务器在接收到第二指令后，可以解析第二指令，根据第二指令中包括的容器标识，确定目标应用程序对应的容器，关闭第四数量与容器标识对应的容器。业务服务器减少容器的过程可参考现有技术，本实施例对此不做限制。
可选地，该方法还可以包括：
响应于用户操作，确定需要在所有业务服务器中增加或减少的容器的第五数量。
根据每个业务服务器发送的第二监测数据和第五数量，从至少一个业务服务器中确定至少一个第三目标服务器，并确定需要在第三目标服务器中增加或减少的容器的第六数量。
向第三目标服务器发送第三指令，以使第三目标服务器根据第三指令增加或减少第六数量的所述容器。
本实施例中，控制服务器可以响应于用户的操作，根据用户的操作确定需要在所有业务服务器中增加或减少的容器的第五数量，即根据用户需求确定需要扩大目标应用程序的容量或降低目标应用程序的容量，并确定具体的容器数量。实际使用时，用户需要根据目标应用程序的运行情况，主动调整目标应用程序的容量。例如，在某个特定时间段，当用户访问量增加时，用户可以手动增加目标应用程序的容量(增加一定数量的容器)，在用户访问量减少时，手动减少目标应用程序的容量(减少一定数量的容器)。
例如，用户可以操作客户端，通过客户端向服务器发送增加或减少指令，以及第五数量。控制服务器接收到客户端发送的增加或减少指令后，可以根据每个业务服务器发送的第二监测数据和第五数量确定第三目标服务器，并确第六数量。控制服务器根据每个业务服务器发送的第二监测数据和第五数量，确定第三目标服务器和第六数量的过程，可参考前述实施例中控制服务器根据第一数量和每个业务服务器发送的第二监测数据确定第二目标服务器和第二数量的过程，本实施例在此不做赘述。控制服务器可以响应于用户的操作，确定需要增加或减少的容器的数量，在对应的业务服务器中增加或减少一定数量的容器，以控制目标应用程序的容量，可以根据用户需求对目标应用程序的容量进行调节，可以提高系统维护的灵活性，提高系统的运行效率。
可选的，该方法还可以包括：
在确定第四目标服务器故障的情况下，确定第四目标服务器中部署的容器的数量，第四目标服务器为至少一个业务服务器中的任一服务器；
根据除第四目标服务器之外的每个业务服务器发送的第二监测数据和第四目标服务器中部署的容器的数量，从除第四目标服务器之外的所有业务服务器中确定至少一个第五目标服务器，并确定需要在第五目标服务器中增加的容器的第七数量
向第五目标服务器发送的第四指令，以使第五目标服务器根据第四指令，增加第七数量的容器。
本实施例中，控制服务器可以监测每个业务服务器的运行状态，在确定某一个业务服务器故障，无法运行容器时，可以在正常运行的业务服务器中增加一定量的容器，维持目标应用程序的容量不变，以提高目标应用程序的稳定性。
具体的，控制服务器可以接收每个业务服务器发送的故障信号，例如控制服务器在接收到业务服务器1(第四目标服务器)的故障信号时，可以确定业务服务器1发生故障，无法运行容器。若业务服务器1部署有10个容器，则可以在业务服务器2和业务服务器3中增加10个容器，保持容器数量不变，以保持目标应用程序的容量不变。控制服务器根据业务服务器1部署的容器数量，以及业务服务器2和业务服务器3分别发送的第二监测数据，从业务服务器2和业务服务器3中确定第五目标服务器的方法可参考前述实施例中，控制服务器根据第一数量和每个业务服务器发送的第二监测数据确定第一目标服务器和第二数量的过程，本实施例在此不做赘述。控制服务器确定业务服务器故障的方法可以根据实际需求确定，例如可以在预设时间长度内没有接收到业务服务器发送的第一监测数据和第二监测数据的情况下，确定业务服务器故障，本实施例对此不做限制。
本实施例中，控制服务器可以在目标应用程序的负载较高时增加一定数量的容器，在负载较低时减少一定数量的容器，可以自动调节目标应用程序的容量，避免人工手动调节目标应用程序的容量时操作繁琐，耗时较长的问题，提高系统维护的实时性，并根据负载的高低灵活的调整目标应用程序的容量，可以提高系统的运行效率。同时，在业务服务器故障时，可以自动在正常运行的业务服务器中增加一定数量的容器，保持目标应用程序的容量不变，可以提高系统的稳定性。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
参照图4，示出了本申请的一种系统维护装置实施例的结构框图，具体可以包括如下模块：接收模块401、计算模块402、第一确定模块403、第二确定模块404和发送模块405。
接收模块401用于接收每个业务服务器分别发送的第一监测数据和第二监测数据，第一监测数据用于描述业务服务器中部署的目标应用程序的所有容器的负载高低，第二监测数据用于描述业务服务器的负载高低。
计算模块402用于根据每个业务服务器发送的第一监测数据，计算得到第三监测数据，第三监测数据用于描述目标应用程序的负载高低。
第一确定模块403用于在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量。
第二确定模块404用于根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量。
发送模块405用于向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的所述容器。
可选的，在本申请的一个可选实施例中，第一确定模块403还用于在第三监测数据小于或等于第二预设阈值的情况下，根据第三监测数据和第二预设阈值确定需要在所有业务服务器中减少的容器的第三数量。
第二确定模块404还用于根据每个业务服务器发送的第二监测数据和第三数量，从至少一个业务服务器中确定至少一个第二目标服务器，并确定需要在第二目标服务器中减少的容器的第四数量。
发送模块405还用于向第二目标服务器发送第二指令以使第二目标服务器根据第二指令减少第四数量的所述容器。
可选的，在本申请的一个可选实施例中，第一确定模块403还用于响应于用户操作，确定需要在所有业务服务器中增加或减少的容器的第五数量。
第二确定模块404还用于根据每个业务服务器发送的第二监测数据和第五数量，从至少一个业务服务器中确定至少一个第三目标服务器，并确定需要在第三目标服务器中增加或减少的容器的第六数量。
发送模块405还用于向第三目标服务器发送第三指令，以使第三目标服务器根据第三指令增加或减少第六数量的所述容器。
可选的，在本申请的一个可选实施例中，第一确定模块403还用于在确定第四目标服务器故障的情况下，确定第四目标服务器中部署的容器的数量，第四目标服务器为至少一个业务服务器中的任一服务器。
第二确定模块404还用于根据除第四目标服务器之外的每个业务服务器发送的第二监测数据和第四目标服务器中部署的容器的数量，从除第四目标服务器之外的所有业务服务器中确定至少一个第五目标服务器，并确定需要在第五目标服务器中增加的容器的第七数量。
发送模块405还用于向第五目标服务器发送的第四指令，以使第五目标服务器根据第四指令，增加第七数量的所述容器。
可选的，在本申请的一个可选实施例中，发送模块405还用于向每个业务服务器分别发送第五指令，以使每个业务服务器分别根据第五指令，建立并运行第八数量的所述容器，第八数量为用户预先设置的容器数量。
综上所述，本申请实施例提供的系统维护装置，包括：接收每个业务服务器分别发送的第一监测数据和第二监测数据，根据每个业务服务器发送的第一监测数据，计算得到第三监测数据，在第三监测数据大于或等于第一预设阈值的情况下，根据第三监测数据和第一预设阈值确定需要在所有业务服务器中增加的容器的第一数量，根据每个业务服务器发送的第二监测数据和第一数量，从至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在第一目标服务器中增加的容器的第二数量，向第一目标服务器发送第一指令，以使第一目标服务器根据第一指令增加第二数量的容器。通过使用容器技术运行目标应用程序，在目标应用程序的运行过程中，实时监测目标应用程序的负载和业务服务器的负载，在目标应用程序的负载较高时，根据目标应用程序的负载和业务服务器的负载在业务服务器中增加一定量的容器，对目标应用程序的容量进行扩展，可以实时的调整目标应用程序的容量，提高系统的稳定性，避免调整不及时导致的系统崩溃等问题。
本申请实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在服务器时，可以使得该服务器执行本申请实施例中各方法步骤的指令(instructions)。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
1.一种系统维护方法，其特征在于，应用于控制服务器，包括：
接收每个业务服务器分别发送的第一监测数据和第二监测数据，所述第一监测数据用于描述所述业务服务器中部署的目标应用程序的所有容器的负载高低，所述第二监测数据用于描述所述业务服务器的负载高低；
根据每个所述业务服务器发送的所述第一监测数据，计算得到第三监测数据，所述第三监测数据用于描述所述目标应用程序的负载高低；
在所述第三监测数据大于或等于第一预设阈值的情况下，根据所述第三监测数据和所述第一预设阈值确定需要在所有所述业务服务器中增加的所述容器的第一数量；
根据每个所述业务服务器发送的所述第二监测数据和所述第一数量，从所述至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在所述第一目标服务器中增加的所述容器的第二数量；
向所述第一目标服务器发送第一指令，以使所述第一目标服务器根据所述第一指令增加所述第二数量的所述容器。
2.根据权利要求1所述的方法，其特征在于，还包括：
在所述第三监测数据小于或等于第二预设阈值的情况下，根据所述第三监测数据和所述第二预设阈值确定需要在所有所述业务服务器中减少的所述容器的第三数量；
根据每个所述业务服务器发送的所述第二监测数据和所述第三数量，从所述至少一个业务服务器中确定至少一个第二目标服务器，并确定需要在所述第二目标服务器中减少的所述容器的第四数量；
向所述第二目标服务器发送第二指令，以使所述第二目标服务器根据所述第二指令减少所述第四数量的所述容器。
3.根据权利要求1所述的方法，其特征在于，还包括：
响应于用户操作，确定需要在所有所述业务服务器中增加或减少的所述容器的第五数量；
根据每个所述业务服务器发送的所述第二监测数据和所述第五数量，从所述至少一个业务服务器中确定至少一个第三目标服务器，并确定需要在所述第三目标服务器中增加或减少的所述容器的第六数量；
向所述第三目标服务器发送第三指令，以使所述第三目标服务器根据所述第三指令增加或减少所述第六数量的所述容器。
4.根据权利要求1所述的方法，其特征在于，还包括：
在确定第四目标服务器故障的情况下，确定所述第四目标服务器中部署的所述容器的数量，所述第四目标服务器为所述至少一个业务服务器中的任一服务器；
根据除所述第四目标服务器之外的每个业务服务器发送的所述第二监测数据和所述第四目标服务器中部署的所述容器的数量，从除所述第四目标服务器之外的所有业务服务器中确定至少一个第五目标服务器，并确定需要在所述第五目标服务器中增加的所述容器的第七数量；
向所述第五目标服务器发送的第四指令，以使所述第五目标服务器根据所述第四指令，增加所述第七数量的所述容器。
5.根据权利要求1-4任一项所述的方法，其特征在于，在所述接收每个业务服务器分别发送的第一监测数据和第二监测数据之前，还包括：
向每个所述业务服务器分别发送第五指令，以使每个所述业务服务器分别根据所述第五指令，建立并运行第八数量的所述容器，所述第八数量为用户预先设置的容器数量。
6.一种系统维护装置，其特征在于，设置于控制服务器，包括：
接收模块，用于接收每个业务服务器分别发送的第一监测数据和第二监测数据，所述第一监测数据用于描述所述业务服务器中部署的目标应用程序的所有容器的负载高低，所述第二监测数据用于描述所述业务服务器的负载高低；
计算模块，用于根据每个所述业务服务器发送的所述第一监测数据，计算得到第三监测数据，所述第三监测数据用于描述所述目标应用程序的负载高低；
第一确定模块，用于在所述第三监测数据大于或等于第一预设阈值的情况下，根据所述第三监测数据和所述第一预设阈值确定需要在所有所述业务服务器中增加的所述容器的第一数量；
第二确定模块，用于根据每个所述业务服务器发送的所述第二监测数据和所述第一数量，从所述至少一个业务服务器中确定至少一个第一目标服务器，并确定需要在所述第一目标服务器中增加的所述容器的第二数量；
发送模块，用于向所述第一目标服务器发送第一指令，以使所述第一目标服务器根据所述第一指令增加所述第二数量的所述容器。
7.根据权利要求1所述的装置，其特征在于，所述第一确定模块，还用于在所述第三监测数据小于或等于第二预设阈值的情况下，根据所述第三监测数据和所述第二预设阈值确定需要在所有所述业务服务器中减少的所述容器的第三数量；
所述第二确定模块，还用于根据每个所述业务服务器发送的所述第二监测数据和所述第三数量，从所述至少一个业务服务器中确定至少一个第二目标服务器，并确定需要在所述第二目标服务器中减少的所述容器的第四数量；
所述发送模块，还用于向所述第二目标服务器发送第二指令，以使所述第二目标服务器根据所述第二指令减少所述第四数量的所述容器。
8.根据权利要求1所述的装置，其特征在于，还包括：
所述第一确定模块，还用于响应于用户操作，确定需要在所有所述业务服务器中增加或减少的所述容器的第五数量；
所述第二确定模块，还用于根据每个所述业务服务器发送的所述第二监测数据和所述第五数量，从所述至少一个业务服务器中确定至少一个第三目标服务器，并确定需要在所述第三目标服务器中增加或减少的所述容器的第六数量；
所述发送模块，还用于向所述第三目标服务器发送第三指令，以使所述第三目标服务器根据所述第三指令增加或减少所述第六数量的所述容器。
9.根据权利要求1所述的装置，其特征在于，所述第一确定模块，还用于在确定第四目标服务器故障的情况下，确定所述第四目标服务器中部署的所述容器的数量，所述第四目标服务器为所述至少一个业务服务器中的任一服务器；
所述第二确定模块，还用于根据除所述第四目标服务器之外的每个业务服务器发送的所述第二监测数据和所述第四目标服务器中部署的所述容器的数量，从除所述第四目标服务器之外的所有业务服务器中确定至少一个第五目标服务器，并确定需要在所述第五目标服务器中增加的所述容器的第七数量；
所述发送模块，还用于向所述第五目标服务器发送的第四指令，以使所述第五目标服务器根据所述第四指令，增加所述第七数量的所述容器。
10.根据权利要求6-9任一项所述的装置，其特征在于，所述发送模块，还用于向每个所述业务服务器分别发送第五指令，以使每个所述业务服务器分别根据所述第五指令，建立并运行第八数量的所述容器，所述第八数量为用户预先设置的容器数量。
技术总结