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

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

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

文章編號：1009-3044（2024）27-0048-04

0 引言

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

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

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

1 相關(guān)研究

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

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

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

2.1 系統(tǒng)模型

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

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

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

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

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

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

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

2.2 問題建模

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

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

3 優(yōu)化算法

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

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

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

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

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

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

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

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

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

3.2 容器與虛擬機的資源池管理算法

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

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

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

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

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

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

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

4 實驗結(jié)果

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

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

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

4.2 結(jié)果分析

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

如圖1與圖2所示，實驗結(jié)果顯示，本文所提出的算法能夠顯著降低所需的容器總數(shù)，并能保持較高的容器利用率。從圖1可見，在Spread算法下，運行微服務(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臺4核8G內(nèi)存的虛擬機，且容器的資源利用率達(dá)到了96%。這表明本文的算法在資源優(yōu)化方面具有明顯優(yōu)勢。

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

5 結(jié)論

本文提出了一種新的云虛擬機上動態(tài)調(diào)度容器資源算法，旨在將微服務(wù)請求有效地分配至容器化的云計算環(huán)境中，并實現(xiàn)容器與底層虛擬機的自動伸縮。實驗顯示，通過與Spread、First-Fit和Best-Fit算法的性能對比，本文提出的算法顯著減少了阿里云的云虛擬機數(shù)量，即可為企業(yè)節(jié)約云計算虛擬機使用成本。在未來的工作中，將重點研究云虛擬機所占用物理機的分配調(diào)度，從而減少物理機的開啟數(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)編輯：謝媛媛】