CN114327752A - 一种微服务配置方法、装置及设备 - Google Patents

Abstract

本发明提供一种微服务配置方法、装置及设备，该方法包括：接收主服务器下发的应用部署指令，应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；启用主协程按任务逻辑执行顺序执行对应的任务；确定需执行挂载任务时，触发启用新协程，并将挂载任务交由新协程执行后开始计时；在计时超过设定时长前，触发主协程执行挂载任务的下一个任务，利用本方案解决了在挂载命令超时或者挂载命令hung住时，kubelet进程等待挂载完成导致后续容器均无法正常创建，影响平台环境稳定性的问题。

Description

一种微服务配置方法、装置及设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种微服务配置方法、装置及设备。

背景技术

在云平台集群环境，例如基于K8S(Kubernetes)的容器云集群下，有大量的微服务，通过主服务器与相应的节点服务器交互，在不同的节点服务器上容器内进行应用部署，使各容器实现相应的微服务。在相应的节点服务器的容器中进行应用部署过程中，容器内多个进程共享的文件的路径需要配置到该容器指定文件夹位置，即将共享文件夹的文件的目录路径挂载到该容器上。

目前，对容器执行应用部署是由节点服务器上的kubelet进程实现的，kubelet进程用于执行主管理服务器下发的任务，将实现微服务的文件目录挂载到相应的容器上，在挂载过程中，可能挂载的是本地文件目录，也可能挂载的是远程文件目录，kubelet进程在执行挂载操作时，通过systemd调用挂载mount命令执行挂载。该方法在挂载命令超时或者挂载命令hung住时，kubelet进程会等待直到挂载成功，在没有挂载成功之前，kubelet进程无法响应其他创建、删除、更新容器请求，导致后续调度到该服务器的容器均无法正常创建，影响平台环境稳定性。

发明内容

本发明提供了一种微服务配置方法，用于解决在挂载命令超时或者挂载命令hung住时，kubelet进程等待挂载完成而无法响应其他创建、删除、更新容器的请求，导致后续调度到该服务器的容器均无法正常创建，影响平台环境稳定性的问题。

第一方面，本发明提供一种微服务配置方法，该方法包括：

接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

启用主协程按所述任务逻辑执行顺序执行对应的任务；

确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

一种可选的实施方式为，该方法还包括：

周期性根据新协程执行挂载任务的结果，确定将各本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载状态，所述挂载状态包括挂载成功、挂载失败、正在执行挂载；

将确定的挂载状态反馈给主服务器，以使主服务器根据所述确定的挂载状态调整下一次下发的挂载任务，并在到达下一任务下发时将调整后的挂载任务通过应用部署指令再次下发。

一种可选的实施方式为，在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务，包括：

确定在计时超过设定时长前，新协程完成挂载任务时，触发主协程执行所述挂载任务的下一个任务；或者

确定新协程未完成挂载任务且计时达到设定时长时，触发主协程执行所述挂载任务的下一个任务；

其中，确定所述新协程完成挂载任务后，关闭所述新协程。

一种可选的实施方式为，确定需执行所述挂载任务时，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时，包括：

确定需执行所述挂载任务时，判断是否当前已经启用新协程执行所述应用对应的挂载任务；

确定当前未启用新协程执行所述应用对应的挂载任务，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时。

一种可选的实施方式为，判断是否当前已经启用新协程执行所述应用对应的挂载任务之后，还包括：

确定当前已启用新协程执行所述应用对应的挂载任务，开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

一种可选的实施方式为，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署新应用的应用部署指令，创建新容器并确定在所述新容器中部署新应用需执行的任务及任务逻辑执行顺序；或者

接收主服务器下发的对应用更新的应用部署指令，确定所述应用所在的原容器，并确定对所述原容器部署的应用进行更新需执行的任务及任务逻辑执行顺序。

一种可选的实施方式为，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署至少一个应用的应用部署指令；

确定部署的至少一个应用分别对应的容器，并确定在各容器部署应用需执行的任务及任务逻辑执行顺序；

启用主协程按所述任务逻辑执行顺序执行对应的任务，包括：

对所述部署的至少一个应用分别对应的容器，分别启用对应的主协程按在该容器部署应用的任务逻辑执行顺序执行对应的任务。

一种可选的实施方式为，将所述挂载任务交由所述新协程执行后，还包括：

通过所述新协程，在本地文件目录/远程文件目录中进行遍历查找；

待查找到需挂载文件的本地文件目录/远程文件目录时，将查找到的本地文件目录/远程文件目录挂载到容器中。

第二方面，一种微服务配置装置，该装置包括：

指令接收模块，用于接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

主协程启用模块，用于启用主协程按所述任务逻辑执行顺序执行对应的任务；

挂载任务执行模块，用于确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

任务执行模块，用于在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

第三方面，本发明提供了一种微服务配置设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述微服务配置方法中任一项所述的步骤。

第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述微服务配置方法中任一项所述的步骤。

上述方法，通过启用新协程执行挂载任务，解决了在挂载命令超时或者挂载命令hung住时，kubelet进程等待挂载完成而无法响应其他创建、删除、更新容器的请求，导致后续调度到该服务器的容器均无法正常创建，影响平台环境稳定性的问题。

附图说明

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

图1为本发明提供的一种K8S架构的示意图；

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

图3为本发明实施例提供的一种挂载任务执行方法的示意图；

图4为本发明实施例提供的一种微服务配置方法示例的示意图；

图5为本发明实施例提供的一种微服务配置装置的流程图；

图6为本发明实施例提供的一种微服务配置设备的流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

下面，如图1所示，对本发明中提到的K8S(Kubernetes)架构进行介绍：Kubernetes集群由一个正在运行的主节点服务器Master以及受主节点服务器调度的多个节点服务器Node组成。

Master主要负责整个集群的管理，比如容器的调度、维护资源的状态、自动扩展以及滚动更新等，主要包括四个核心组件，分别为：

1、kube-apiserver：提供资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

2、kube-scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的节点上，并更新数据库中pod的节点信息(Node Name字段)，记录pod分配情况；

3、controller-manager：Kubernetes的“大脑”，通过kube-apiserver监控整个集群的状态，并确保集群处于预期的工作状态，包括kube-controller-manager和cloud-controller-manager；

4、etcd：保存整个集群的状态。

Node是运行具体容器的主机，负责管理镜像和容器以及cluster内的服务发现和负载均衡，主要包括四个核心组件，分别为：

1、kubelet：主要用于创建、销毁pod，监听etcd中资源变化，接收并启动kubelet进程处理Master下发到本节点的任务，按照Pod Spec描述管理当前节点的pod及pod中的容器(Pod Spec是用来描述一个pod的yaml或者json对象，主要通过kube-apiserver获取)，定期向Master汇报节点的资源使用情况，并监控节点和容器的资源；

2、container runtime：负责镜像管理以及pod和容器的真正运行(CRI)；

3、kube-proxy：负责K8S的通信和负载均衡机制；

4、pod：K8S调度的基本单位，一组紧密关联的容器集合，也相当于一个“进程组”，包含多个共享IPC、Network和UTC namespace的容器，每个容器都封装有一个进程，多个容器相互配合实现一个应用实例。

以下对K8S中容器挂载进行解释：

在K8S系统中存在数据卷volume的概念，K8S支持许多类型的volume，pod可以同时使用任意类型/数量的volume，不同类型的数据卷对应不同的存储介质，如nfs、PVC、ConfigMap。

内部实现中，volume只是一个目录，目录中可能有一些数据，pod的容器可以访问这些数据，这个目录的产生方式、支持它的介质、其中的数据内容都由使用的特定volume类型来决定，如果要使用volume，pod需要指定volume的类型和内容(spec.volumes字段)，及映射到容器的位置(spec.containers.volumeMounts字段)。

数据卷volume主要为解决如下两方面问题：

1、数据持久性：通常情况下，容器运行起来之后，写入到其文件系统的文件暂时性的，当容器崩溃后，kubelet将会重启该容器，此时原容器运行后写入的文件将丢失，因为容器将重新从镜像创建。

2、数据共享：同一个pod(容器组)中运行的容器之间，经常会存在共享文件/文件夹的需求。

Volume作为pod中多个容器访问的共享目录定义在pod上，被pod的多个容器挂载到相同或不同的路径下，其生命周期与pod绑定，当容器崩溃后，kubelet再次重启容器时，volume的数据依然存在，仅当pod被删除时，volume才会清理。其中，kubelet再次重启容器时数据是否丢失取决于具体的volume类型，比如empty Dir的数据会丢失，而PV的数据则不会丢失。

容器挂载即是指将定义在pod中的数据卷volume关联到容器，同一个pod中的同一个volume可以被挂载到该pod中的多个容器上，如此解决了容器数据持久化和容器间共享数据的问题。

基于上述K8S架构，当用户需要进行应用部署时，首先向kube-apiserver发起请求，kube-apiserver接收到客户端发送的请求后，根据新的pod模板生成pod api对象并存储到etcd中，kube-scheduler监听etcd中pod变化，基于自身算法给pod分配Node，并更新etcd中记录，记录pod分配情况。

Node中的kubelet通过kube-apiserver接收到应用部署任务后，启动kubelet进程处理该部署任务。

需要注意的是，上述过程仅是在进行前期的配置或者系统的更新发生的，当完成前期配置或系统更新后，主服务器与节点服务器实现解耦，终端用户进行直接向对应节点发送请求，由对应节点来执行对应的应用即可，无需通过主服务器来实现。

但是当应用部署指令中存在挂载任务时，挂载任务执行过程中易发生因遍历目录数据量过大导致挂载命令超时或者挂载命令hung的情况，并且该情况一旦发生就会使kubelet进程长时间等待挂载，无法响应其他创建，删除，更新容器请求，导致后续调度到该服务器的容器均无法正常创建，影响平台环境稳定性。

为解决上述问题，本发明实施例提供一种微服务配置方法，下面结合说明书附图对本发明实施例做进一步详细描述。

实施例1

如图2所示，本发明实施例提供一种微服务配置方法，包括：

步骤201，接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

用户在需要进行应用部署时，向主服务器中的kube-apiserver发送请求，该请求可以为yaml文件或者http请求，上述请求中携带完成该请求所需的全部相关资源，例如，如果该请求为创建一个新pod来实现新的微服务功能，则请求中携带创建pod需要的全部配置信息，如环境变量、启动命令、挂载内容等。

其中，由于对应用进行部署的过程可能分为多次来完成，因此用户可能多次发起应用部署请求来实现对应用的部署。

kube-apiserver接收到请求后，将该请求对应的应用部署指令存储在etcd中，位于当前节点服务器中的kubelet通过主服务器中的kube-apiserver周期性监听etcd中关于当前节点的相关信息，进而接收主服务器下发的当前节点对应的应用部署指令，上述监听周期默认为10s。

步骤202，启用主协程按所述任务逻辑执行顺序执行对应的任务；

步骤203，确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

如图3所示，kubelet确定需要执行的下一任务为挂载任务时，启用新协程，以将本地文件目录或远程文件目录挂载到pod的容器中。

实施中，确定需执行所述挂载任务时，在触发启用新协程之前，还需判断当前是否已存在正在执行当前应用对应的挂载任务的协程，如果不存在则启用新协程，如果存在则等待并开始计时，不再启用新协程。

作为一种可选的实施方式，确定需执行所述挂载任务时，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时，包括：

确定需执行所述挂载任务时，判断是否当前已经启用新协程执行所述应用对应的挂载任务；

确定当前未启用新协程执行所述应用对应的挂载任务，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时。

作为一种可选的实施方式，判断是否当前已经启用新协程执行所述应用对应的挂载任务之后，还包括：

确定当前已启用新协程执行所述应用对应的挂载任务，开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

步骤204，在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务；

上述计时超过设定时长前包括两种情况，分别为在设定时长内完成挂载任务和到达预设时长仍为完成上述挂载任务，上述完成挂载任务包括挂载成功和挂载失败两种情形。

当到达预设时长仍未完成上述挂载任务时，返回错误信息，以使主协程在接收错误信息后执行挂载任务后的下一个任务，此时，上述用于挂载的协程仍执行挂载任务，至挂载任务完成。

作为一种可选的实施方式，在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务，包括：

确定在计时超过设定时长前，新协程完成挂载任务时，触发主协程执行所述挂载任务的下一个任务；或者

确定新协程未完成挂载任务且计时达到设定时长时，触发主协程执行所述挂载任务的下一个任务；

其中，确定所述新协程完成挂载任务后，关闭所述新协程。

上述方法，通过启用新协程执行挂载任务，解决了在挂载命令超时或者挂载命令hung住时，kubelet进程等待挂载完成而无法响应其他创建、删除、更新容器的请求，导致后续调度到该服务器的容器均无法正常创建，影响平台环境稳定性的问题。

上述步骤201中，应用部署指令可分为部署新应用的应用部署指令和对已有应用进行更新的应用部署指令，其中都携带有将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务。

在本发明实施例中，上述部署新应用是指创建一个新pod，上述对已有应用进行更新是指对已创建的pod进行更新。

需要说明的是，上述挂载任务是针对一个应用(pod)即一个容器集合的挂载任务，该挂载任务中包括对上述应用中全部需挂载的容器进行挂载，实施过程中，如果该应用中有一个容器挂载未完成，即认定为该挂载任务未完成。

并且，由于挂载任务是针对一个应用的挂载任务，可能包含多个对单个容器进行挂载的子任务，在该挂载任务执行过程中，可能已有部分容器的挂载子任务已完成，因此，当该挂载任务执行过程中，该应用中单个容器的挂载状态可能为挂载成功、挂载失败和正在执行挂载。

作为一种可选的实施方式，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署新应用的应用部署指令，创建新容器并确定在所述新容器中部署新应用需执行的任务及任务逻辑执行顺序；或者

接收主服务器下发的对应用更新的应用部署指令，确定所述应用所在的原容器，并确定对所述原容器部署的应用进行更新需执行的任务及任务逻辑执行顺序。

实施中，如果上述主服务器下发的应用部署指令为部署多个应用，则在执行该应用部署指令对应的任务时，对多个应用的部署任务独立进行，即启用各应用对应的主协程来执行对应的部署任务，并且在执行任一应用的部署任务时，在执行到对应的挂载任务时调用各自的协程来执行挂载任务，例如，接收到对两个pod(pod 1和pod 2)进行部署的应用部署指令，且每个pod对应的应用部署指令中都包含挂载任务，则pod 1和pod 2的部署任务都是启用各自的主程序来完成的，且pod 1对应的挂载任务的完成情况并不会对pod 2对应的挂载任务的完成情况造成影响，即如果pod 1对应的挂载任务超时，pod 2对应的挂载任务仍可以正常执行。

作为一种可选的实施方式，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署至少一个应用的应用部署指令；

确定部署的至少一个应用分别对应的容器，并确定在各容器部署应用需执行的任务及任务逻辑执行顺序；

启用主协程按所述任务逻辑执行顺序执行对应的任务，包括：

对所述部署的至少一个应用分别对应的容器，分别启用对应的主协程按在该容器部署应用的任务逻辑执行顺序执行对应的任务。

上述步骤203中，作为一种可选的实施方式，将所述挂载任务交由所述新协程执行后，还包括：

通过所述新协程，在本地文件目录/远程文件目录中进行遍历查找；

待查找到需挂载文件的本地文件目录/远程文件目录时，将查找到的本地文件目录/远程文件目录挂载到容器中。

上述新协程接收到挂载任务时，根据挂载任务中携带的volume的类型及映射到容器的位置，在本地文件目录/远程文件目录找到挂载的目录，并将其挂载到对应容器中。

实施中，节点服务器会周期性确定本节点各应用中容器的挂载状态，并将各应用中容器的挂载状态反馈给主服务器，主服务器根据节点反馈的各应用中容器的挂载状态，在下一次下发挂载任务时，挂载任务中只包括挂载状态为挂载失败、正在执行挂载的挂载任务。

因此，节点服务器接收的多个应用部署指令中的第一个应用部署指令中包含该应用中对各容器进行挂载的挂载任务，而之后的应用部署指令中只包括主服务器根据反馈的该应用中容器的挂载状态调整后的仅对部分容器进行挂载的挂载任务。

节点服务器在接收到主服务再一次下发的另一应用部署指令并按任务逻辑执行顺序执行到挂载任务时，由于上一次该应用对应的挂载任务尚未执行完成，为避免多次启用新协程执行同一应用的挂载任务，在启用新协程之前，首先判断是否当前已启用新协程执行同一应用的挂载任务，确定当前未启用新协程时在启用新协程执行该挂载任务。

作为一种可选的实施方式，上述微服务配置方法，还包括：

周期性根据新协程执行挂载任务的结果，确定将各本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载状态，所述挂载状态包括挂载成功、挂载失败、正在执行挂载；

将确定的挂载状态反馈给主服务器，以使主服务器根据所述确定的挂载状态调整下一次下发的挂载任务，并在到达下一任务下发时将调整后的挂载任务通过应用部署指令再次下发。

需要注意的是，由于节点服务器中的kubelet会周期性监听etcd中关于当前节点的相关信息，因此在并未收到用户的应用部署请求时，主服务器也会周期性下发未完成的挂载任务，以使节点服务器按照上述方法执行该挂载任务。

如图4所示，以一个滚动升级的业务为例对本发明实施例微服务配置方法的具体流程进行说明：

步骤1、用户发起创建服务或者滚动更新服务请求；

步骤2、kube-apiserver接收到请求后，根据新的pod模板生成pod api对象，并存入etcd中。

步骤3、kube-scheduler监控etcd，发现未分配节点的pod，为pod分配节点，并更新etcd中pod的分配情况。

步骤4、kubelet接收应用部署指令，调用主协程执行对应任务，确定需执行所述挂载任务时，判断是否当前已经启用新协程执行该应用对应的挂载任务，若当前未启用新协程，则执行4a，若当前已经启用新协程，则执行4b；

步骤4a、触发启用新协程，执行挂载，并开始计时；

步骤4b、等待，并开始计时；

步骤5、在预设时间内完成挂载任务/到达预设时间仍未完成挂载任务时，触发主协程执行所述挂载任务的下一个任务

实施例2

以下对执行上述微服务配置方法的装置进行说明。

请参阅图5，本发明实施例提供一种微服务配置装置，该装置包括：

指令接收模块501，用于接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

主协程启用模块502，用于启用主协程按所述任务逻辑执行顺序执行对应的任务；

挂载任务执行模块503，用于确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

任务执行模块504，用于在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

可选的，该装置还包括：

挂载状态确定模块，用于周期性根据新协程执行挂载任务的结果，确定将各本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载状态，所述挂载状态包括挂载成功、挂载失败、正在执行挂载；

挂载状态反馈模块，用于将确定的挂载状态反馈给主服务器，以使主服务器根据所述确定的挂载状态调整下一次下发的挂载任务，并在到达下一任务下发时将调整后的挂载任务通过应用部署指令再次下发。

可选的，上述任务执行模块504用于在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务，包括：

确定在计时超过设定时长前，新协程完成挂载任务时，触发主协程执行所述挂载任务的下一个任务；或者

确定新协程未完成挂载任务且计时达到设定时长时，触发主协程执行所述挂载任务的下一个任务；

其中，确定所述新协程完成挂载任务后，关闭所述新协程。

可选的，上述挂载任务执行模块503用于确定需执行所述挂载任务时，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时，包括：

确定需执行所述挂载任务时，判断是否当前已经启用新协程执行所述应用对应的挂载任务；

确定当前未启用新协程执行所述应用对应的挂载任务，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时。

可选的，上述挂载任务执行模块503用于判断是否当前已经启用新协程执行所述应用对应的挂载任务之后，还包括：

确定当前已启用新协程执行所述应用对应的挂载任务，开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

可选的，上述指令接收模块501用于接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署新应用的应用部署指令，创建新容器并确定在所述新容器中部署新应用需执行的任务及任务逻辑执行顺序；或者

接收主服务器下发的对应用更新的应用部署指令，确定所述应用所在的原容器，并确定对所述原容器部署的应用进行更新需执行的任务及任务逻辑执行顺序。

可选的，上述指令接收模块501用于接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署至少一个应用的应用部署指令；

确定部署的至少一个应用分别对应的容器，并确定在各容器部署应用需执行的任务及任务逻辑执行顺序；

启用主协程按所述任务逻辑执行顺序执行对应的任务，包括：

对所述部署的至少一个应用分别对应的容器，分别启用对应的主协程按在该容器部署应用的任务逻辑执行顺序执行对应的任务。

可选的，上述挂载任务执行模块503用于将所述挂载任务交由所述新协程执行后，还包括：

通过所述新协程，在本地文件目录/远程文件目录中进行遍历查找；

待查找到需挂载文件的本地文件目录/远程文件目录时，将查找到的本地文件目录/远程文件目录挂载到容器中。

实施例3

在介绍了本发明示例性实施方式的微服务配置方法和装置之后，接下来，介绍根据本发明的另一示例性实施方式的设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本发明的设备可以至少包括至少一个处理器、以及至少一个存储器。其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行本说明书上述描述的根据本发明各种示例性实施方式的微服务配置方法中的步骤。

下面参照图6来描述根据本发明的这种实施方式的设备600。图6显示的设备600仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图6所示，设备600以通用设备的形式表现。设备600的组件可以包括但不限于：上述至少一个处理器601、上述至少一个存储器602、连接不同系统组件(包括存储器602和处理器601)的总线603，其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行以下步骤：

接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

启用主协程按所述任务逻辑执行顺序执行对应的任务；

确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

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

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

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

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

可选的，上述处理器还用于：

周期性根据新协程执行挂载任务的结果，确定将各本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载状态，所述挂载状态包括挂载成功、挂载失败、正在执行挂载；

将确定的挂载状态反馈给主服务器，以使主服务器根据所述确定的挂载状态调整下一次下发的挂载任务，并在到达下一任务下发时将调整后的挂载任务通过应用部署指令再次下发。

可选的，上述处理器用于在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务，包括：

确定在计时超过设定时长前，新协程完成挂载任务时，触发主协程执行所述挂载任务的下一个任务；或者

确定新协程未完成挂载任务且计时达到设定时长时，触发主协程执行所述挂载任务的下一个任务；

其中，确定所述新协程完成挂载任务后，关闭所述新协程。

可选的，上述处理器用于确定需执行所述挂载任务时，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时，包括：

确定需执行所述挂载任务时，判断是否当前已经启用新协程执行所述应用对应的挂载任务；

确定当前未启用新协程执行所述应用对应的挂载任务，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时。

可选的，上述处理器用于判断是否当前已经启用新协程执行所述应用对应的挂载任务之后，还包括：

确定当前已启用新协程执行所述应用对应的挂载任务，开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

可选的，上述处理器用于接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署新应用的应用部署指令，创建新容器并确定在所述新容器中部署新应用需执行的任务及任务逻辑执行顺序；或者

接收主服务器下发的对应用更新的应用部署指令，确定所述应用所在的原容器，并确定对所述原容器部署的应用进行更新需执行的任务及任务逻辑执行顺序。

可选的，上述处理器用于接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署至少一个应用的应用部署指令；

确定部署的至少一个应用分别对应的容器，并确定在各容器部署应用需执行的任务及任务逻辑执行顺序；

启用主协程按所述任务逻辑执行顺序执行对应的任务，包括：

对所述部署的至少一个应用分别对应的容器，分别启用对应的主协程按在该容器部署应用的任务逻辑执行顺序执行对应的任务。

可选的，上述处理器用于将所述挂载任务交由所述新协程执行后，还包括：

通过所述新协程，在本地文件目录/远程文件目录中进行遍历查找；

待查找到需挂载文件的本地文件目录/远程文件目录时，将查找到的本地文件目录/远程文件目录挂载到容器中。

在一些可能的实施方式中，本发明提供的一种微服务配置方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本发明各种示例性实施方式的一种微服务配置方法中的步骤。

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

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

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

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

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

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

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和方框图来描述的。应理解可由计算机程序指令实现流程图和方框图中的每一流程和/或方框、以及流程图和方框图中的流程和方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种微服务配置方法，其特征在于，该方法包括：

接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

启用主协程按所述任务逻辑执行顺序执行对应的任务；

确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

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

周期性根据新协程执行挂载任务的结果，确定将各本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载状态，所述挂载状态包括挂载成功、挂载失败、正在执行挂载；

将确定的挂载状态反馈给主服务器，以使主服务器根据所述确定的挂载状态调整下一次下发的挂载任务，并在到达下一任务下发时将调整后的挂载任务通过应用部署指令再次下发。

3.根据权利要求1所述的方法，其特征在于，在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务，包括：

确定在计时超过设定时长前，新协程完成挂载任务时，触发主协程执行所述挂载任务的下一个任务；或者

确定新协程未完成挂载任务且计时达到设定时长时，触发主协程执行所述挂载任务的下一个任务；

其中，确定所述新协程完成挂载任务后，关闭所述新协程。

4.根据权利要求1所述的方法，其特征在于，确定需执行所述挂载任务时，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时，包括：

确定需执行所述挂载任务时，判断是否当前已经启用新协程执行所述应用对应的挂载任务；

确定当前未启用新协程执行所述应用对应的挂载任务，触发启用新协程，将所述挂载任务交由所述新协程执行后开始计时。

5.根据权利要求4所述的方法，其特征在于，判断是否当前已经启用新协程执行所述应用对应的挂载任务之后，还包括：

确定当前已启用新协程执行所述应用对应的挂载任务，开始计时；

在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

6.根据权利要求1所述的方法，其特征在于，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署新应用的应用部署指令，创建新容器并确定在所述新容器中部署新应用需执行的任务及任务逻辑执行顺序；或者

接收主服务器下发的对应用更新的应用部署指令，确定所述应用所在的原容器，并确定对所述原容器部署的应用进行更新需执行的任务及任务逻辑执行顺序。

7.根据权利要求1所述的方法，其特征在于，接收主服务器下发的应用部署指令，包括：

接收主服务器下发的部署至少一个应用的应用部署指令；

确定部署的至少一个应用分别对应的容器，并确定在各容器部署应用需执行的任务及任务逻辑执行顺序；

启用主协程按所述任务逻辑执行顺序执行对应的任务，包括：

对所述部署的至少一个应用分别对应的容器，分别启用对应的主协程按在该容器部署应用的任务逻辑执行顺序执行对应的任务。

8.根据权利要求1所述的方法，其特征在于，将所述挂载任务交由所述新协程执行后，还包括：

通过所述新协程，在本地文件目录/远程文件目录中进行遍历查找；

待查找到需挂载文件的本地文件目录/远程文件目录时，将查找到的本地文件目录/远程文件目录挂载到容器中。

9.一种微服务配置装置，其特征在于，该装置包括：

指令接收模块，用于接收主服务器下发的应用部署指令，所述应用部署指令包括在节点服务器中的容器部署应用需执行的任务及任务逻辑执行顺序，所述任务包括将本地文件目录挂载到容器或将远程文件目录挂载到容器的挂载任务；

主协程启动模块，用于启用主协程按所述任务逻辑执行顺序执行对应的任务；

挂载任务执行模块，用于确定需执行所述挂载任务时，触发启用新协程，并将所述挂载任务交由所述新协程执行后开始计时；

任务执行模块，用于在计时超过设定时长前，触发主协程执行所述挂载任务的下一个任务。

10.一种微服务配置设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1-8中任一项所述的步骤。

Images