CN110704166A - 服务运行方法、装置和服务器 - Google Patents

Abstract

本发明提供了一种服务运行方法、装置和服务器，其中，该方法包括：获取待部署服务的镜像文件和部署需求；该部署需求包括运行服务所需容器的预定数量；根据该预定数量，创建运行服务的容器；通过镜像文件，将服务部署至创建的容器中，以通过容器运行服务；监控运行服务的容器的实际数量，如果该实际数量低于预设阈值，重启运行服务的容器。该方式中，将服务部署在容器中，通过监控容器的实际数量，即可确定服务是否正常运行，如果服务运行发生故障，则通过容器自动化地重启服务，无需再由人工重启服务，从而节省了服务维护和重启所需的时间成本和人力成本，同时也提高了服务运行的稳定性。

Description

服务运行方法、装置和服务器

技术领域

本发明涉及大数据技术领域，尤其是涉及一种服务运行方法、装置和服务器。

背景技术

相关技术中，应用系统或者服务通常直接部署在服务器上，当服务器故障或者服务宕机时，服务器会发出报警信号，管理员收到该报警信号后，通常会去现场重启服务或者编写一套重启程序来重启服务，这种服务的重启方式消耗了大量的时间和人力。

发明内容

本发明的目的在于提供一种服务运行方法、装置和服务器，以节省服务维护和重启所需的时间成本和人力成本，同时提高服务运行的稳定性。

第一方面，本发明实施例提供一种服务运行方法，该方法包括：获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量；根据该预定数量，创建运行服务的容器；通过上述镜像文件，将服务部署至创建的容器中，以通过容器运行所述服务；监控运行该服务的容器的实际数量，如果实际数量低于预设阈值，重启运行服务的容器。

在本发明较佳的实施例中，上述预设阈值为预定数量；上述如果实际数量低于预设阈值，重启运行服务的容器的步骤，包括：判断该实际数量是否小于预定数量；如果小于，重启运行该服务的容器。

在本发明较佳的实施例中，上述重启运行服务的容器的步骤，包括：获取运行该服务的容器停止运行的容器；重启该停止运行的容器，以使运行服务的容器的实际数量与预设阈值相匹配。

在本发明较佳的实施例中，上述服务的数量为多个；运行每个服务的容器之间相互独立。

在本发明较佳的实施例中，上述将服务部署至创建的容器中，以通过该容器运行服务的步骤之后，该方法还包括：判断运行该服务的容器是否满足预设条件；其中，该预设条件包括：运行服务的容器的实际数量低于预设阈值，和/或，运行该服务的容器内的服务接口异常；如果满足，生成告警信息。

在本发明较佳的实施例中，上述将服务部署至创建的容器中，以通过容器运行服务的步骤之后，该方法还包括：判断运行该服务的容器的实际数量是否低于预定数量；如果低于预定数量，生成告警信息；如果等于该预定数量，针对每个运行该服务的容器，判断当前容器内的服务接口是否发生异常；如果发生异常，生成告警信息。

第二方面，本发明实施例提供一种服务运行装置，所述装置包括：服务获取模块，用于获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量；容器创建模块，用于根据预定数量，创建运行服务的容器；服务部署模块，用于通过镜像文件，将服务部署至创建的容器中，以通过容器运行服务；监控模块，用于监控运行服务的容器的实际数量，如果实际数量低于预设阈值，重启运行服务的容器。

在本发明较佳的实施例中，上述预设阈值为预定数量；该监控模块，用于：判断实际数量是否小于预定数量；如果小于，重启运行该服务的容器。

在本发明较佳的实施例中，上述监控模块，用于：获取运行所述服务的容器中停止运行的容器；重启该停止运行的容器，以使运行该服务的容器的实际数量与预设阈值相匹配。

在本发明较佳的实施例中，上述服务部署模块之后，该装置还包括告警模块，用于：判断运行该服务的容器是否满足预设条件；其中，该预设条件包括：运行服务的容器的实际数量低于预设阈值，和/或，运行服务的容器内的服务接口异常；如果满足，生成告警信息。

第三方面，本发明实施例提供一种服务器，包括处理器和存储器，该存储器存储有能够被处理器执行的机器可执行指令，该处理器执行机器可执行指令以实现上述服务运行方法。

第四方面，本发明实施例提供一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述服务运行方法。

本发明实施例带来了以下有益效果：

本发明提供的一种服务运行方法、装置和服务器，首先获取待部署服务的镜像文件和部署需求，进而根据部署需求中的运行服务所需容器的预定数量，创建运行服务的容器；再通过镜像文件将服务部署至创建的容器中，以通过容器运行服务；在运行服务的过程中，监控运行服务的容器的实际数量，如果该实际数量低于预设阈值，则重启运行服务的容器。该方式中，将服务部署在容器中，通过监控容器的实际数量，即可确定服务是否正常运行，如果服务运行发生故障，则通过容器自动化地重启服务，无需再由人工重启服务，从而节省了服务维护和重启所需的时间成本和人力成本，同时也提高了服务运行的稳定性。

附图说明

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

图1为本发明实施例提供的一种服务运行的场景的示意图；

图2为本发明实施例提供的一种服务运行方法的流程图；

图3为本发明实施例提供的另一种服务运行方法的流程图；

图4为本发明实施例提供的另一种服务运行方法的流程图；

图5为本发明实施例提供的另一种服务运行方法的流程图；

图6为本发明实施例提供的一种服务运行装置的结构示意图；

图7为本发明实施例提供的一种服务器的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

相关技术中，应用系统或者服务通常直接部署在物理服务器上，当服务故障时，需要人工重启服务，或者通过人工编写程序自动化重启服务，这种服务的重启方式消耗了大量的时间和人力。而且一台物理机上可能部署多个服务，服务之间可能会互相影响。基于此，本发明实施例提出的一种服务运行方法、装置和服务器，该技术可以应用于服务部署、服务监控、系统部署、系统监控等场景中。

为了便于对本发明实施例进行理解，图1示出了一种服务运行的场景，该场景可以通过Kubernetes(简称K8S)软件实现；该图中监控节点与云平台的工作节点连接，该工作节点中运行有多个最小执行调度单元(也可以简称为Pod)，一个Pod中运行有一个或者多个容器，该容器中部署有服务，监控节点可以监控服务的运行。在另一种服务运行的场景中，在服务器上安装有Kubernetes软件，基于该软件在服务器上构建容器运行环境，以使服务部署在容器中。

Kubernetes构建的容器运行环境中，通过控制器对象Deployment，可以维持一个固定的Pod数量(比如1或2等)，当Pod出现故障停止运行导致现有Pod副本数量小于定义的固定数量，K8S会自动重启Pod以及容器内的服务，保证现有Pod副本数始终和定义的数量一致。基于上述原理，本发明实施例中，可在Pod中封装一个容器，一个Pod等同于一个容器，Pod的数量等同于容器的数量，则对于某个运行的服务，可以维持一个固定的容器数量即Pod数量(比如1或2等)，当容器出现故障停止运行，导致运行服务的容器数量小于规定的容器数量，可以自动重启容器内的服务，保证运行服务的容器数量始终与规定的容器数量一致，从而监控服务的运行状态。

上述Kubernetes是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理，内建强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

基于上述描述，下面对本发明实施例所公开的一种服务运行方法进行详细介绍；如图2所示，该方法包括如下步骤：

步骤S202，获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量。

用户可以将上述待部署服务打包到容器镜像中，当需要部署该服务时，可以从容器镜像中得到待部署服务对应的镜像文件。其中，容器镜像通常是挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，该系统文件中保存有镜像文件。该镜像文件通常是只读文件，通过该镜像文件可以启动多个容器，且每个容器可以共享该镜像文件。

上述部署需求通常与待部署服务的大小或复杂程度有关系，如果服务较小或较为简单，一个容器即可运行该服务；如果服务较大或者较为复杂，则可能需要多个容器运行该服务。该部署需求通常保存在数据库中，根据待部署服务可以从数据库中调取相应的部署需求。

步骤S204，根据上述预定数量，创建运行该服务的容器。

通常情况下可以通过Kubernetes中的容器创建指令，如create指令，创建预定数量的容器。在具体实现时，可以在Kubernetes中创建一个控制器对象，通过控制器对象设置运行服务的容器的数量为预定数量。

具体的，可根据上述预定数量，创建了该预定数量的Pod，每个Pod内部封装了一个容器，该容器用于运行该服务。

步骤S206，通过上述镜像文件，将服务部署至创建的容器中，以通过该容器运行所述服务。

上述创建的容器可以通过监控节点或者控制器对象访问镜像文件，从容器镜像中获取待部署服务的镜像文件，并使用该镜像文件，启动上述创建的容器，从而将待部署服务部署在容器中。通常，一个服务可以运行在一个容器中，也可以运行在多个容器中，但通常，服务对应的一个或多个容器，不再运行其他服务，即，通过容器可以将服务进行隔离，服务之间不再共享内存、网络等资源，以防止服务之间互相影响，从而提高服务运行的可靠性。在具体实现时，可以通过Kubernetes或者启动指令启动上述容器运行，以启动运行容器中的服务。

步骤S208，监控运行上述服务的容器的实际数量，如果实际数量低于预设阈值，重启运行该服务的容器。

在具体实现时，上述预设阈值即设置为预定数量，该预定数量具体为指定的Pod副本数量，在步骤S204中，根据预定数量，创建了该预定数量的Pod，每个Pod内部封装了一个容器，该容器用于运行该服务，亦即，在Kubernetes中设定指定副本数量的容器运行待部署服务。本步骤中，可以根据预先设定的指定副本数量，即上述预定数量，利用K8S的控制器对象Deployment，检测Pod的副本数量，当Pod出现故障挂掉了导致现有Pod数量小于规定的副本数，自动重启Pod，即，当服务出现故障或者宕机时，运行的容器数量将低于指定副本数量，此时，Kubernetes将自动重启停止运行的容器。减少人工维护成本。

通常情况下可以通过Kubernetes实时或者定时监控当前运行服务的容器的实际数量。例如，Kubernetes可以通过容器监测探针Liveness Probes检测容器的运行状态，通常Liveness Probes有三种检测结果：检测通过、检测失败和检测没有正常进行，当检测失败或者检测没有正常运行时，确定对应的容器故障。

上述预设阈值通常可以根据开发需求设定，通常可以与上述预定数量相同，也可以小于预定数量。在服务正常运行的情况下，运行服务的容器的实际数量应该等于预设阈值；如果实际数量低于预设阈值，表明运行服务的部分容器出现了故障或者宕机，服务运行受到了影响，此时，Kubernetes可以自动重启该故障或者宕机的服务对应的容器，也即是Kubernetes自动触发docker start命令，直接将故障或者宕机的服务对应的容器重新启动运行起来，以使服务的所有容器都处于正常运行的状态，保证服务整体的正常运行。

本发明实施例提供的一种服务运行方法，首先获取待部署服务的镜像文件和部署需求，进而根据部署需求中的运行服务所需容器的预定数量，创建运行服务的容器；再通过镜像文件将服务部署至创建的容器中，以通过容器运行服务；在运行服务的过程中，监控运行服务的容器的实际数量，如果该实际数量低于预设阈值，则重启运行服务的容器。该方式中，将服务部署在容器中，通过监控容器的实际数量，即可确定服务是否正常运行，如果服务运行发生故障，则通过容器自动化地重启服务，无需再由人工重启服务，从而节省了服务维护和重启所需的时间成本和人力成本，同时也提高了服务运行的稳定性。

本发明实施例还提供了另一种服务运行方法，该方法在上述实施例所述方法的基础上实现；该方法重点描述重启运行服务的容器的具体过程；如图3所示，该方法包括如下步骤：

步骤S302，获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量。

步骤S304，根据上述预定数量，创建运行该服务的容器。

步骤S306，通过上述镜像文件，将服务部署至创建的容器中，以通过该容器运行所述服务。

上述服务的数量通常为多个；运行每个服务的容器之间相互独立。一个服务可以运行在一个容器中，也可以运行在多个容器中，通常服务对应的一个或多个容器，不再运行其他服务，从而通过容器将服务进行隔离，使得服务间解耦，避免了将多个服务部署在一个物理服务中互相影响的现象。

步骤S308，监控运行上述服务的容器的实际数量。

步骤S310，判断该实际数量是否低于预设阈值；如果实际数量低于预设阈值，执行步骤S310；否则，执行步骤S308。

步骤S312，获取运行上述服务的容器中停止运行的容器。

通常情况下容器出现故障或者服务宕机时，该故障容器或者服务宕机的容器将停止运行，使得当前运行服务的容器的数量小于预设阈值。为了保证服务的正常运行，需要找到停止运行的容器，并重新启动该容器。当所有服务都正常运行时，也即是实际数量等于预设阈值或者大于预设阈值时，将继续监控运行服务的容器的实际数量，以实时监控服务的运行状态。

步骤S314，重启上述停止运行的容器，以使运行该服务的容器的实际数量与上述预设阈值相匹配。

在重启停止运行的容器的同时，也重新启动了该容器中的服务。当有多个容器停止运行时，需要同时或相继重新启动多个容器，以使正在运行服务的容器的数量与预设阈值相匹配，也即是实际数量等于预设阈值或者大于预设阈值。在具体实现时，上述预设阈值可以为预定数量；此时，实际数量则等于预设阈值。那么，上述步骤S310可以通过下述步骤30-31实现：

步骤30，判断上述实际数量是否小于预定数量；如果实际数量小于预设阈值，执行步骤31；否则，继续监控运行服务的容器的实际数量。

步骤31，重启运行上述服务的容器。

当预设阈值等于预定数量时，运行服务的容器数量也等于预定数量，当运行的容器的实际数量一旦不等于预定数量，将自动重新启动停止运行的容器。在具体实现时，可以根据预先设定的指定副本数量(相当于上述预定数量)，在Kubernetes中设定指定副本数量的容器运行待部署服务，其中，Kubernetes可以启动运行指定副本数量的容器，以运行容器中的服务；当服务出现故障或者宕机时，启动运行的容器数量将低于指定副本数量，此时，Kubernetes将自动重启停止运行的容器。

上述服务运行方法，首先获取待部署服务的镜像文件和部署需求，进而根据部署需求中的运行服务所需容器的预定数量，创建运行服务的容器；再通过镜像文件将服务部署至创建的容器中，以通过容器运行服务；然后监控运行服务的容器的实际数量，如果该实际数量低于预设阈值，获取运行服务的容器中停止运行的容器，并重启该停止运行的容器，以使运行服务的容器的实际数量与预设阈值相匹配。该方式无需再人工重启服务，而且可以通过容器将服务进行隔离，避免了将多个服务部署在一个物理服务中互相影响的现象，同时，该方式可以保证服务运行的可靠性。

本发明实施例还提供了另一种服务运行方法，该方法在上述实施例所述方法的基础上实现；该方法重点描述监控运行服务的容器的具体过程；如图4所示，该方法包括如下步骤：

步骤S402，获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量。

步骤S404，根据上述预定数量，创建运行该服务的容器。

步骤S406，通过上述镜像文件，将服务部署至创建的容器中，以通过该容器运行所述服务。

步骤S408，判断运行上述服务的容器是否满足预设条件；如果满足预设条件，执行步骤S410；否则，继续执行步骤S408。

其中，该预设条件包括：运行服务的容器的实际数量低于预设阈值，和/或，运行该服务的容器内的服务接口异常。

通常，可以实时或者定时判断运行服务的容器是否满足预设条件，以监控容器内服务的运行状态。在具体实现时，可以仅判断运行服务的容器的实际数量是否低于预设阈值，可以仅判断运行服务的容器内的服务接口是否异常，也可以既判断运行服务的容器的实际数量是否低于预设阈值，又判断运行服务的容器内的服务接口是否异常。其中，服务接口异常可以理解为服务接口不通，通过该服务接口无法在容器内接通对应的服务，当通过服务接口无法在容器内接通对应的服务时，表明该服务处于异常状态，可以理解为该服务不可用。

步骤S410，生成告警信息。

上述告警信息可以是告警提示图片，也可以是蜂鸣等告警声音。当运行服务的容器满足预设条件，也可以理解为当前服务已经出现故障，此时，系统将生成告警信息。通常可以将该告警信息发送给管理员，以提醒管理员采取相应的措施，或者系统根据该告警信息重新启动容器，以使容器中的服务重新正常运行。

另一种方式中，还可以通过下述步骤40-43判断是否需要生成告警信息：

步骤40，判断运行服务的容器的实际数量是否低于预定数量；如果低于预定数量；执行步骤42；否则，执行步骤41。

步骤41，针对每个运行服务的容器，判断当前容器内的服务接口是否发生异常；如果是，执行步骤42，否则，结束。

步骤42，生成告警信息。

在具体实现时，上述判断运行服务的容器的实际数量是否低于预定数量的过程也可以看成对服务状态的监控过程，首先需要判断当前运行服务的容器的数量，如果实际运行的数量(相当于上述实际数量)小于预设阈值时，可以确定当前存在不可用的服务，此时可以向管理员发送告警信息；当实际运行的数量等于预定数量时，由于存在容器运行正常但容器内的服务运行不正常的现象，因此需要查看正在运行的容器内的服务的运行状态，以确定容器内的服务是否运行正常；通常通过调用容器内服务对应的服务接口，可以判定服务是否运行正常，例如，当服务接口可以接通时，确定服务运行正常，当服务接口没有接通时，可以向管理员发送告警信息。

上述服务运行方法，首先获取待部署服务的镜像文件和部署需求，进而根据部署需求中的运行服务所需容器的预定数量，创建运行服务的容器；再通过镜像文件将服务部署至创建的容器中，以通过容器运行服务；然后判断运行服务的容器是否满足预设条件；如果满足预设条件生成告警信息。该方式可以通过运行服务的容器的实际数量和判断服务的容器内的服务接口是否异常，来监控服务的运行状态，这种二级监控的方式，保障了服务的高可用和抗故障能力。

本发明实施例还提供了另一种服务运行方法，该方法在上述实施例所述方法的基础上实现；该方法重点描述通过Kubernetes控制服务运行的具体过程；如图5所示，该方法包括如下步骤：

步骤S502，获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量。

步骤S504，通过Kubernetes创建预定数量的运行上述服务的容器。

在具体实现时，可以在Kubernetes中创建一个Deployment，通过Deployment设置容器的数量，可以得到预定数量的容器。该Deployment通常是Kubernetes中的一个控制器对象，它可以维持运行一个固定数量的容器，也可以理解为Deployment可以保证当前运行的容器数量与定预定数量一致。

步骤S506，通过上述镜像文件，将服务部署至创建的容器中。

在具体实现时，上述镜像文件中的待部署服务部署在Kubernetes的Deployment中，以通过Deployment中的容器运行待部署服务。

步骤S508，通过Kubernetes启动运行上述容器，以运行该容器中部署的服务。

步骤S510，监控运行上述服务的容器的实际数量。

步骤S512，判断上述实际数量是否低于预定数量；如果低于预定数量，执行步骤S514；否则，执行步骤S510。

步骤S514，获取停止运行的容器，通过Kubernetes重启该停止运行的容器，以使运行服务的容器的实际数量等于预定数量。

在监控服务运行状态时，可以通过查看Deployment中存活的副本数量(也即是实际数量)判断服务的状态，当存活的副本数量等于预定数量时，再调用容器内部署的服务接口进一步验证服务的状态，以通过两级监控的方式，保证服务的可用性。

上述服务运行方法，首先获取待部署服务的镜像文件和部署需求，再通过Kubernetes创建部署需求中指定的预定数量的容器，以在该容器中运行服务，进而通过上述镜像文件将服务部署至创建的容器中，然后通过Kubernetes启动运行上述容器，以运行该容器中部署的服务，实时监控运行服务的容器的实际数量，并判断该实际数量是否低于预定数量，如果低于预定数量，获取停止运行的容器，通过Kubernetes重启该停止运行的容器，以使运行服务的容器的实际数量等于预定数量。该方式中借助Kubernetes强大的故障发现和修复能力，在服务故障时无需人工重启服务，节省了大量的时间和人力成本，同时也保障了服务的高可用性和抗故障能力。

对应于上述方法实施例，本发明实施例提供了一种服务运行装置，如图6所示，该装置包括：

服务获取模块60，用于获取待部署服务的镜像文件和部署需求；其中，该部署需求包括运行服务所需容器的预定数量；

容器创建模块61，用于根据所述预定数量，创建运行所述服务的容器；

服务部署模块62，用于通过镜像文件，将服务部署至创建的容器中，以通过容器运行所述服务；

监控模块63，用于监控运行服务的容器的实际数量，如果实际数量低于预设阈值，重启运行该服务的容器。

上述服务运行装置，首先获取待部署服务的镜像文件和部署需求，进而根据部署需求中的运行服务所需容器的预定数量，创建运行服务的容器；再通过镜像文件将服务部署至创建的容器中，以通过容器运行服务；在运行服务的过程中，监控运行服务的容器的实际数量，如果该实际数量低于预设阈值，则重启运行服务的容器。该方式中，将服务部署在容器中，通过监控容器的实际数量，即可确定服务是否正常运行，如果服务运行发生故障，则通过容器自动化地重启服务，无需再由人工重启服务，从而节省了服务维护和重启所需的时间成本和人力成本，同时也提高了服务运行的稳定性。

进一步地，上述预设阈值为所述预定数量；上述监控模块63，用于：判断实际数量是否小于预定数量；如果小于，重启运行该服务的容器。

进一步地，上述监控模块63，用于：获取运行该服务的容器中，停止运行的容器；重启该停止运行的容器，以使运行服务的容器的实际数量与预设阈值相匹配。

上述服务的数量为多个；运行每个该服务的容器之间相互独立。

进一步地，上述服务部署模块62之后，所述装置还包括告警模块，用于：判断运行该服务的容器是否满足预设条件；其中，预设条件包括：运行服务的容器的实际数量低于预设阈值，和/或，运行该服务的容器内的服务接口异常；如果满足，生成告警信息。

进一步地，上述告警模块，用于：判断运行服务的容器的实际数量是否低于预定数量；如果低于预定数量，生成告警信息；如果等于预定数量，针对每个运行服务的容器，判断当前容器内的服务接口是否发生异常；如果发生异常，生成告警信息。

本发明实施例所提供的服务运行装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。

本发明实施例还提供了一种服务器，用于运行上述服务运行方法；参见图7所示，该服务器包括存储器100和处理器101，其中，存储器100存储有能够被处理器101执行的机器可执行指令，该处理器101执行机器可执行指令以实现上述服务运行方法。

其中，存储器100可能包含高速随机存取存储器(RAM，RandomAccessMemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口103(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线102可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器101可以是通用处理器，包括中央处理器(CentralProcessingUnit，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器100，处理器101读取存储器100中的信息，结合其硬件完成前述实施例的方法的步骤。

本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述服务运行方法。具体实现可参见方法实施例，在此不再赘述。

本发明实施例所提供的服务运行方法、装置和服务器的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和/或电子设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种服务运行方法，其特征在于，所述方法包括：

获取待部署服务的镜像文件和部署需求；其中，所述部署需求包括运行所述服务所需容器的预定数量；

根据所述预定数量，创建运行所述服务的容器；

通过所述镜像文件，将所述服务部署至创建的容器中，以通过所述容器运行所述服务；

监控运行所述服务的容器的实际数量，如果所述实际数量低于预设阈值，重启运行所述服务的容器。

2.根据权利要求1所述的方法，其特征在于，所述预设阈值为所述预定数量；

所述如果所述实际数量低于预设阈值，重启运行所述服务的容器的步骤，包括：

判断所述实际数量是否小于所述预定数量；

如果小于，重启运行所述服务的容器。

3.根据权利要求1或2所述的方法，其特征在于，重启运行所述服务的容器的步骤，包括：

获取运行所述服务的容器中停止运行的容器；

重启所述停止运行的容器，以使运行所述服务的容器的实际数量与所述预设阈值相匹配。

4.根据权利要求1所述的方法，其特征在于，所述服务的数量为多个；运行每个所述服务的容器之间相互独立。

5.根据权利要求1所述的方法，其特征在于，将所述服务部署至创建的容器中，以通过所述容器运行所述服务的步骤之后，所述方法还包括：

判断运行所述服务的容器是否满足预设条件；其中，所述预设条件包括：运行所述服务的容器的实际数量低于预设阈值，和/或，运行所述服务的容器内的服务接口异常；

如果满足，生成告警信息。

6.根据权利要求1所述的方法，其特征在于，将所述服务部署至创建的容器中，以通过所述容器运行所述服务的步骤之后，所述方法还包括：

判断运行所述服务的容器的实际数量是否低于所述预定数量；

如果低于所述预定数量，生成告警信息；

如果等于所述预定数量，针对每个运行所述服务的容器，判断当前容器内的服务接口是否发生异常；

如果发生异常，生成告警信息。

7.一种服务运行装置，其特征在于，所述装置包括：

服务获取模块，用于获取待部署服务的镜像文件和部署需求；其中，所述部署需求包括运行所述服务所需容器的预定数量；

容器创建模块，用于根据所述预定数量，创建运行所述服务的容器；

服务部署模块，用于通过所述镜像文件，将所述服务部署至创建的容器中，以通过所述容器运行所述服务；

监控模块，用于监控运行所述服务的容器的实际数量，如果所述实际数量低于预设阈值，重启运行所述服务的容器。

8.根据权利要求7所述的装置，其特征在于，所述预设阈值为所述预定数量；所述监控模块，用于：判断所述实际数量是否小于所述预定数量；如果小于，重启运行所述服务的容器。

9.根据权利要求7或8所述的装置，其特征在于，所述监控模块，用于：

获取运行所述服务的容器中，停止运行的容器；

重启所述停止运行的容器，以使运行所述服务的容器的实际数量与所述预设阈值相匹配。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括告警模块，用于：

判断运行所述服务的容器是否满足预设条件；其中，所述预设条件包括：运行所述服务的容器的实际数量低于预设阈值，和/或，运行所述服务的容器内的服务接口异常；

如果满足，生成告警信息。

11.一种服务器，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1至6任一项所述的服务运行方法。

12.一种机器可读存储介质，其特征在于，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使处理器实现权利要求1至6任一项所述的服务运行方法。

Images