一種在云虛擬機(jī)上動(dòng)態(tài)優(yōu)化容器部署的優(yōu)化算法

摘要：微服務(wù)架構(gòu)的優(yōu)勢(shì)在于它提供了更高的靈活性和可擴(kuò)展性，允許獨(dú)立部署、快速迭代和故障隔離，從而加速了開發(fā)過程并提高了系統(tǒng)的可靠性。為了降低企業(yè)使用云服務(wù)資源的成本，文章提出了一種容器資源優(yōu)化調(diào)度算法，旨在有效地將微服務(wù)請(qǐng)求路由到容器中，并將容器運(yùn)行在合理的云虛擬機(jī)中，從而減少活躍云虛擬機(jī)的數(shù)量。仿真實(shí)驗(yàn)結(jié)果表明，在每分鐘21 000個(gè)請(qǐng)求量時(shí)，僅需開啟44臺(tái)4核8G內(nèi)存的虛擬機(jī)，且容器的資源利用率達(dá)到了96%；通過與Spread算法相比，該算法所使用的容器數(shù)量可節(jié)約11.1%～15.36%，并將活躍虛擬機(jī)的數(shù)量減少10.12%～15.25%；與First-Fit和Best-Fit算法相比，容器數(shù)量可節(jié)約6.91%～10.41%，活躍虛擬機(jī)的數(shù)量減少的幅度在6.14%～8.91%之間。

關(guān)鍵詞：云計(jì)算；微服務(wù)；容器；優(yōu)化算法

中圖分類號(hào)：TP301.6 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2024）27-0048-04

0 引言

微服務(wù)架構(gòu)通過將企業(yè)應(yīng)用分解為獨(dú)立的小型模塊，每個(gè)模塊由一個(gè)微服務(wù)來完成特定的任務(wù)，并通過SOAP協(xié)議進(jìn)行服務(wù)間的通信。這種架構(gòu)允許開發(fā)團(tuán)隊(duì)分成多個(gè)小組，各自獨(dú)立地開發(fā)不同模塊的業(yè)務(wù)功能，從而提高了代碼的復(fù)用性和維護(hù)的便捷性。鑒于需求的不斷變化，微服務(wù)架構(gòu)的應(yīng)用程序必須具備良好的可擴(kuò)展性。

面對(duì)微服務(wù)的分布式特性和需求的不確定性，企業(yè)需要一種成本效益高的、可伸縮的資源配置算法來確保部署和執(zhí)行的效率。云計(jì)算為其提供了解決方案，云計(jì)算的優(yōu)勢(shì)包括彈性擴(kuò)展、成本效益、高可用性和易于管理。例如，阿里云提供了按需擴(kuò)展的云資源，企業(yè)可以根據(jù)需求快速調(diào)整計(jì)算能力，無需投資昂貴的硬件，這在電子商務(wù)網(wǎng)站應(yīng)對(duì)高峰銷售季節(jié)時(shí)尤為有用。依托云計(jì)算技術(shù)，企業(yè)可根據(jù)實(shí)際資源需求，動(dòng)態(tài)地開啟或關(guān)閉按量付費(fèi)實(shí)例，并將微服務(wù)打包成容器，將其運(yùn)行在這些活躍的按量付費(fèi)實(shí)例上，以此來滿足客戶端的動(dòng)態(tài)資源需求。

然而，企業(yè)普遍關(guān)注的一個(gè)重要問題是如何在按需付費(fèi)的云實(shí)例上，根據(jù)微服務(wù)的請(qǐng)求量動(dòng)態(tài)調(diào)整實(shí)例數(shù)量，以及在每個(gè)活躍的實(shí)例上動(dòng)態(tài)調(diào)整部署的微服務(wù)容器。針對(duì)上述問題，本文提出一種新的資源調(diào)度算法，并在阿里云ECS 按量收費(fèi)的實(shí)例中使用Docker容器部署微服務(wù)來進(jìn)行驗(yàn)證，實(shí)驗(yàn)結(jié)果證明了該算法的有效性。

1 相關(guān)研究

微服務(wù)架構(gòu)是一種現(xiàn)代軟件設(shè)計(jì)模式，它將大型應(yīng)用拆分為多個(gè)獨(dú)立的小服務(wù)，每個(gè)服務(wù)負(fù)責(zé)單一功能，實(shí)現(xiàn)服務(wù)的解耦和簡(jiǎn)化系統(tǒng)復(fù)雜度。Hasselbring[1]指出微服務(wù)架構(gòu)倡導(dǎo)去中心化的組織結(jié)構(gòu)，允許服務(wù)獨(dú)立測(cè)試、部署和運(yùn)行，確保了變更的局部性，從而提高了系統(tǒng)的可靠性、可用性和可維護(hù)性。Zdun等人[2]指出微服務(wù)架構(gòu)在提升系統(tǒng)性能和加快DevOps開發(fā)周期方面，確實(shí)優(yōu)于單體架構(gòu)。因此，微服務(wù)架構(gòu)可根據(jù)業(yè)務(wù)需求進(jìn)行靈活擴(kuò)展，增強(qiáng)系統(tǒng)的可擴(kuò)展性。

微服務(wù)任務(wù)調(diào)度是一種自動(dòng)化機(jī)制，用于管理和協(xié)調(diào)多個(gè)微服務(wù)之間任務(wù)的執(zhí)行順序和資源分配，以優(yōu)化服務(wù)性能和響應(yīng)時(shí)間。近年來也吸引了不少學(xué)者的探索，LI等人[3]提出了一種創(chuàng)新的分布式微服務(wù)工作流引擎，但該分布式引擎將微服務(wù)部署在虛擬機(jī)上，并不能動(dòng)態(tài)調(diào)度容器。FAZIO等人[4]對(duì)微服務(wù)調(diào)度和資源管理中的一些關(guān)鍵問題進(jìn)行了梳理，包括如何利用Docker Swarm、Kubernetes等工具將微服務(wù)部署到容器中，并在云環(huán)境中有效管理這些容器，但該方法并未考慮虛擬機(jī)的資源利用率。GERLACH等人[5]提出的Skyport系統(tǒng)是一個(gè)多云環(huán)境下的容器調(diào)度系統(tǒng)，可動(dòng)態(tài)調(diào)度容器的部署，但該系統(tǒng)假定虛擬機(jī)的資源無限。因此，在優(yōu)化微服務(wù)任務(wù)調(diào)度時(shí)，同時(shí)關(guān)注虛擬機(jī)和容器資源的利用率，有助于企業(yè)降低虛擬機(jī)成本，提高資源效率。為解決這個(gè)問題，本文提出了一種云虛擬機(jī)上動(dòng)態(tài)優(yōu)化容器部署的優(yōu)化算法。

2 數(shù)學(xué)建模

2.1 系統(tǒng)模型

本文系統(tǒng)的設(shè)計(jì)和建模基于以下假設(shè)：1） 容器能夠在不同虛擬機(jī)之間遷移，實(shí)現(xiàn)在最少數(shù)量的虛擬機(jī)中進(jìn)行優(yōu)化整合；2） 微服務(wù)所使用的容器鏡像可部署在任一虛擬機(jī)上，每種容器鏡像至少需要有一個(gè)容器實(shí)例；3） 允許有多個(gè)容器從同一個(gè)容器鏡像中被實(shí)例化出來，提供相同的微服務(wù)。

首先，給定一組微服務(wù)請(qǐng)求S = { s1，s2，...，sm }， 每個(gè)微服務(wù)請(qǐng)求都會(huì)被路由到一個(gè)已部署的容器云環(huán)境。給定一組容器鏡像CI = { ci1，ci2，...，cix }，每個(gè)容器鏡像提供一種容器服務(wù)，每個(gè)容器必須綁定一種容器鏡像；因此，微服務(wù)容器C = { c1，c2，...，cn }可以通過容器鏡像來實(shí)現(xiàn)實(shí)例化。所有的容器都部署在虛擬機(jī)上，V = { v1，v2，...， vq }。

系統(tǒng)根據(jù)請(qǐng)求量動(dòng)態(tài)調(diào)整容器實(shí)例，保持資源利用率在合理范圍。容器和虛擬機(jī)的擴(kuò)展或縮減決策基于資源需求和使用情況。本文不會(huì)僅因資源利用率短期下降就關(guān)閉容器或虛擬機(jī)，而是在資源持續(xù)低利用后才會(huì)考慮調(diào)整。其中，容器和虛擬機(jī)的資源利用率的計(jì)算方法如下：

容器的資源利用率：用一個(gè)矩陣Xi，j，t 來表示請(qǐng)求與容器之間的分配關(guān)系，這個(gè)矩陣表示在特定時(shí)刻t，請(qǐng)求si 是否被分配到了容器cj。那么，容器cj 在時(shí)刻t的資源利用率的計(jì)算公式如下：

式中，服務(wù)請(qǐng)求si 需要的計(jì)算能力以每秒百萬指令（MIPS） 來衡量，記為mipssi。相應(yīng)地，容器cj 的計(jì)算能力，即其MIPS容量，表示為mipscj。且Xi，j，t定義為：

虛擬機(jī)的資源利用率：同樣的，通過矩陣Yj，k，t 來展示容器與虛擬機(jī)之間的分配關(guān)系。在此矩陣中，元素Yj，k，t 代表在特定時(shí)刻t，容器cj 是否被分配到了虛擬機(jī)vk。在特定時(shí)間點(diǎn)t，虛擬機(jī)vk 的資源利用率的計(jì)算方法如下：

式中，虛擬機(jī)vk 的計(jì)算能力也是通過其每秒百萬指令（MIPS） 的容量來衡量的。而那些被分配給容器的服務(wù)請(qǐng)求，會(huì)被記錄在該容器的請(qǐng)求服務(wù)歷史表中，以便管理和追蹤。此外，Yj，k，t 的定義公式為：

2.2 問題建模

問題模型的目標(biāo)函數(shù)是在滿足微服務(wù)請(qǐng)求的前提下最小化云虛擬機(jī)資源的開啟量，并最大化每個(gè)虛擬機(jī)的容器資源利用率；約束條件為：1） 每個(gè)虛擬機(jī)有內(nèi)存的限制，只能容納特定數(shù)量的容器；2） 每個(gè)容器鏡像能夠響應(yīng)的并發(fā)請(qǐng)求數(shù)量不同。該模型可以在最小化按需收費(fèi)的虛擬機(jī)數(shù)量（例如阿里云的ECS） 的同時(shí)，最大化Docker容器的利用率。

給定一組微服務(wù)請(qǐng)求sm ∈ S （m = 1，2，...），一組容器鏡像 cix ∈ CI （x = 1，2，...）和一組虛擬機(jī)vi ∈ V （i =1，2，...）；需要求出一個(gè)調(diào)度計(jì)劃 f：si → cj，其中請(qǐng)求si由容器cj 來提供服務(wù)；求出一個(gè)容器分配計(jì)劃g：cj → vk，其中容器cj部署在虛擬機(jī)vk 上。

3 優(yōu)化算法

本文提出了一種全新的優(yōu)化算法，該算法專門用于處理獨(dú)立的微服務(wù)請(qǐng)求，目的是將這些請(qǐng)求合理分配到一組容器C 中，以便在相應(yīng)的一組虛擬機(jī)V 上順利運(yùn)行。每個(gè)容器僅支持運(yùn)行一種特定類型的微服務(wù)。因此，可以根據(jù)服務(wù)請(qǐng)求S 的屬性，將它們進(jìn)行分類并分配到合適的容器。

本文提出的優(yōu)化算法分為兩個(gè)階段：1） 服務(wù)請(qǐng)求的優(yōu)化分配算法；2） 容器和虛擬機(jī)的資源池管理算法。以下是具體的實(shí)施步驟。

3.1 服務(wù)請(qǐng)求的優(yōu)化分配算法

本文提出了一個(gè)服務(wù)請(qǐng)求的優(yōu)化分配算法（見算法1） ，該算法的基本邏輯為：在請(qǐng)求的調(diào)度周期內(nèi)，資源分配者會(huì)接收到一系列的服務(wù)請(qǐng)求，并將這些請(qǐng)求定向到相應(yīng)的容器。在進(jìn)行服務(wù)請(qǐng)求的分配之前，會(huì)先將容器按照資源利用率的高低進(jìn)行降序排列。目的是確保資源分配者能夠優(yōu)先將服務(wù)請(qǐng)求分配給那些資源利用率最高，但尚未達(dá)到過載狀態(tài)的容器。基于這種算法，即在服務(wù)需求下降時(shí)釋放利用率較低的容器，這樣可以有效地減少容器的部署。注意，企業(yè)的成本不直接與容器的部署數(shù)量掛鉤，而是與虛擬機(jī)的部署數(shù)量緊密相關(guān)。

為了使容器更高效地分布在較少的虛擬機(jī)中，本文提出了一種算法：根據(jù)容器利用率與虛擬機(jī)利用率的乘積（uc j，t?uvk，t ），對(duì)容器進(jìn)行降序排序。這一排序過程體現(xiàn)在算法1的第3行中，目的是優(yōu)化資源分配，確保容器能夠被合理地集中管理。

在算法1 中的第14～16行，選擇容器cj 來處理服務(wù)請(qǐng)求si 的條件是：容器的利用率uc jt 必須低于預(yù)設(shè)的利用率上限閾值θch，并且si 能夠在該容器中成功部署，即mipssi + θcj ? mipscj ≤ mipscj ，其中mips（百萬指令每秒的機(jī)器周期）。如果當(dāng)前沒有容器能夠滿足服務(wù)請(qǐng)求的部署條件，就需要在合適的虛擬機(jī)上，利用容器鏡像cia 來創(chuàng)建一個(gè)新的容器，以確保服務(wù)請(qǐng)求能夠得到處理。容器可以在虛擬機(jī)上部署的條件是該虛擬機(jī)擁有充足的資源，即虛擬機(jī)vk 在特定時(shí)間點(diǎn)t 的資源可用性的定義為：

式中，θvh為虛擬機(jī)利用率的上限閾值。

為了確保容器之間不會(huì)發(fā)生資源爭(zhēng)搶，本文假設(shè)：無論容器的實(shí)際使用情況如何，其所需的資源都將被完全保留。基于這個(gè)假設(shè)，虛擬機(jī)vk 資源可用性的定義中的uc j，t替換成1，具體表示如下：

這里，用函數(shù)isDeployableVM （cj， vk ）用于檢查虛擬機(jī)vk 是否具備滿足新容器cj 所需資源，當(dāng)mipscj ≤ Rvk，t時(shí)，即表示vk 的資源足夠，該函數(shù)將返回true。

3.2 容器與虛擬機(jī)的資源池管理算法

本文提出了容器和虛擬機(jī)的資源池管理算法（參見算法2） ，該算法的基本邏輯是：通過對(duì)容器和虛擬機(jī)按資源利用率降序排列，本文能夠在擴(kuò)展時(shí)，將微服務(wù)分配給列表中利用率最高的容器，而讓列表末尾的容器盡量保持低利用率。這種算法可確保列表末尾的虛擬機(jī)在不被需要時(shí)能夠進(jìn)入空閑狀態(tài)。如果這些虛擬機(jī)在列表尾部仍然沒有被分配任務(wù)，它們就可能被考慮為釋放候選。此外，如果列表尾部的容器是空閑的，它們也可能會(huì)被列入釋放的隊(duì)列。

在算法1結(jié)束后，算法2會(huì)對(duì)各種服務(wù)類型（即不同容器鏡像類型）的容器實(shí)例進(jìn)行健康狀態(tài)的檢查，并對(duì)其資源使用情況進(jìn)行二次分析；這些分析結(jié)果將作為擴(kuò)容或縮容的依據(jù)。

假定在某時(shí)間點(diǎn)t，容器鏡像類型cia，其容器實(shí)例ucia，t的資源利用率可以通過如下的計(jì)算方法得出：

式中，uc j，t 指的是容器cj 在時(shí)間t 的資源利用率，而Ca 表示由容器鏡像cia 生成的所有容器的集合。如果在t' 至t 某個(gè)時(shí)間段，容器的平均資源利用率超過了預(yù)設(shè)的上限閾值θch，那么就需要對(duì)Ca 進(jìn)行擴(kuò)容，以提升其處理能力。因此，在某個(gè)時(shí)間段的平均資源利用率計(jì)算方式如下：

算法2 的11～14行的計(jì)算邏輯是，如果平均資源利用率---ucia，t 大于θch 則---ucia，t – θch 個(gè)容器將被實(shí)例化；當(dāng)在虛擬機(jī)vk 上創(chuàng)建新容器時(shí)，必須確保該容器的新增資源不會(huì)使得虛擬機(jī)的總利用率超出設(shè)定的閾值θvh，可以通過如下公式來檢驗(yàn)：

當(dāng)容器無法適配現(xiàn)有的任何虛擬機(jī)時(shí)，則須創(chuàng)建一個(gè)新的虛擬機(jī)來為該容器提供所需的資源分配。為確保容器能夠迅速啟動(dòng)，避免因虛擬機(jī)實(shí)例化過程（通常需要1至2分鐘）造成的服務(wù)中斷或延誤，會(huì)在每個(gè)調(diào)度周期結(jié)束前對(duì)虛擬機(jī)進(jìn)行預(yù)擴(kuò)容；這樣，就能維護(hù)一個(gè)隨時(shí)可用的虛擬機(jī)池，確保容器可以被立即部署。

算法2 的18～20行的計(jì)算邏輯是，當(dāng)容器uci 在某時(shí)刻t 的平均資源利用率低于預(yù)設(shè)的下限閾值θcl 時(shí)，就需要對(duì)這些容器進(jìn)行釋放；釋放的規(guī)則是，選取前θcl - ---ucia，t ? |Ca| 個(gè)容器進(jìn)行關(guān)閉。同樣，當(dāng)虛擬機(jī)的平均資源利用率-uvt低于設(shè)定的下限閾值θvl 時(shí)，則會(huì)釋放相應(yīng)的虛擬機(jī)；釋放的規(guī)則是，選取前θvl - -uvt? |V| 個(gè)虛擬機(jī)。

4 實(shí)驗(yàn)結(jié)果

4.1 仿真環(huán)境搭建

仿真實(shí)驗(yàn)環(huán)境是基于阿里云的按量收費(fèi)的云服務(wù)器實(shí)例（ECS） 。本文選用了ecs.c7.xlarge這種計(jì)算密集型的虛擬機(jī)類型來部署容器。此類虛擬機(jī)配備了4個(gè)虛擬CPU（vCPU） 和8 GiB的內(nèi)存，并且能夠提供最高12.5 Gbps的內(nèi)網(wǎng)網(wǎng)絡(luò)帶寬。在實(shí)驗(yàn)中，每個(gè)容器最高可以提供100 MIPS的處理能力。因此，如果容器以最大性能運(yùn)行，一臺(tái)虛擬機(jī)理論上可以同時(shí)容納4個(gè)這樣的容器，這是基于虛擬機(jī)的最大利用率被設(shè)定為90%。

為了生成仿真數(shù)據(jù)，本文估算了在容器（滿負(fù)荷運(yùn)行）中處理一個(gè)微服務(wù)請(qǐng)求的平均耗時(shí)為510毫秒，這個(gè)執(zhí)行時(shí)間可能會(huì)在0.08秒到1.8秒之間波動(dòng)。據(jù)此計(jì)算，平均每分鐘大約能夠處理118個(gè)微服務(wù)請(qǐng)求。相應(yīng)地，一臺(tái)虛擬機(jī)平均每分鐘能夠處理的微服務(wù)請(qǐng)求數(shù)量為472個(gè)（即118個(gè)乘以4） 。在實(shí)驗(yàn)時(shí)，每分鐘微服務(wù)請(qǐng)求的數(shù)量范圍為3 000到21 000。

4.2 結(jié)果分析

Zhang等人[6]提出了三種公認(rèn)的標(biāo)準(zhǔn)容器分配算法：Spread、First-Fit 和Best-Fit。本文將通過與這些算法的比較來驗(yàn)證所提出算法的有效性。

如圖1與圖2所示，實(shí)驗(yàn)結(jié)果顯示，本文所提出的算法能夠顯著降低所需的容器總數(shù)，并能保持較高的容器利用率。從圖1可見，在Spread算法下，運(yùn)行微服務(wù)所需的容器數(shù)量稍顯偏高，F(xiàn)irst-Fit和Best-Fit這兩種算法的表現(xiàn)則較為接近。相較于Spread算法，本文的算法所使用的容器數(shù)量可節(jié)約11.1%～15.36%，與First-Fit和Best-Fit算法相比，容器數(shù)量可節(jié)約6.91% ～10.41%。此外，本文提出的算法僅需開啟44臺(tái)4核8G內(nèi)存的虛擬機(jī)，且容器的資源利用率達(dá)到了96%。這表明本文的算法在資源優(yōu)化方面具有明顯優(yōu)勢(shì)。

圖3展示了活躍虛擬機(jī)的數(shù)量，隨著部署容器數(shù)量的減少，活躍虛擬機(jī)的數(shù)量也隨之降低。具體來說，與Spread算法相比，本文的算法能夠?qū)⒒钴S虛擬機(jī)的數(shù)量減少10.12%～15.25%；與First-Fit 和Best-Fit算法相比，減少的幅度在6.14%～8.91%之間。

5 結(jié)論

本文提出了一種新的云虛擬機(jī)上動(dòng)態(tài)調(diào)度容器資源算法，旨在將微服務(wù)請(qǐng)求有效地分配至容器化的云計(jì)算環(huán)境中，并實(shí)現(xiàn)容器與底層虛擬機(jī)的自動(dòng)伸縮。實(shí)驗(yàn)顯示，通過與Spread、First-Fit和Best-Fit算法的性能對(duì)比，本文提出的算法顯著減少了阿里云的云虛擬機(jī)數(shù)量，即可為企業(yè)節(jié)約云計(jì)算虛擬機(jī)使用成本。在未來的工作中，將重點(diǎn)研究云虛擬機(jī)所占用物理機(jī)的分配調(diào)度，從而減少物理機(jī)的開啟數(shù)量，以達(dá)到節(jié)能減排的目標(biāo)。

參考文獻(xiàn)：

[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.

【通聯(lián)編輯：謝媛媛】