CN109408200A - 一种基于资源请求特征的微服务资源管理方法及系统 - Google Patents

Abstract

本发明提供了一种基于资源请求特征的微服务资源管理方法，包括获取微服务的资源请求特征；基于所述资源请求特征对所述微服务进行组合部署；基于所述资源请求特征及所述组合部署对所述微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，在保证服务质量的前提下，有效提高系统资源利用率，降低服务器使用数量。本发明还公开了一种基于资源请求特征的微服务资源管理系统。

Description

一种基于资源请求特征的微服务资源管理方法及系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于资源请求特征的微服务资源管理方法及系统。

背景技术

微服务架构是一项在云中部署应用和服务的新技术。微服务架构下，各服务由于业务需求、开发技术的不同，对系统资源的需求也不同。待部署的微服务，根据业务逻辑的不同、实现方式的不同，在资源占用方面存在很大差异。目前的资源管理机制研究多集中在IAAS层，较少有对微服务架构下PAAS平台层应用的特性进行综合考虑，它们或者局限地考虑了单一资源，或者在实施弹性资源分配方案时没有对应用在资源使用方面的差异加以考虑。因此急需一种PAAS资源弹性管理机制，结合不同类型的微服务对资源的不同需求，在保证服务质量的前提下，尽可能地提高平台资源利用率、降低服务器使用数量。

发明内容

有鉴于此，本发明提供了一种基于资源请求特征的微服务资源管理方法及系统，能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，在保证服务质量的前提下，有效提高系统资源利用率，降低服务器使用数量。

本发明提供了一种基于资源请求特征的微服务资源管理方法，包括：

获取微服务的资源请求特征；

基于所述资源请求特征对所述微服务进行组合部署；

基于所述资源请求特征以及所述组合部署对所述微服务的资源进行弹性伸缩管理。

优选地，所述获取微服务的资源请求特征包括：

将所述微服务使用容器进行封装，并部署在单独的物理机上；

对所述物理机和所述微服务进行监测；

待所述微服务运行状态稳定后，获取所述微服务的所述资源请求特征。

在上述方案中，通过对微服务访问日志的监控，结合服务所在的物理机系统环境的监测记录分析，获取微服务的资源请求特征，从而能建立微服务与系统资源开销的对应关系。

优选地，所述基于所述资源请求特征对所述微服务进行组合部署包括：

基于所述微服务的所述资源请求特征将所述微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，其中，每组所述微服务对资源的使用率成互补关系。

在上述方案中，将多种在资源开销方面有着不同特征的服务组合部署在一起，能充分利用系统资源，提高资源使用效率。

优选地，所述基于所述资源请求特征及所述组合部署对所述微服务的资源进行弹性伸缩管理包括：

基于所述资源请求特征，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配。即根据当前节点中虚拟机的资源使用情况，结合应用请求特征，进行资源分配，若没有满足请求的虚拟机则进行服务扩展，若系统资源长期使用率较低则进行服务收缩。

在上述方案中，通过对微服务的资源进行弹性伸缩管理，能有效平衡系统资源使用，提高资源利用效率，提高部署方案的稳定性，并充分保证服务质量。

一种基于资源请求特征的微服务资源管理系统，包括：

获取模块，用于获取微服务的资源请求特征；

部署模块，用于基于所述资源请求特征对所述微服务进行组合部署；

管理模块，用于基于所述资源请求特征及所述组合部署对所述微服务的资源进行弹性伸缩管理。

优选地，所述获取模块包括：

部署子模块，用于将所述微服务使用容器进行封装，并部署在单独的物理机上；

监测子模块，用于对所述物理机和所述微服务进行监测；

获取子模块，用于待所述微服务运行状态稳定后，获取所述微服务的所述资源请求特征。

优选地，所述部署模块具体用于：

基于所述微服务的所述资源请求特征将所述微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，每组所述微服务对资源的使用率成互补关系。

优选地，所述管理模块具体用于：

基于所述资源请求特征，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配。

从上述技术方案可以看出，本发明提供了一种基于资源请求特征的微服务资源管理方法，首先获取微服务的资源请求特征，然后基于所述资源请求特征对所述微服务进行组合部署，最后基于所述资源请求特征以及所述组合部署对所述微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，在保证服务质量的前提下，有效提高系统资源利用率，降低服务器使用数量。

附图说明

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

图1为本发明公开的一种基于资源请求特征的微服务资源管理方法实施例1的方法流程图；

图2为本发明公开的一种基于资源请求特征的微服务资源管理方法实施例2的方法流程图；

图3为本发明公开的一种基于资源请求特征的微服务资源管理系统实施例1的结构示意图；

图4为本发明公开的一种基于资源请求特征的微服务资源管理系统实施例2的结构示意图；

图5为本发明实施例公开的基于资源请求互补特性的微服务组合部署方式示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，为本发明公开的一种基于资源请求特征的微服务资源管理方法实施例1的方法流程图，所述方法包括：

S101、获取微服务的资源请求特征；

一个新的微服务被部署之前，需要经过一个监测和日志分析的过程，从而获取到微服务的资源请求特征。

S102、基于资源请求特征对微服务进行组合部署；

获取到微服务的资源请求特征之后，需要基于该微服务的资源请求特征对微服务进行部署和资源分配，由此可以均衡利用系统资源，有效提高资源利用率，以达到请求资源互补的目的。服务搭配部署是对微服务的资源进行弹性伸缩管的关键步骤。

S103、基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。

基于上述步骤获取到资源请求特征和对资源进行组合部署，而后需要对微服务的资源进行弹性伸缩管理，根据业务需求和策略，自动调整其弹性计算资源的管理服务，在满足业务需求高峰增长时无缝地增加服务实例，并在业务需求下降时自动减少服务实例以节约成本。

综上所述，在上述实施例中，在对微服务资源进行管理时，首先获取微服务的资源请求特征，然后基于资源请求特征对微服务进行组合部署，最后基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，自动调整其弹性计算资源的管理服务，在满足业务需求高峰增长时无缝地增加服务实例，并在业务需求下降时自动减少服务实例，在保证服务质量的前提下，有效提高系统资源利用率，降低服务器使用数量。

具体地，在上述实施例中，在对微服务进行部署时，单个微服务运行在docker容器上，根据资源请求特征进行微服务的组合部署，例如，对内存需求较高的一组微服务搭配对CPU需求较高的微服务，达到充分利用资源的目的。一组微服务部署在一台物理机上，多个物理机构成一个集群。

如图2所示，为本发明公开的一种基于资源请求特征的微服务资源管理方法实施例2的方法流程图，所述方法包括：

S201、将微服务使用容器进行封装，并部署在单独的物理机上；

为获取到微服务的资源请求特征，首先需要将微服务使用容器进行封装，并将封装后的微服务部署在单独的物理机上。

S202、对物理机和微服务进行监测；

在单独的物理机上部署好微服务之后，对微服务访问日志进行监控，同时对微服务所在的物理机系统环境进行监测。

S203、待微服务运行状态稳定后，获取微服务的资源请求特征；

待部署在单独的物理机上的微服务运行状态稳定后，通过对微服务访问日志的监控，结合服务所在的物理机系统环境的监测记录分析，获取微服务的资源请求特征，建立微服务与系统资源开销的对应关系。

S204、基于资源请求特征对微服务进行组合部署；

基于微服务的资源请求特征将微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，其中，每组所述微服务对资源的使用率成互补关系。将多种在资源开销方面有着不同特征的服务组合部署在一起，充分利用系统资源，提高资源使用效率。

S205、基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。

基于获取到的资源请求特征和上述组合部署方式，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配，即根据当前节点中虚拟机的资源使用情况，结合应用请求特征，进行资源分配，若没有满足请求的虚拟机则进行服务扩展，若系统资源长期使用率较低则进行服务收缩，有效平衡系统资源使用，提高资源利用效率，提高部署方案的稳定性，并充分保证服务质量。

综上所述，在上述实施例中，在对微服务资源进行管理时，首先将微服务使用容器进行封装，并部署在单独的物理机上，然后对物理机和微服务进行监测，待微服务运行状态稳定后，获取微服务的资源请求特征，进而基于资源请求特征对微服务进行组合部署，最后基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，自动调整其弹性计算资源的管理服务，通过对微服务访问日志的监控，结合服务所在的系统环境的监测记录分析，建立微服务与系统资源开销的对应关系，将多种在资源开销方面有着不同特征的服务组合部署在一起，有效平衡系统资源使用，提高资源利用效率，提高部署方案的稳定性，并充分保证服务质量。

具体地，在上述实施例中，通过对微服务的监控和日志分析，能够得出如下表所示的微服务与资源的请求对应表service_resource_table：

微服务	资源请求
		ServiceA	R(A)＝{R1，R2……Rn}
ServiceB	R(B)＝{R1，R2……Rn}
		…	…
ServiceN	R(N)＝{R1，R2……Rn}

上表中，Ri是对该微服务请求时，对资源i的使用情况，其中Ri(1<i<n)，i表示CPU、内存、I/O等资源。

具体地，在上述实施例中，在对微服务进行部署时，单个微服务运行在docker容器上，根据资源请求特征进行微服务的组合部署，例如，对内存需求较高的一组微服务搭配对CPU需求较高的微服务，达到充分利用资源的目的。一组微服务部署在一台物理机上，多个物理机构成一个集群。

如图5所示，为本发明实施例公开的基于资源请求互补特性的微服务组合部署方式示意图。VM(1)和VM(n)是部署在一台物理机或不同物理机上的虚拟机，每个虚拟机上部署一组微服务，每组微服务对资源的使用率成互补关系。其中，微服务A对CPU使用率较高，微服务B对硬盘使用率较高，微服务C对内存使用率较高，这种微服务组合方式保证了应用实例接收到的请求率能处于较为稳定的状态，各自的请求率不会相互影响，从而解决了传统的微服务部署方式对各个应用实例之间的紧耦合性，达到充分利用系统资源的目的。

具体地，在上述实施例中，对微服务资源进行弹性伸缩管理由相应的弹性伸缩机制执行，弹性伸缩机制具体包括微服务动态扩展机制和微服务动态收缩机制。

1、微服务动态扩展机制

由微服务A的资源请求特征获取其执行时的资源消耗情况R(A)＝{R1，R2，R3}，其中R1表示CPU消耗情况、R2表示内存消耗情况、R3表示I/O消耗情况；

列出当前节点中所有虚拟机的资源使用情况，C(i)＝{C1，C2，C3}，其中C1表示虚拟机的CPU消耗情况、C2表示虚拟机的内存消耗情况、C3表示虚拟机的I/O消耗情况；

设置部署扩展微服务的虚拟机的条件，找出可部署扩展微服务的虚拟机，例如满足R1+C1<75％&&R2+C2<75％&&R3+C3<75％，若有多台虚拟机同时满足，则选取R2+C2值最小的那台部署扩展微服务；如果找到可用的虚拟机则部署扩展微服务，否则开启新的虚拟机进行部署。

2、微服务动态收缩机制

设置系统资源利用率阈值，当系统资源在一定时间内利用率低于该阈值，则执行微服务动态收缩机制，例如当系统资源一定时间内利用率低于20％，则执行收缩机制，将微服务关闭。该“一定时间”的具体时长和系统资源利用率阈值可根据具体情况具体设定。

如图3所示，为本发明公开的一种基于资源请求特征的微服务资源管理系统实施例1的结构示意图，所述系统包括：

获取模块301，用于获取微服务的资源请求特征；

一个新的微服务被部署之前，需要经过一个监测和日志分析的过程，从而获取到微服务的资源请求特征。

部署模块302，用于基于资源请求特征对微服务进行组合部署；

获取到微服务的资源请求特征之后，需要基于该微服务的资源请求特征对微服务进行部署和资源分配，由此可以均衡利用系统资源，有效提高资源利用率，以达到请求资源互补的目的。服务搭配部署是对微服务的资源进行弹性伸缩管的关键步骤。

管理模块303，用于基于资源请求特征及组合部署对微服务的资源进行弹性伸缩管理。

基于上述步骤获取到资源请求特征和对资源进行组合部署，而后需要对微服务的资源进行弹性伸缩管理，根据业务需求和策略，自动调整其弹性计算资源的管理服务，在满足业务需求高峰增长时无缝地增加服务实例，并在业务需求下降时自动减少服务实例以节约成本。

综上所述，在上述实施例中，在对微服务资源进行管理时，首先获取微服务的资源请求特征，然后基于资源请求特征对微服务进行组合部署，最后基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，自动调整其弹性计算资源的管理服务，在满足业务需求高峰增长时无缝地增加服务实例，并在业务需求下降时自动减少服务实例，在保证服务质量的前提下，有效提高系统资源利用率，降低服务器使用数量。

具体地，在上述实施例中，在对微服务进行部署时，单个微服务运行在docker容器上，根据资源请求特征进行微服务的组合部署，例如，对内存需求较高的一组微服务搭配对CPU需求较高的微服务，达到充分利用资源的目的。一组微服务部署在一台物理机上，多个物理机构成一个集群。

如图4所示，为本发明公开的一种基于资源请求特征的微服务资源管理系统实施例2的结构示意图，所述系统包括：

部署子模块401，用于将微服务使用容器进行封装，并部署在单独的物理机上；

为获取到微服务的资源请求特征，首先需要将微服务使用容器进行封装，并将封装后的微服务部署在单独的物理机上。

监测子模块402，用于对物理机和微服务进行监测；

在单独的物理机上部署好微服务之后，对微服务访问日志进行监控，同时对微服务所在的物理机系统环境进行监测。

获取子模块403，用于待微服务运行状态稳定后，获取微服务的所述资源请求特征；

待部署在单独的物理机上的微服务运行状态稳定后，通过对微服务访问日志的监控，结合服务所在的物理机系统环境的监测记录分析，获取微服务的资源请求特征，建立微服务与系统资源开销的对应关系。

部署模块404，用于基于资源请求特征对微服务进行组合部署；

基于微服务的资源请求特征将微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，其中，每组所述微服务对资源的使用率成互补关系。将多种在资源开销方面有着不同特征的服务组合部署在一起，充分利用系统资源，提高资源使用效率。

管理模块405，用于基于资源请求特征及组合部署对微服务的资源进行弹性伸缩管理。

基于获取到的资源请求特征和上述组合部署方式，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配，即根据当前节点中虚拟机的资源使用情况，结合应用请求特征，进行资源分配，若没有满足请求的虚拟机则进行服务扩展，若系统资源长期使用率较低则进行服务收缩，有效平衡系统资源使用，提高资源利用效率，提高部署方案的稳定性，并充分保证服务质量。

综上所述，在上述实施例中，在对微服务资源进行管理时，首先将微服务使用容器进行封装，并部署在单独的物理机上，然后对物理机和微服务进行监测，待微服务运行状态稳定后，获取微服务的资源请求特征，进而基于资源请求特征对微服务进行组合部署，最后基于资源请求特征以及组合部署对微服务的资源进行弹性伸缩管理。本发明能够根据应用对资源的不同需求，组合部署微服务，并根据系统资源的使用情况进行弹性伸缩，自动调整其弹性计算资源的管理服务，通过对微服务访问日志的监控，结合服务所在的系统环境的监测记录分析，建立微服务与系统资源开销的对应关系，将多种在资源开销方面有着不同特征的服务组合部署在一起，有效平衡系统资源使用，提高资源利用效率，提高部署方案的稳定性，并充分保证服务质量。

具体地，在上述实施例中，通过对微服务的监控和日志分析，能够得出如下表所示的微服务与资源的请求对应表service_resource_table：

微服务	资源请求
		ServiceA	R(A)＝{R1，R2……Rn}
ServiceB	R(B)＝{R1，R2……Rn}
		…	…
ServiceN	R(N)＝{R1，R2……Rn}

上表中，Ri是对该微服务请求时，对资源i的使用情况，其中Ri(1<i<n)，i表示CPU、内存、I/O等资源。

具体地，在上述实施例中，在对微服务进行部署时，单个微服务运行在docker容器上，根据资源请求特征进行微服务的组合部署，例如，对内存需求较高的一组微服务搭配对CPU需求较高的微服务，达到充分利用资源的目的。一组微服务部署在一台物理机上，多个物理机构成一个集群。

如图5所示，为本发明实施例公开的基于资源请求互补特性的微服务组合部署方式示意图。VM(1)和VM(n)是部署在一台物理机或不同物理机上的虚拟机，每个虚拟机上部署一组微服务，每组微服务对资源的使用率成互补关系。其中，微服务A对CPU使用率较高，微服务B对硬盘使用率较高，微服务C对内存使用率较高，这种微服务组合方式保证了应用实例接收到的请求率能处于较为稳定的状态，各自的请求率不会相互影响，从而解决了传统的微服务部署方式对各个应用实例之间的紧耦合性，达到充分利用系统资源的目的。

具体地，在上述实施例中，对微服务资源进行弹性伸缩管理由相应的弹性伸缩机制执行，弹性伸缩机制具体包括微服务动态扩展机制和微服务动态收缩机制。

1、微服务动态扩展机制

由微服务A的资源请求特征获取其执行时的资源消耗情况R(A)＝{R1，R2，R3}，其中R1表示CPU消耗情况、R2表示内存消耗情况、R3表示I/O消耗情况；

列出当前节点中所有虚拟机的资源使用情况，C(i)＝{C1，C2，C3}，其中C1表示虚拟机的CPU消耗情况、C2表示虚拟机的内存消耗情况、C3表示虚拟机的I/O消耗情况；

设置部署扩展微服务的虚拟机的条件，找出可部署扩展微服务的虚拟机，例如满足R1+C1<75％&&R2+C2<75％&&R3+C3<75％，若有多台虚拟机同时满足，则选取R2+C2值最小的那台部署扩展微服务；如果找到可用的虚拟机则部署扩展微服务，否则开启新的虚拟机进行部署。

2、微服务动态收缩机制

设置系统资源利用率阈值，当系统资源在一定时间内利用率低于该阈值，则执行微服务动态收缩机制，例如当系统资源一定时间内利用率低于20％，则执行收缩机制，将微服务关闭。该“一定时间”的具体时长和系统资源利用率阈值可根据具体情况具体设定。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种基于资源请求特征的微服务资源管理方法，其特征在于，包括：

获取微服务的资源请求特征；

基于所述资源请求特征对所述微服务进行组合部署；

基于所述资源请求特征以及所述组合部署对所述微服务的资源进行弹性伸缩管理。

2.根据权利要求1所述的方法，其特征在于，所述获取微服务的资源请求特征包括：

将所述微服务使用容器进行封装，并部署在单独的物理机上；

对所述物理机和所述微服务进行监测；

待所述微服务运行状态稳定后，获取所述微服务的所述资源请求特征。

3.根据权利要求1所述的方法，其特征在于，所述基于所述资源请求特征对所述微服务进行组合部署包括：

基于所述微服务的所述资源请求特征将所述微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，其中，每组所述微服务对资源的使用率成互补关系。

4.根据权利要求1所述的方法，其特征在于，所述基于所述资源请求特征及所述组合部署对所述微服务的资源进行弹性伸缩管理包括：

基于所述资源请求特征，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配。

5.一种基于资源请求特征的微服务资源管理系统，其特征在于，包括：

获取模块，用于获取微服务的资源请求特征；

部署模块，用于基于所述资源请求特征对所述微服务进行组合部署；

管理模块，用于基于所述资源请求特征及所述组合部署对所述微服务的资源进行弹性伸缩管理。

6.根据权利要求5所述的系统，其特征在于，所述获取模块包括：

部署子模块，用于将所述微服务使用容器进行封装，并部署在单独的物理机上；

监测子模块，用于对所述物理机和所述微服务进行监测；

获取子模块，用于待所述微服务运行状态稳定后，获取所述微服务的所述资源请求特征。

7.根据权利要求5所述的系统，其特征在于，所述部署模块具体用于：

基于所述微服务的所述资源请求特征将所述微服务与其他微服务搭配部署到物理机上，一组微服务部署在一台所述物理机上，每组所述微服务对资源的使用率成互补关系。

8.根据权利要求5所述的系统，其特征在于，所述管理模块具体用于：

基于所述资源请求特征，设置每种资源的权值，计算当前节点的动态综合负载值，并通过策略算法进行请求分配。