一种在云虚拟机上动态优化容器部署的优化算法

摘要：微服务架构的优势在于它提供了更高的灵活性和可扩展性，允许独立部署、快速迭代和故障隔离，从而加速了开发过程并提高了系统的可靠性。为了降低企业使用云服务资源的成本，文章提出了一种容器资源优化调度算法，旨在有效地将微服务请求路由到容器中，并将容器运行在合理的云虚拟机中，从而减少活跃云虚拟机的数量。仿真实验结果表明，在每分钟21 000个请求量时，仅需开启44台4核8G内存的虚拟机，且容器的资源利用率达到了96%；通过与Spread算法相比，该算法所使用的容器数量可节约11.1%～15.36%，并将活跃虚拟机的数量减少10.12%～15.25%；与First-Fit和Best-Fit算法相比，容器数量可节约6.91%～10.41%，活跃虚拟机的数量减少的幅度在6.14%～8.91%之间。

关键词：云计算；微服务；容器；优化算法

中图分类号：TP301.6 文献标识码：A

文章编号：1009-3044（2024）27-0048-04

0 引言

微服务架构通过将企业应用分解为独立的小型模块，每个模块由一个微服务来完成特定的任务，并通过SOAP协议进行服务间的通信。这种架构允许开发团队分成多个小组，各自独立地开发不同模块的业务功能，从而提高了代码的复用性和维护的便捷性。鉴于需求的不断变化，微服务架构的应用程序必须具备良好的可扩展性。

面对微服务的分布式特性和需求的不确定性，企业需要一种成本效益高的、可伸缩的资源配置算法来确保部署和执行的效率。云计算为其提供了解决方案，云计算的优势包括弹性扩展、成本效益、高可用性和易于管理。例如，阿里云提供了按需扩展的云资源，企业可以根据需求快速调整计算能力，无需投资昂贵的硬件，这在电子商务网站应对高峰销售季节时尤为有用。依托云计算技术，企业可根据实际资源需求，动态地开启或关闭按量付费实例，并将微服务打包成容器，将其运行在这些活跃的按量付费实例上，以此来满足客户端的动态资源需求。

然而，企业普遍关注的一个重要问题是如何在按需付费的云实例上，根据微服务的请求量动态调整实例数量，以及在每个活跃的实例上动态调整部署的微服务容器。针对上述问题，本文提出一种新的资源调度算法，并在阿里云ECS 按量收费的实例中使用Docker容器部署微服务来进行验证，实验结果证明了该算法的有效性。

1 相关研究

微服务架构是一种现代软件设计模式，它将大型应用拆分为多个独立的小服务，每个服务负责单一功能，实现服务的解耦和简化系统复杂度。Hasselbring[1]指出微服务架构倡导去中心化的组织结构，允许服务独立测试、部署和运行，确保了变更的局部性，从而提高了系统的可靠性、可用性和可维护性。Zdun等人[2]指出微服务架构在提升系统性能和加快DevOps开发周期方面，确实优于单体架构。因此，微服务架构可根据业务需求进行灵活扩展，增强系统的可扩展性。

微服务任务调度是一种自动化机制，用于管理和协调多个微服务之间任务的执行顺序和资源分配，以优化服务性能和响应时间。近年来也吸引了不少学者的探索，LI等人[3]提出了一种创新的分布式微服务工作流引擎，但该分布式引擎将微服务部署在虚拟机上，并不能动态调度容器。FAZIO等人[4]对微服务调度和资源管理中的一些关键问题进行了梳理，包括如何利用Docker Swarm、Kubernetes等工具将微服务部署到容器中，并在云环境中有效管理这些容器，但该方法并未考虑虚拟机的资源利用率。GERLACH等人[5]提出的Skyport系统是一个多云环境下的容器调度系统，可动态调度容器的部署，但该系统假定虚拟机的资源无限。因此，在优化微服务任务调度时，同时关注虚拟机和容器资源的利用率，有助于企业降低虚拟机成本，提高资源效率。为解决这个问题，本文提出了一种云虚拟机上动态优化容器部署的优化算法。

2 数学建模

2.1 系统模型

本文系统的设计和建模基于以下假设：1） 容器能够在不同虚拟机之间迁移，实现在最少数量的虚拟机中进行优化整合；2） 微服务所使用的容器镜像可部署在任一虚拟机上，每种容器镜像至少需要有一个容器实例；3） 允许有多个容器从同一个容器镜像中被实例化出来，提供相同的微服务。

首先，给定一组微服务请求S = { s1，s2，...，sm }， 每个微服务请求都会被路由到一个已部署的容器云环境。给定一组容器镜像CI = { ci1，ci2，...，cix }，每个容器镜像提供一种容器服务，每个容器必须绑定一种容器镜像；因此，微服务容器C = { c1，c2，...，cn }可以通过容器镜像来实现实例化。所有的容器都部署在虚拟机上，V = { v1，v2，...， vq }。

系统根据请求量动态调整容器实例，保持资源利用率在合理范围。容器和虚拟机的扩展或缩减决策基于资源需求和使用情况。本文不会仅因资源利用率短期下降就关闭容器或虚拟机，而是在资源持续低利用后才会考虑调整。其中，容器和虚拟机的资源利用率的计算方法如下：

容器的资源利用率：用一个矩阵Xi，j，t 来表示请求与容器之间的分配关系，这个矩阵表示在特定时刻t，请求si 是否被分配到了容器cj。那么，容器cj 在时刻t的资源利用率的计算公式如下：

式中，服务请求si 需要的计算能力以每秒百万指令（MIPS） 来衡量，记为mipssi。相应地，容器cj 的计算能力，即其MIPS容量，表示为mipscj。且Xi，j，t定义为：

虚拟机的资源利用率：同样的，通过矩阵Yj，k，t 来展示容器与虚拟机之间的分配关系。在此矩阵中，元素Yj，k，t 代表在特定时刻t，容器cj 是否被分配到了虚拟机vk。在特定时间点t，虚拟机vk 的资源利用率的计算方法如下：

式中，虚拟机vk 的计算能力也是通过其每秒百万指令（MIPS） 的容量来衡量的。而那些被分配给容器的服务请求，会被记录在该容器的请求服务历史表中，以便管理和追踪。此外，Yj，k，t 的定义公式为：

2.2 问题建模

问题模型的目标函数是在满足微服务请求的前提下最小化云虚拟机资源的开启量，并最大化每个虚拟机的容器资源利用率；约束条件为：1） 每个虚拟机有内存的限制，只能容纳特定数量的容器；2） 每个容器镜像能够响应的并发请求数量不同。该模型可以在最小化按需收费的虚拟机数量（例如阿里云的ECS） 的同时，最大化Docker容器的利用率。

给定一组微服务请求sm ∈ S （m = 1，2，...），一组容器镜像 cix ∈ CI （x = 1，2，...）和一组虚拟机vi ∈ V （i =1，2，...）；需要求出一个调度计划 f：si → cj，其中请求si由容器cj 来提供服务；求出一个容器分配计划g：cj → vk，其中容器cj部署在虚拟机vk 上。

3 优化算法

本文提出了一种全新的优化算法，该算法专门用于处理独立的微服务请求，目的是将这些请求合理分配到一组容器C 中，以便在相应的一组虚拟机V 上顺利运行。每个容器仅支持运行一种特定类型的微服务。因此，可以根据服务请求S 的属性，将它们进行分类并分配到合适的容器。

本文提出的优化算法分为两个阶段：1） 服务请求的优化分配算法；2） 容器和虚拟机的资源池管理算法。以下是具体的实施步骤。

3.1 服务请求的优化分配算法

本文提出了一个服务请求的优化分配算法（见算法1） ，该算法的基本逻辑为：在请求的调度周期内，资源分配者会接收到一系列的服务请求，并将这些请求定向到相应的容器。在进行服务请求的分配之前，会先将容器按照资源利用率的高低进行降序排列。目的是确保资源分配者能够优先将服务请求分配给那些资源利用率最高，但尚未达到过载状态的容器。基于这种算法，即在服务需求下降时释放利用率较低的容器，这样可以有效地减少容器的部署。注意，企业的成本不直接与容器的部署数量挂钩，而是与虚拟机的部署数量紧密相关。

为了使容器更高效地分布在较少的虚拟机中，本文提出了一种算法：根据容器利用率与虚拟机利用率的乘积（uc j，t∙uvk，t ），对容器进行降序排序。这一排序过程体现在算法1的第3行中，目的是优化资源分配，确保容器能够被合理地集中管理。

在算法1 中的第14～16行，选择容器cj 来处理服务请求si 的条件是：容器的利用率uc jt 必须低于预设的利用率上限阈值θch，并且si 能够在该容器中成功部署，即mipssi + θcj ⋅ mipscj ≤ mipscj ，其中mips（百万指令每秒的机器周期）。如果当前没有容器能够满足服务请求的部署条件，就需要在合适的虚拟机上，利用容器镜像cia 来创建一个新的容器，以确保服务请求能够得到处理。容器可以在虚拟机上部署的条件是该虚拟机拥有充足的资源，即虚拟机vk 在特定时间点t 的资源可用性的定义为：

式中，θvh为虚拟机利用率的上限阈值。

为了确保容器之间不会发生资源争抢，本文假设：无论容器的实际使用情况如何，其所需的资源都将被完全保留。基于这个假设，虚拟机vk 资源可用性的定义中的uc j，t替换成1，具体表示如下：

这里，用函数isDeployableVM （cj， vk ）用于检查虚拟机vk 是否具备满足新容器cj 所需资源，当mipscj ≤ Rvk，t时，即表示vk 的资源足够，该函数将返回true。

3.2 容器与虚拟机的资源池管理算法

本文提出了容器和虚拟机的资源池管理算法（参见算法2） ，该算法的基本逻辑是：通过对容器和虚拟机按资源利用率降序排列，本文能够在扩展时，将微服务分配给列表中利用率最高的容器，而让列表末尾的容器尽量保持低利用率。这种算法可确保列表末尾的虚拟机在不被需要时能够进入空闲状态。如果这些虚拟机在列表尾部仍然没有被分配任务，它们就可能被考虑为释放候选。此外，如果列表尾部的容器是空闲的，它们也可能会被列入释放的队列。

在算法1结束后，算法2会对各种服务类型（即不同容器镜像类型）的容器实例进行健康状态的检查，并对其资源使用情况进行二次分析；这些分析结果将作为扩容或缩容的依据。

假定在某时间点t，容器镜像类型cia，其容器实例ucia，t的资源利用率可以通过如下的计算方法得出：

式中，uc j，t 指的是容器cj 在时间t 的资源利用率，而Ca 表示由容器镜像cia 生成的所有容器的集合。如果在t' 至t 某个时间段，容器的平均资源利用率超过了预设的上限阈值θch，那么就需要对Ca 进行扩容，以提升其处理能力。因此，在某个时间段的平均资源利用率计算方式如下：

算法2 的11～14行的计算逻辑是，如果平均资源利用率---ucia，t 大于θch 则---ucia，t – θch 个容器将被实例化；当在虚拟机vk 上创建新容器时，必须确保该容器的新增资源不会使得虚拟机的总利用率超出设定的阈值θvh，可以通过如下公式来检验：

当容器无法适配现有的任何虚拟机时，则须创建一个新的虚拟机来为该容器提供所需的资源分配。为确保容器能够迅速启动，避免因虚拟机实例化过程（通常需要1至2分钟）造成的服务中断或延误，会在每个调度周期结束前对虚拟机进行预扩容；这样，就能维护一个随时可用的虚拟机池，确保容器可以被立即部署。

算法2 的18～20行的计算逻辑是，当容器uci 在某时刻t 的平均资源利用率低于预设的下限阈值θcl 时，就需要对这些容器进行释放；释放的规则是，选取前θcl - ---ucia，t ⋅ |Ca| 个容器进行关闭。同样，当虚拟机的平均资源利用率-uvt低于设定的下限阈值θvl 时，则会释放相应的虚拟机；释放的规则是，选取前θvl - -uvt⋅ |V| 个虚拟机。

4 实验结果

4.1 仿真环境搭建

仿真实验环境是基于阿里云的按量收费的云服务器实例（ECS） 。本文选用了ecs.c7.xlarge这种计算密集型的虚拟机类型来部署容器。此类虚拟机配备了4个虚拟CPU（vCPU） 和8 GiB的内存，并且能够提供最高12.5 Gbps的内网网络带宽。在实验中，每个容器最高可以提供100 MIPS的处理能力。因此，如果容器以最大性能运行，一台虚拟机理论上可以同时容纳4个这样的容器，这是基于虚拟机的最大利用率被设定为90%。

为了生成仿真数据，本文估算了在容器（满负荷运行）中处理一个微服务请求的平均耗时为510毫秒，这个执行时间可能会在0.08秒到1.8秒之间波动。据此计算，平均每分钟大约能够处理118个微服务请求。相应地，一台虚拟机平均每分钟能够处理的微服务请求数量为472个（即118个乘以4） 。在实验时，每分钟微服务请求的数量范围为3 000到21 000。

4.2 结果分析

Zhang等人[6]提出了三种公认的标准容器分配算法：Spread、First-Fit 和Best-Fit。本文将通过与这些算法的比较来验证所提出算法的有效性。

如图1与图2所示，实验结果显示，本文所提出的算法能够显著降低所需的容器总数，并能保持较高的容器利用率。从图1可见，在Spread算法下，运行微服务所需的容器数量稍显偏高，First-Fit和Best-Fit这两种算法的表现则较为接近。相较于Spread算法，本文的算法所使用的容器数量可节约11.1%～15.36%，与First-Fit和Best-Fit算法相比，容器数量可节约6.91% ～10.41%。此外，本文提出的算法仅需开启44台4核8G内存的虚拟机，且容器的资源利用率达到了96%。这表明本文的算法在资源优化方面具有明显优势。

图3展示了活跃虚拟机的数量，随着部署容器数量的减少，活跃虚拟机的数量也随之降低。具体来说，与Spread算法相比，本文的算法能够将活跃虚拟机的数量减少10.12%～15.25%；与First-Fit 和Best-Fit算法相比，减少的幅度在6.14%～8.91%之间。

5 结论

本文提出了一种新的云虚拟机上动态调度容器资源算法，旨在将微服务请求有效地分配至容器化的云计算环境中，并实现容器与底层虚拟机的自动伸缩。实验显示，通过与Spread、First-Fit和Best-Fit算法的性能对比，本文提出的算法显著减少了阿里云的云虚拟机数量，即可为企业节约云计算虚拟机使用成本。在未来的工作中，将重点研究云虚拟机所占用物理机的分配调度，从而减少物理机的开启数量，以达到节能减排的目标。

参考文献：

[1] HASSELBRING W.Microservices for scalability：keynote talkabstract[C]//Proceedings of the 7th ACM/SPEC on InternationalConference on Performance Engineering.Delft The Netherlands.ACM，2016：133-134.

[2] ZDUN U，QUEVAL P J，SIMHANDL G，et al.Microservice secu⁃rity metrics for secure communication，identity management，andobservability[J]. ACM Transactions on Software Engineeringand Methodology，2023，32（1）：1-34.

[3] LI X，ZHOU J S，WEI X，et al.Topology-aware scheduling frame⁃work for microservice applications in cloud[J].IEEE Transac⁃tions on Parallel and Distributed Systems， 2023， 34（5）： 1635-1649.

[4] FAZIO M，CELESTI A，RANJAN R，et al.Open issues in schedul⁃ing microservices in the cloud[J].IEEE Cloud Computing，2016，3（5）：81-88.

[5] GERLACH W，TANG W，WILKE A，et al.Container orchestra⁃tion for scientific workflows[C]//2015 IEEE International Con⁃ference on Cloud Engineering. March 9-13， 2015， Tempe， AZ，USA.IEEE，2015：377-378.

[6] ZHANG R，ZHONG A M，DONG B，et al.Container-VM-PM ar⁃chitecture：a novel architecture for docker container placement[M]//Lecture Notes in Computer Science.Cham：Springer Inter⁃national Publishing，2018：128-140.

【通联编辑：谢媛媛】