CN113382077A - 微服务调度方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种微服务调度方法、装置、计算机设备和存储介质。所述方法包括：获取容器管理系统的节点状态目录，所述节点状态目录包括所述容器管理系统中各节点的可用运行资源；获取待调度微服务正常运行所需的目标运行资源；根据所述目标运行资源和所述节点状态目录，从所述容器管理系统中的各节点中确定目标节点，并将所述待调度微服务部署至目标节点运行。本申请在进行微服务调度时，结合待调度微服务正常运行所需的运行资源和各节点的可用运行资源两个影响因素，确定目标节点。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

Description

微服务调度方法、装置、计算机设备和存储介质

技术领域

本申请涉及微服务调度技术领域，特别是涉及一种微服务调度方法、装置、计算机设备和存储介质。

背景技术

随着电网监控技术的不断发展，传统的整体式架构在某些方面已经不能很好地满足需求，基于此，微服务架构的系统应用而生。

微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，每个微服务仅关注于完成一个业务，多个微服务共同作用，可以实现一个应用的正常运行。其中，容器服务编排程序(Kubernetes，K8s)系统是基于容器的集群管理平台，用于管理云平台中多个主机上容器化的应用，微服务作为应用中一个小的业务，可以依托于K8s系统中各个节点的容器进行部署和运行。

然而，在K8s系统中，当一节点同时涌入大量微服务的容器时，可能使该节点出现拥塞的状态，甚至会导致节点死机，节点容器承载的微服务不可用。

发明内容

基于此，有必要针对上述技术问题，提供一种能够有效调度微服务，使各个节点负载分布均衡的微服务调度方法、装置、计算机设备和存储介质。

第一方面，提供了一种微服务调度方法，该方法包括：

获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；

获取待调度微服务正常运行所需的目标运行资源；

根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。

在其中一个实施例中，获取容器管理系统的节点状态目录，包括：

获取容器管理系统中各节点的节点运行信息；

根据节点运行信息，确定各节点的可用运行资源；

根据预设规范对各节点的可用运行资源进行整理，生成节点状态目录。

在其中一个实施例中，获取容器管理系统中各节点的节点运行信息，包括：

向各节点发送状态上报指令，状态上报指令用于指示各节点上报节点运行信息；

接收各节点上报的节点运行信息。

在其中一个实施例中，根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行，包括：

根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点；

从至少一个候选节点中确定目标节点，并将待调度微服务部署至目标节点运行。

在其中一个实施例中，节点运行信息还包括节点链路，节点链路用于指示待调度微服务所在节点与各节点之间的转移路径；

则从至少一个候选节点确定目标节点，包括：

获取待调度微服务所在节点与各候选节点之间的转移路径；

将转移路径满足预设条件的候选节点确定为目标节点。

在其中一个实施例中，根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点，包括：

根据容器管理系统中各节点的可用运行资源和目标运行资源，将可用运行资源大于目标运行资源的节点确定为候选节点。

在其中一个实施例中，节点运行信息包括：CPU占用率和内存占用率，则可用运行资源包括可用CPU资源和可用内存资源。

第二方面，提供了一种微服务调度装置，该装置包括：

第一获取模块，用于获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；

第二获取模块，用于获取待调度微服务正常运行所需的目标运行资源；

调度模块，用于根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。

第三方面，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述第一方面中任一微服务调度方法的步骤。

第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面中任一微服务调度方法的步骤。

上述微服务调度方法、装置、计算机设备和存储介质，获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；获取待调度微服务正常运行所需的目标运行资源；根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。在本申请中，为避免待调度微服务运行资源过大，节点可用资源过少，导致待调度微服务部署在节点上后无法正常运行，节点发生堵塞等情况，在进行微服务调度时，综合考虑待调度微服务正常运行时所需的运行资源和各节点的可用运行资源两个影响因素，以确定目标节点。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

附图说明

图1为本申请一个实施例提供的容器管理系统的结构示意图；

图2为本申请一个实施例提供的微服务调度方法的流程示意图；

图3为本申请另一个实施例提供的微服务调度方法的流程示意图；

图4为本申请另一个实施例提供的微服务调度方法的流程示意图；

图5为本申请另一个实施例提供的微服务调度方法的流程示意图；

图6为本申请另一个实施例提供的微服务调度方法的流程示意图；

图7为本申请一个实施例提供的微服务调度装置的结构框图；

图8为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在对本申请的微服务扩容方法进行解释说明之前，先对本申请涉及的名词、应用环境进行解释说明。

Kubernetes系统：容器服务编排程序(Kubernetes，K8s)提供应用部署、维护和扩展机制等功能，利用K8s系统能方便地管理跨机器运行容器化的应用，K8s系统可以在物理机上运行。

K8s系统按节点功能由控制节点和运行节点组成。

其中，控制节点负责调度和管理整个系统，控制节点包含API Server(服务接口)组件、Scheduler(调度程序)组件和Controller Manager(控制中心)组件。

API Server作为K8s系统的入口，封装了核心对象的增删改查操作，以RESTful(Representational state transfer，表述性状态转移)接口方式提供给外部客户和内部组件调用，它维护的REST对象将持久化到etcd(键值存储系统，主要用于共享配置和服务发现)。Scheduler负责集群的资源调度，为新建的pod分配机器，这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。Controller Manager为K8s系统中各种controller的管理者，是集群内部的控制中心，负责执行各种控制器。通常有两类控制器：端点控制器和副本控制器。端点控制器(Endpoint Controller)定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的；副本控制器(Replication Controller)定期关联replication Controller和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

运行节点可以是一台物理主机，也可以是一台虚拟机(VM)，负责运行业务容器。在每个运行节点上运行用于启动和管理pod的服务——kubelet，并能够被控制节点管理。在运行节点上运行的服务进程包括kubelet、kube-proxy和docker daemon。

Kubelet责管控docker容器，如启动/停止和监控运行状态等，它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收API Server的HTTP请求，汇报pod的运行状态。Kube Proxy负责为pod提供代理，它会定期从etcd获取所有的service，并根据service信息创建代理，当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。docker deamon监听着客户端的请求，并且管理着docker的镜像、容器、网络、磁盘等对象。其中，docker镜像是一个只读模板，可以用来创建docker容器。镜像是一种轻量级的、可执行的独立软件包，用来打包软件运行环境和基于运行环境开发的软件。它包含运行某个软件所需要的所有的内容，包括代码、运行时、库、环境变量、配置文件等。

微服务：一种软件开发技术面向服务的体系结构(SOA)架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。微服务架构是将一个复杂的应用拆分成多个服务模块，且每个模块专注于单一业务功能对外提供服务。由于服务模块可以独立编译部署，同时各服务模块之间可以互相通信，并组合为整体对外提供服务，使得微服务架构具有部署灵活、更新和维护方便等优点，被广泛应用于当前互联网的大量应用和服务中。

本申请提供的微服务调度方法，可以应用于如图1所示的应用环境中。其中，容器管理系统100包括控制中心110和多个节点120，控制中心110通过网络与多个节点120进行通信。于K8s系统架构而言，节点120为K8s系统中的运行节点，可以是虚拟机或者物理服务器；控制中心110为K8s系统中的控制节点，可以是一终端设备。

每个节点120上有一个分配的pod，pod可以被一个容器化的环境看作应用层的“逻辑宿主机”。pod可以包括多个容器，且pod中的多个容器对应的应用通常是紧耦合的，每个容器承载一个微服务，Pod在节点120上被创建、启动或者销毁。

控制中心110负责K8s系统中资源配额管理，确保指定的对象在任何时候都不会超量占用系统资源，避免了由于某些业务进程的设计或实现的缺陷导致整个系统运行紊乱甚至意外宕机，对整个集群的平稳运行和稳定性有非常重要的作用。

每个节点上部署有多个容器，容器中承载有微服务，当一节点同时部署大量容器，承载更多微服务时，可能使该节点出现拥塞的状态，甚至会导致节点死机，节点容器中承载的微服务不可用。

基于此，在本申请实施例中，当需要对任一微服务进行调度时，控制中心110可以根据各节点120上的可用运行资源和待调度微服务正常运行所需的运行资源，确定部署待调度微服务的节点。

在一个实施例中，如图2所示，提供了一种微服务调度方法，以该方法应用于图1中的控制中心110为例进行说明，包括以下步骤：

步骤210：获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源。

其中，容器管理系统包括节点，各节点上部署有微服务，不同的微服务需要占用的节点资源不同。因此，节点上可以部署微服务的数量取决于节点的可用运行资源，节点的可用运行资源包括可用中央处理器(central processing unit，CPU)资源和可用内存资源。

在一种可能的实现方式中，在控制中心连接多个节点时，即存储各节点的运行资源，并建立节点和节点运行资源的对应关系，即得到容器管理系统的节点状态目录。

其中，节点和节点运行资源的对应关系可以以列表或者拓扑结构等方式来表现，本申请对此不做限制。随着节点部署微服务的数目变化情况，控制中心对各节点的运行资源进行更新，以确定各节点的可用运行资源。

步骤220：获取待调度微服务正常运行所需的目标运行资源。

其中，待调度微服务可以是需要部署在容器管理系统中的新增微服务，也可以是容器管理系统中任一节点上的原有微服务，但需要将该微服务调度到其他节点上去运行。

目标运行资源即为待调度微服务正常运行需要占用的CPU资源和内存资源。

步骤230：根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。

可以理解的是，节点的可用运行资源可以保证待调度微服务正常运行时，才可以将待调度微服务部署在该节点上。换言之，若节点的可用运行资源不能保证待调度微服务的正常运行，则不能将待调度微服务部署在该节点上，否则会导致节点出现拥塞的状态，甚至会导致节点死机，还会影响节点容器承载的其他微服务的正常运行。

在一种可能的实现方式中，上述步骤230的实现过程可以为：根据待调度微服务运行所需的CPU资源、内存资源和容器管理系统的节点状态目录，将节点状态目录中可用CPU资源大于待调度微服务运行所需CPU资源，且可用内存资源大于待调度微服务运行所需内存资源的节点确定为目标节点，并将待调度微服务部署至目标节点运行。

在本申请实施例中，获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；获取待调度微服务正常运行所需的目标运行资源；根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。在本申请中，为避免待调度微服务运行资源过大，节点可用资源过少，导致待调度微服务部署在节点上后无法正常运行，节点发生堵塞等情况，在进行微服务调度时，综合考虑待调度微服务正常运行时所需的运行资源和各节点的可用运行资源两个影响因素，以确定目标节点。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

在一个实施例中，如图3所示，获取容器管理系统的节点状态目录(上述步骤210)的实现过程，包括如下步骤：

步骤310：获取容器管理系统中各节点的节点运行信息。

在一种可能的实现方式中，节点运行信息包括CPU占用率和内存占用率，在另一种的实现方式中，节点运行信息包括已占用CPU资源和已占用内存资源，上述两种节点运行信息均可反映节点中不可用资源的占比。

则上述步骤310的实现过程可以为：控制中心向各节点发送状态上报指令，状态上报指令用于指示各节点上报节点运行信息；控制中心接收各节点上报的节点运行信息。

作为一个示例，状态上报信息请求端采集K8s系统中的各节点的IP地址信息，然后基于IP地址信息，向K8s系统中的各节点发送状态上报指令，K8s系统中的各节点接收到状态上报指令后，就会向状态上报信息请求端发送响应状态上报指令的节点运行信息，从而状态上报信息请求端可以获取K8s系统中的各节点的节点运行信息。

需要说明的是，节点的IP地址信息可以为K8s系统中节点的物理IP地址或者节点的虚拟IP地址，本申请对此不做限制。

可以理解的是，上述状态上报信息请求端可以为K8s系统中的控制节点(即本申请图1示出的容器管理系统100中的控制中心110)，也可以是K8s系统外部的控制终端，本申请对此亦不做限制。

步骤320：根据节点运行信息，确定各节点的可用运行资源。

其中，节点的可用运行资源包括可用CPU资源和可用内存资源。

在一种可能的实现方式中，控制中心110中与各个节点建立通信时，即存储各节点的总的运行资源。如此，当接收到节点上报的节点运行信息后，即可根据该节点的总运行资源和节点上报的资源占用率/已占用资源，确定该节点的可用运行资源。

作为一个示例，对任一节点而言，其可用CPU资源确定过程为：

可用CPU资源＝总CPU资源-总CPU资源×CPU占用率；

可用CPU资源＝总CPU资源-已占用CPU资源。

同理，对任一节点而言，其可用内存资源确定过程为：

可用内存资源＝总内存资源-总内存资源×内存占用率；

可用内存资源＝总内存资源-已占用内存资源。

步骤330：根据预设规范对各节点的可用运行资源进行整理，生成节点状态目录。

其中，预设规范可以包括但不限于以下几种：

(1)可用运行资源从大到小的顺序；

(2)可用运行资源从小到大的顺序；

(3)可用运行资源对应的节点和控制中心建立连接的先后顺序。

节点状态目录包括节点信息和节点的可用运行资源，节点信息可以包括节点名称、节点IP地址、节点标识、节点部署容器等信息，本申请对此不做限制。

在本申请实施例中，通过节点上报的形式，获取各节点的可用运行资源，将所有节点的可用运行资源按照预设规范进行整理，得到节点状态目录。如此，通过节点状态目录，即可清楚明了的获知容器管理系统中各节点的可用资源。

基于上述任一实施例，在一种可能的实现方式中，参见图4。若待调度微服务为新增微服务，则根据目标运行资源和节点状态目录，将待调度微服务部署至目标节点运行(上述步骤230)的实现过程，包括如下步骤：

步骤410：根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点。

其中，节点的可用运行资源包括可用CPU资源和可用内存资源，待调度微服务的目标运行资源包括目标CPU资源和目标内存资源。

在一种可能的实现方式中，步骤410的实现过程为：根据容器管理系统中各节点的可用运行资源和目标运行资源，将可用运行资源大于目标运行资源的节点确定为候选节点。

作为一个示例，通过节点状态目录查看每一个节点的可用CPU资源和可用内存资源，将可用CPU资源大于目标CPU资源，且可用内存资源大于目标内存资源的节点确定为候选节点，得到至少一个候选节点。

步骤420：从至少一个候选节点中确定目标节点，并将待调度微服务部署至目标节点运行。

当候选节点为一个时，将该候选节点作为目标节点；当候选节点为两个及以上时，从两个及以上候选节点中选择一个节点作为目标节点。

作为一个示例，从两个及以上候选节点中选择目标节点的过程可以为：将节点的可用运行资源和目标运行资源差值最大的一个候选节点作为目标节点；或者，将目标可用CPU资源和目标CPU资源之间差值最大的一个候选节点作为目标节点；或者，将可用内存资源和目标内存资源之间差值最大的一个候选节点作为目标节点；或者，随意指定一个候选节点作为目标节点，本申请对此不做限制。

在确定目标节点后，在目标节点上创建运行待调度微服务的容器，以将待调度微服务部署至目标节点运行。

在本申请实施例中，综合考虑待调度微服务正常运行所需的运行资源和各节点的可用运行资源两个影响因素，从节点状态目录中确定一个目标节点，将待调度微服务部署至目标节点运行。如此，实现对待调度微服务进行部署的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

基于上述实施例，在另一种可能的实现过程种，参见图5。若待调度微服务为容器管理系统中任一节点原有微服务，则根据目标运行资源和节点状态目录，将待调度微服务部署至目标节点运行(上述步骤230)的实现过程，包括如下步骤：

步骤510：根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点。

其中，步骤510与上述步骤410相同，具体实现过程参见上述步骤410，在此不再赘述。

步骤520：获取待调度微服务所在节点与各候选节点之间的转移路径。

需要说明的是，控制中心110中在于各个节点建立通信时，即存储各节点微服务部署情况，因此，控制中心在根据各节点上报的节点运行信息生成状态目录时，还可以在节点状态目录中加入各节点与其他节点之间的转移路径。

也即是，容器管理系统的节点状态目录包括：多个节点、各节点的可用运行资源和各节点之间的转移路径。

在一种可能的实现方式中，上述步骤520的实现过程可以为：获取容器管理系统的节点状态目录，根据待调度微服务所在节点，从节点状态目录中查询该节点与其他候选节点之间的转移路径。

步骤530：将转移路径满足预设条件的候选节点确定为目标节点，并将待调度微服务部署至目标节点运行。

其中，预设条件可以是转移路径最短，或者，基于该转移路径调度微服务时耗时最短，本申请对此不做限制。

作为一个示例，从两个及以上候选节点中选择目标节点的过程可以为：将转移路径最短的一条路径所对应的候选节点，作为目标节点。

在确定目标节点后，在目标节点上创建运行待调度微服务的容器，以将待调度微服务部署至目标节点运行。

在本申请实施例中，在根据待调度微服务正常运行所需的运行资源和各节点的可用运行资源，从节点状态目录中确定至少一个候选节点，待调度微服务在候选节点上可以正常运行。进一步地，考虑到微服务调度路径和时间，根据待调度微服务所在节点与各候选节点之间的转移路径，从候选节点中确定一个目标节点，将待调度微服务部署至目标节点运行。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

基于上述实施例，如图6所示，本申请还提供了另一种微服务调度方法，以该方法应用于图1中的控制中心110为例进行说明，包括以下步骤：

步骤610：向各节点发送状态上报指令，状态上报指令用于指示各节点上报节点运行信息；

步骤620：接收各节点上报的节点运行信息；

步骤630：根据节点运行信息，确定各节点的可用运行资源；

步骤640：根据预设规范对各节点的可用运行资源进行整理，生成节点状态目录；

步骤650：获取待调度微服务正常运行所需的目标运行资源；

步骤660：根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点；

步骤670：从至少一个候选节点中确定目标节点，并将待调度微服务部署至目标节点运行。

步骤680：获取待调度微服务所在节点与各候选节点之间的转移路径；

步骤690：将转移路径满足预设条件的候选节点确定为目标节点，并将待调度微服务部署至目标节点运行。

上述步骤的具体实现过程可参见图2-5对应的实施例，在此不再赘述，通过上述微服务调度方法，在进行微服务调度时，综合考虑待调度微服务正常运行所需的运行资源和各节点的可用运行资源两个影响因素，确定目标节点。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

应该理解的是，虽然图2-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图7所示，提供了一种微服务调度装置，该装置700包括：第一获取模块710、第二获取模块720和调度模块730，其中：

第一获取模块710，用于获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；

第二获取模块720，用于获取待调度微服务正常运行所需的目标运行资源；

调度模块730，用于根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。

在其中一个实施例中，第一获取模块710，包括：

第一获取单元，用于获取容器管理系统中各节点的节点运行信息；

第一确定单元，用于根据节点运行信息，确定各节点的可用运行资源；

目录生成单元，用于根据预设规范对各节点的可用运行资源进行整理，生成节点状态目录。

在其中一个实施例中，第一获取单元，还用于：

向各节点发送状态上报指令，状态上报指令用于指示各节点上报节点运行信息；

接收各节点上报的节点运行信息。

在其中一个实施例中，调度模块730，包括：

第二获取单元，用于根据容器管理系统中各节点的可用运行资源和目标运行资源，从节点状态目录中获取至少一个候选节点；

第二确定单元，用于从至少一个候选节点中确定目标节点，并将待调度微服务部署至目标节点运行。

在其中一个实施例中，节点运行信息还包括节点链路，节点链路用于指示待调度微服务所在节点与各节点之间的转移路径；

则第二确定单元，还用于：

获取待调度微服务所在节点与各候选节点之间的转移路径；

将转移路径满足预设条件的候选节点确定为目标节点。

在其中一个实施例中，第二获取单元，还用于：

根据容器管理系统中各节点的可用运行资源和目标运行资源，将可用运行资源大于目标运行资源的节点确定为候选节点。

在其中一个实施例中，节点运行信息包括：CPU占用率和内存占用率，则可用运行资源包括可用CPU资源和可用内存资源。

在本申请实施例种，微服务调度装置600获取容器管理系统的节点状态目录，节点状态目录包括容器管理系统中各节点的可用运行资源；获取待调度微服务正常运行所需的目标运行资源；根据目标运行资源和节点状态目录，从容器管理系统中的各节点中确定目标节点，并将待调度微服务部署至目标节点运行。在本申请中，为避免待调度微服务运行资源过大，节点可用资源过少，导致待调度微服务部署在节点上后无法正常运行，节点发生堵塞的状态的情况，在进行微服务调度时，综合考虑待调度微服务正常运行所需的运行资源和各节点的可用运行资源两个影响因素，确定目标节点。如此，提高微服务调度效率的同时，保证了容器管理系统中各节点上微服务均衡分布，且各微服务均可正常运行。

关于微服务调度装置的具体限定可以参见上文中对于微服务调度方法的限定，在此不再赘述。上述微服务调度装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种微服务调度方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现本申请实施例示出的任一微服务调度方法的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请实施例示出的任一微服务调度方法的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种微服务调度方法，其特征在于，所述方法包括：

获取容器管理系统的节点状态目录，所述节点状态目录包括所述容器管理系统中各节点的可用运行资源；

获取待调度微服务正常运行所需的目标运行资源；

根据所述目标运行资源和所述节点状态目录，从所述容器管理系统中的各节点中确定目标节点，并将所述待调度微服务部署至所述目标节点运行。

2.根据权利要求1所述的微服务调度方法，其特征在于，所述获取容器管理系统的节点状态目录，包括：

获取所述容器管理系统中各节点的节点运行信息；

根据所述节点运行信息，确定所述各节点的可用运行资源；

根据预设规范对所述各节点的可用运行资源进行整理，生成所述节点状态目录。

3.根据权利要求2所述的微服务调度方法，其特征在于，所述获取所述容器管理系统中各节点的节点运行信息，包括：

向所述各节点发送状态上报指令，所述状态上报指令用于指示所述各节点上报节点运行信息；

接收所述各节点上报的节点运行信息。

4.根据权利要求1-3任一所述的微服务调度方法，其特征在于，所述根据所述目标运行资源和所述节点状态目录，从所述容器管理系统中的各节点中确定目标节点，并将所述待调度微服务部署至目标节点运行，包括：

根据所述容器管理系统中各节点的可用运行资源和所述目标运行资源，从所述节点状态目录中获取至少一个候选节点；

从所述至少一个候选节点中确定所述目标节点，并将所述待调度微服务部署至所述目标节点运行。

5.根据权利要求4所述的微服务调度方法，其特征在于，所述节点运行信息还包括节点链路，所述节点链路用于指示所述待调度微服务所在节点与所述各节点之间的转移路径；

则所述从所述至少一个候选节点确定所述目标节点，包括：

获取所述待调度微服务所在节点与各所述候选节点之间的转移路径；

将转移路径满足预设条件的候选节点确定为所述目标节点。

6.根据权利要求4所述的微服务调度方法，其特征在于，所述根据所述容器管理系统中各节点的可用运行资源和所述目标运行资源，从所述节点状态目录中获取至少一个候选节点，包括：

根据所述容器管理系统中各节点的可用运行资源和所述目标运行资源，将可用运行资源大于所述目标运行资源的节点确定为所述候选节点。

7.根据权利要求1-3任一项所述的微服务调度方法，其特征在于，节点运行信息包括：CPU占用率和内存占用率，则可用运行资源包括可用CPU资源和可用内存资源。

8.一种微服务调度装置，其特征在于，所述装置包括：

第一获取模块，用于获取容器管理系统的节点状态目录，所述节点状态目录包括容器管理系统中各节点的可用运行资源；

第二获取模块，用于获取待调度微服务正常运行所需的目标运行资源；

调度模块，用于根据所述目标运行资源和所述节点状态目录，从所述容器管理系统中的各节点中确定目标节点，并将所述待调度微服务部署至所述目标节点运行。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的微服务调度方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的微服务调度方法的步骤。

Images