基于多樣性的微服務韌性部署機制

摘 要：針對微服務架構軟件系統的共享漏洞問題，面向微服務下的部署工作進行了研究，提出了一種面向韌性抗毀的多樣性微服務動態部署策略，能夠利用多樣性部署特點，根據資源約束情況部署多樣化的微服務組件，兼顧集中式部署與負載均衡的優勢，有效緩解了同構性帶來的問題，增強了軟件系統的韌性能力。在此基礎上實現了一種最小負載部署算法（Load-Min），并通過實驗和六種算法進行了比較，實驗結果顯示Load-Min部署算法相較其他經典算法，在資源利用效能、系統安全性等方面均有較大的提升。

關鍵詞：微服務； 多樣性； 軟件系統韌性； 容器部署； 服務組合

中圖分類號：TP393.0 文獻標志碼：A

文章編號：1001-3695（2022）03-035-0845-06

doi：10.19734/j.issn.1001-3695.2021.08.0347

基金項目：國家自然科學基金資助項目；國家博士后科學基金資助項目；江蘇省自然科學基金青年基金資助項目

作者簡介：余航（1997-），男，浙江衢州人，碩士，主要研究方向為網絡安全、軟件定義網絡、云計算；許博（1980-），男（通信作者），甘肅蘭州人，副教授，碩導，博士，主要研究方向為網絡性能測量、網絡流量識別、軟件定義網絡、信息系統開發等（xubo820@163.com）；王秀磊（1988-），男，山東濟寧人，講師，博士，主要研究方向為邊緣計算、網絡功能虛擬化、網絡安全、網絡管理.

Diversity-based microservice resilience deployment mechanism

Yu Hang， Xu Bo?， Wang Xiulei

（Command amp; Control Engineering College， Army Engineering University of PLA， Nanjing 210007， China）

Abstract：In order to alleviate the homogeneity problem， this paper proposed a diversity-based microservice resilience deployment mechanism. It designed the strategy to deploy a wide variety of instances according to resource constraints. Combined with centralized deployment and load balancing， the proposed strategy could effectively alleviate the homogeneity problem and enhance the resilience of the system. Thus， it implemented a minimum load deployment algorithm （Load-Min）. Simulation experiments show that compared with other six classical algorithms， Load-Min algorithm has great improvement in system security， resource utilization， and load balancing performance.

Key words：microservice; diversity; resilience of software systems; container deployment; service composition

0 引言

系統維持服務持續運行、確保在面臨多種異常情況下完成關鍵任務的能力通常被稱為系統韌性^[1]。為增強軟件系統韌性，服務提供商通常會采取多樣性及冗余部署的方式^[2]。傳統軟件系統的單體架構要求軟件必須整體部署^[3]，這使得實現多樣性和冗余技術將付出成倍的代價^[4]。而事實上，軟件系統不同模塊的重要性及脆弱性也不盡相同，通過增強部分模塊的多樣性即可有效提升系統整體的韌性抗毀能力。

微服務架構^[5]可以解決當前單體架構所面臨的問題，由于微服務架構下軟件系統被高度解耦^[6]，使得微服務組件能夠利用容器鏡像進行開發，提高了微服務組件的可重用性，所以微服務架構下的冗余部署相較于單體架構更加靈活高效。但可重用性高同時也意味著基于同一鏡像部署的多個組件容器都是同構的。研究表明，容器鏡像中普遍存在安全漏洞^[7]。因此一旦攻擊者獲得目標系統中某一微服務組件的漏洞，那么攻擊者隨后將反復利用這一漏洞成功攻擊使用同樣鏡像的容器，從而嚴重影響系統提供服務能力。當前研究人員普遍認為，采用異構部署^[8]等多樣性方法是解決同構性問題的有效手段^[2]。對于采取了多樣性的系統而言，攻擊者只有成功獲取了每種版本實現的漏洞才有可能在攻擊中取得成功，并且即便攻擊者獲得了暫時的成功，這一成功也是難以持續的。因此，版本數越多，多樣性指標越高，攻擊者的攻擊就越難以獲得成功。但多樣性指標并非越高越好，不同微服務之間、以及同一微服務的不同版本實現在資源消耗、負載情況、故障概率等方面不盡相同，所以多樣性的應用將進一步擴大系統的復雜性，從而在部署、運維、管理等方面帶來了新的挑戰。

本文旨在解決微服務架構下軟件系統多樣性部署問題，實現在異構的基礎設施上部署異構容器，有效增加軟件系統的多樣性，使得攻擊者無法利用容器的同構性，對微服務架構的軟件系統進行大規模破壞和打擊，從而保證軟件系統的韌性抗毀能力。

本文的主要貢獻包括：a）建立了一種多樣化微服務的部署模型，以最大化系統的韌性抗毀能力;b）提出了一種基于多樣性的異構容器編排方案，較好的克服了共享漏洞帶來的問題，通過冗余部署并提高多樣性水平，使得微服務可用性極大增強;c）提出了一種最小負載部署算法（Load-Min），該算法結合了集中式部署和分散部署的優勢，既通過集中式部署確保了較低的鏈路負載，又通過對多版本實現的分散部署避免了服務請求對單個節點的過度依賴，同時兼顧了負載均衡。

1 相關工作

目前，在微服務架構下的服務鏈部署問題上，已經有學者提出了一些切實可行的解決方案，但主要還是從效率方面開展研究。Wan等人^[9]利用Docker容器分層的特點提出了一種資源分配算法EPTA（EC placement and task assignment algorithm），該算法通過平衡喚醒成本、安裝成本和通信成本，顯著降低了部署成本。谷允捷等人^[10]提出了一種基于重疊網絡結構的服務功能鏈時空優化編排策略，該策略綜合考慮了節點計算資源、網絡鏈路資源與時延約束，將編排問題轉換為最短路徑問題，并用模擬退火算法進行了求解。Han等人^[11]針對工作負載進行性能分析實驗，從而得到精細的資源需求，并基于貪婪的啟發式算法執行微服務部署，該算法創新之處在于通過使用從剖析結果得出的精細化資源需求來考慮應用程序性能，但該算法只考慮了單條服務鏈的情況。Joseph等人^[12]提出了一種新穎的啟發式方法IntMA（interaction-aware microservice allocation），以借助從交互圖獲得的交互信息，從而以交互感知的方式部署微服務。但以上關于部署問題的工作都未基于多樣性進行過探討。

在引入多樣性的同時，如何在服務器集群中部署多版本的微服務組件，從而使得系統更安全高效，成為了研究人員需要關注的問題。目前部分工作結合了多樣性進行考慮，Torkura等人^[13]首次將移動目標防御技術（moving target defense，MTD）應用到微服務架構上，利用MTD機制，通過多樣化部署的安全策略最小化共享漏洞，為攻擊者帶來了不確定性，同時降低了微服務架構下系統的可攻擊性，以此克服同構性微服務帶來的安全隱患。謝記超等人^[14]提出了一種基于節點異構性的部署方法，旨在進行冗余備份和重映射時保證節點的異構性。Wen等人^[15]提出了一個新的可靠的微服務編排框架，該框架采用遺傳算法執行微服務組合，同時減少了用戶安全要求和實際服務提供之間的差異。張淼等人^[16]考慮到操作系統同構性可能引發的安全風險，利用異構操作系統提出了一種基于多樣性的虛擬機安全部署策略，有效降低了攻擊者的單位攻擊收益，但只考慮了虛擬機的安全部署，并未考慮資源約束等問題。傳統的部署與編排機制側重于單個服務鏈的服務質量（quality of service，QoS）優化，而忽略了實例之間的共享和競爭。為了解決這個問題，Ding等人^[17]提出了一種基于列表調度的微服務選擇算法（microservice service selection algorithm，MSS）。該算法采用工作流模型來對服務鏈進行描述，提出了基于子任務期限和緊迫性的兩種服務選擇策略，以完成微服務實例選擇，構成服務鏈。Alleg等人^[2]提出了一種多樣性和冗余聯合機制，并提出利用混合整數線性程序（mixed-integer linear programming，MILP）為模型的服務功能鏈（service function chain，SFC）部署解決方案，旨在滿足目標SFC可用性級別的同時，降低由于多樣性和冗余而導致的成本上升，避免了服務中斷，為備份實例分配了更少的資源。仝青等人^[18]提出了一種自適應的時空多樣性聯合調度策略，該策略聯合了時空多樣性，結合粗粒度的入侵檢測，克服了單一策略下防御代價高昂且效果不佳的缺陷，以較低代價提高了系統的防御能力，但并未討論資源消耗帶來的影響，也未將部署位置納入考慮。

微服務架構下服務鏈的部署問題可以理解為在一定約束條件下的優化問題，該問題是一個NP難問題，在求解部署方案的算法選擇上，研究人員通常選擇遺傳算法^[15]、模擬退火算法^[10]、列表搜索算法^[17]等啟發式算法，除此之外，Viterbi算法^{[14， 19]}也被多次提及。

2 基于多樣性的韌性微服務鏈動態部署模型

基于已有的研究可知，通過多樣性技術能夠有效提升軟件系統的韌性抗毀能力，但在現有單體式架構下，實現軟件系統的多樣性面臨較大的挑戰。微服務技術的出現為解決這一問題提供了新的思路，本章主要研究如何在資源約束下建立一種多樣化微服務的部署模型，以最大化系統的韌性抗毀能力。

2.1 基于多樣性的韌性系統模型與故障場景

2.1.1 基于多樣性的韌性系統模型

本文所提出的部署策略是一種半在線的部署策略，系統每次能夠處理一個批次的服務請求，每個服務請求對應著一個服務鏈，一條響應特定請求的服務鏈示例如圖1所示。

圖1的服務鏈示例由六個獨立的微服務組件協調完成，服務鏈基本模型可以用圖1所示的DAG圖表示。其中，Di表示該服務鏈上的第i個微服務組件，int（i，j）表示容器Di和Dj之間的業務流鏈路開銷。

圖2是服務鏈上各容器與基礎設施層各部署節點之間的映射關系，其中Ni（i=1，2，3，…）表示部署節點，節點既可能是某一臺物理服務器，也可能是某個部署在物理機上的虛擬機，使用不同的OS，包括Debian、Ubuntu、CentOS等。本文所研究的問題，就是如何根據請求將不同的服務鏈部署到具有多個部署節點的集群中，以滿足用戶和系統多樣性需要。

2.1.2 故障場景

1）共享漏洞問題 在使用容器構建軟件系統時，由于大量使用相同的基礎鏡像，所以當鏡像存在高危漏洞，并且當攻擊者掌握了這一漏洞時，攻擊者就能利用已知漏洞輕而易舉地針對系統中的容器發起攻擊，使之喪失服務能力。

2）節點故障問題 節點故障是一個不可避免的問題，當集群中某一個節點出現故障導致無法工作時，所有部署在該節點上的容器都將失去提供服務的能力，從而影響相關的服務請求完成情況。節點故障對服務請求的影響主要存在于兩個方面：a）主鏈上的容器失效，需要啟用部署在其他節點上的冗余服務組件;b）不僅主鏈上的容器失效，由于其他冗余也部署在同一節點上，或是該服務并未部署冗余，從而導致服務請求的失敗。本文在實驗環節中也將考察在某一節點失效的情況下系統受影響的程度。

2.2 問題建模

2.2.1 容器多樣性模型

文獻[16，20]根據生物多樣性的度量方法，利用香農公式，提出了一種系統多樣性的度量方法，對單個微服務而言，其數學公式可以表述為

其中：D表示該項微服務的多樣性指標;d表示該微服務組件的實現版本數量;pi表示第i個版本的組件部署數量占部署總數的比例。因此根據多樣性最大化的目標，求取的目標函數應該為Max D，約束條件為

根據香農第一定理，多樣性指標D取極值當且僅當p₁=p₂=…=pd=1d時成立，最大值為log₂d。

由此可見，在基于冗余和多樣性部署時，對每個微服務而言，應當使部署的微服務組件數量在各版本間盡可能地平均分布，由此獲得多樣性的最大化。

2.2.2 韌性部署問題模型

微服務架構下軟件系統在提供服務時，主要通過為用戶請求分配并部署服務鏈實現，該部署主要解決服務鏈上每個微服務部署版本種類數量、各版本冗余部署數量以及部署位置三個問題。該問題可以理解為在一定約束條件下的優化問題，本文的優化目標為在滿足軟件系統可靠性的同時，使集群消耗的網絡資源最小化。為對模型進行更好的解釋說明，本文對即將使用的變量符號進行了解釋說明，具體如表1所示。

從滿足用戶所需的服務可靠性出發，對于每個用戶請求，都應該通過部署合適的多樣性和冗余度，使其可靠性達到一個可接受的閾值A。假設請求Qi對應的服務鏈Gi中各微服務的故障概率為P^v，其中v∈Vi，那么服務鏈的可靠性約束可以描述為

在式（4）的約束下，為防止某一微服務可靠性過低給服務鏈帶來的可靠性瓶頸，因此本文對該約束條件進一步強化，進而要求每個微服務都達到一個最低可靠性閾值，如式（5）所示。

對于服務鏈中單個微服務v而言，由于運用了多樣性與冗余相結合的部署方式，各部署實例之間是并行的關系。在這種部署方式下，只有當部署的微服務v全部版本的所有實例都失效，微服務v才會出現不可用的情況，因此其故障概率P^v為

式（6）說明了微服務的可靠性可以通過部署更多的實例得到提高，將式（6）代入式（5）中，可以得到可靠性對于微服務部署的約束條件表達式：

除了可靠性約束外，服務鏈的部署還需要滿足計算和網絡資源約束，其約束條件可以表述為

其中：式（8）表示服務鏈中的某一個容器只能被部署一次；式（9）（10）分別表示節點上部署的容器所需消耗的處理器、內存資源之和不超過節點所擁有的資源上限；式（11）為物理鏈路資源約束。本文優化目標為在確保多樣性的基礎上，盡可能地減少交互，在降低鏈路開銷的同時，降低鏈路故障給服務帶來的影響，目標函數如式（12）所示。

2.3 模型分析

本文所提出的部署方法主要針對2.1.2節提出的兩大問題，結合負載均衡方法，旨在提出一種基于多樣性的微服務韌性部署方法，在降低共享漏洞和節點故障帶來的損失、提高系統可用性的同時，盡可能降低鏈路資源開銷，從而降低物理鏈路故障帶來的損失，并使之具備更好的負載均衡效果。基于以上目標，本文所提出的部署方案需要考慮以下原則：

a）盡可能將同一服務鏈上的主執行容器部署在同一節點上。這一原則有助于降低依賴于單個節點的服務請求數量，同時有助于減少微服務組件在部署節點之間的交互，從而降低物理鏈路故障帶來的損失。

b）多樣性部署版本不能與主執行容器部署在同一節點上。這樣做的優勢在于能夠避免由于節點損失導致的服務請求對應服務鏈上某一微服務功能徹底無法得到保證，從而導致服務請求的失敗。同時將多樣性部署版本部署到其他節點上，也有利于充分利用各部署節點上的碎片空間;將多樣性部署版本部署到資源壓力更輕的節點上，也有利于實現更好的負載均衡效果。

c）多樣性均衡要求。多樣性均衡主要是指，對于同一微服務而言，其部署各版本的容器數量應當盡可能保持均衡，其目的在于減輕由于共享漏洞問題帶來的微服務提供服務能力的損失，例如，當系統中大量的容器使用Ubuntu基礎鏡像構建容器，那么當該鏡像出現高危漏洞并為攻擊者所掌握時，系統將喪失大部分微服務的服務能力。

d）負載均衡。在進行部署時，除有類似于原則a）所提出的特殊要求外，應盡可能選擇資源壓力較輕的節點進行部署。

e）資源約束。主要包括節點資源約束和鏈路資源約束兩個方面。節點資源約束是指單個節點上的可用處理器（CPU）、內存（MEM）資源有限，部署在節點上的容器所需資源之和不得超過節點資源總量；鏈路資源約束是指每條物理鏈路上承載的虛擬鏈路傳輸數據量之和不得超過鏈路容量。

3 算法描述

3.1 基于多樣性的微服務編排算法

本文所使用的編排算法是考慮多樣性部署需要所設計的，充分考慮了2.3節中的多樣性均衡要求。此外，由于越復雜的服務請求，對應服務鏈所需微服務越多，根據式（7）可以得知，其對于單個微服務的可用性要求越高。在多樣性部署模式下，根據式（6），對于單個微服務而言部署的容器數量越多，其故障概率越低，可用性越高。因此，對于單個微服務而言，其所在的服務鏈越長，實現該微服務所需部署的容器數量就越多，這將導致大量的資源消耗。本文所給出的編排方案充分考慮了這一點，本方案優先考慮復雜服務請求，即優先處理更長的服務鏈，同時在挑選微服務組件部署版本時，優先考慮故障率更低的實現版本。

本編排算法的偽代碼如算法1所示，腳本的輸入包括：服務請求信息、微服務信息、拓撲信息。其中：服務請求信息包括了請求序號、服務鏈長度、服務鏈的微服務組成信息；微服務信息包括了各微服務不同版本實現的資源消耗、故障率、當前部署數量；拓撲信息主要保存了各請求對應的服務鏈的圖結構數據。

算法1 diversity-based microservices orchestration algorithm

輸入：req_info： the service requests information；svc_info： microservices information；topo_info： topos information。

輸出：service chains orchestration information。

1 for i in range（len（req_info））：

2 req ← request whose service chain with max topo lenth

3 sv_chain ← req corresponding service chain

4 error_threshold ← use sv_chain calculate error_threshold with formula （7）

5 while ms in sv_chain：

6 choose the version which has min error rate

7 ms_error_rate ← min error rate

8 while ms_error_rate gt; error_threshold：

9 choose the version with has min error rate among the other versions

10 ms_error_rate ←ms_error_rate * min error rate

11 end

12 end

在算法1中，第1～4行表示優先處理復雜服務請求，并根據服務鏈長度計算單項微服務所需提供的可用性指標。第5～7行表示在確定了所需處理的服務請求及其對應的服務鏈后，逐個確定該鏈中所需部署的微服務，以及在該鏈中單個微服務所需提供的可用性程度。第8～11行表示對于單個微服務而言，優先選擇故障概率低的實現版本，直到該項微服務整體可用性達到要求。在該算法中，假設一個批次有q個服務請求，每個服務請求包含m個微服務，每個微服務又存在v種版本實現，那么該算法的時間復雜度可以表示為O（qmv）。

3.2 最小負載部署算法Load-Min

服務鏈部署問題可以理解為在一定約束條件下求最優解的問題，該問題求解過程是一個NP難問題^[2]。由于網絡規模龐大，通過線性規劃尋找最優解決方案復雜度高、耗時長，并且用戶請求對即時性有嚴格的要求，而線性規劃無法在有效時間內得到有效解，所以此類問題通常使用啟發式算法。本文提出了一種最小負載部署算法（Load-Min），該算法是一種啟發式的半在線部署算法，該算法按時間窗口分批次處理服務請求，每批次服務請求數量與當前用戶需求與系統狀態相關。

本文在算法2中給出了部署算法的偽代碼，其輸入包括：服務請求信息、微服務信息、拓撲信息、編排信息、節點信息，其中前三項在算法1中已經進行過說明，在此不再贅述。第四項編排信息是由算法1的執行結果得到的，關于每個服務鏈中各微服務具體要部署哪些容器的信息。第五項節點信息保持著各節點實時的狀態信息，包括資源負載等。

算法2 Load-Min deployment algorithm

輸入：req_info： the service requests information；svc_info： microservices information；topo_info： topos information；orche_info： Orchestration information；node_info： node information。

輸出：Service chains deployment information。

1 for i in range（len（req_info））：

2 req ← request whose service chain with max topo lenth

3 sv_chain ← req corresponding service chain

4 node_main ← choose the node with min resource utilization rate

5 while ms in sv_chain：

6 while resource is not enough to deploy the first docker of ms：

7 node_main ← choose the node with min resource utilization rate among the other nodes

8 end

9 deploy the first docker on the node chosen

10 update node_info

11 // deploy the other dockers

12 for other dockers of ms：

13 node_vice ← choose the node with min resource utilization rate among the other nodes

14 while resource is not enough to deploy the docker：

15 node_vice ← choose the node with min resource utilization rate among the other nodes

16 end

17 deploy the docker on the node chosen

18 update node_info

19 end

在算法2中，第1～4行表示優先處理復雜服務請求，并根據各節點負載狀態獲取當前負載最輕的節點作為當前請求服務鏈的主部署節點，第5～10行表示該服務鏈上所有微服務的主執行容器都部署在該節點上，直到資源無法承受，再考慮部署到下一個節點上，這樣做的優勢是盡可能將同一服務請求的主執行容器集中在單一節點上，既能降低物理鏈路負載，又能減少對單一節點產生依賴的服務請求數量。第12～19行表示多樣性部署版本的部署，這類容器除了需要注意不與服務鏈中本微服務下其他微服務部署在同一節點上，其他主要考慮負載均衡效果，每次部署時都是種選擇資源負載最低的節點進行部署。在該算法中，假設一個批次有q個服務請求，每個服務請求包含m個微服務，每個微服務存在v種版本實現，集群中有n個部署節點，那么該算法的時間復雜度可以表示為O（qm（1×n+（v-1）×n×n/2）。

4 性能評估

本文首先對模型所描述的系統進行了簡單實現，并對其進行部分性能驗證。為更好地評估模型性能，本文針對更復雜條件下的情況進行了仿真。

4.1 基于多樣性的韌性部署原型系統實現

4.1.1 基于多樣性的微服務架構軟件系統原型

在基于軟件定義網絡（software define network，SDN）實現的軟件系統網絡中，可以將編排器集成在SDN控制器中，使之成為整個軟件系統的控制中心。如圖3所示，SDN控制器能夠根據用戶請求和資源約束定制部署策略，并將部署策略下發至集群各服務器中執行。在本文所設計的原型系統中，根據是否啟用虛擬機，集群中的服務器分為直接作為服務部署節點部署微服務組件（即業務容器）以及在服務器上啟動虛擬機作為服務容器部署節點兩種，如圖3中的服務器A。

本文使用Docker容器技術，Docker提供的虛擬化技術使得研究能夠忽略底層平臺的差異性，因此本文統一將諸如服務器A、VM1、VM2這樣直接部署容器的主機視為部署節點。對于在節點上部署的業務容器而言，同屬于同一微服務的容器有多個版本的實現，即使用不同容器鏡像構建的具有相同業務功能的容器模板。例如，對于實現Web前端功能的容器而言，容器構建使用的基礎鏡像可以使用Ubuntu、Debian、CentOS等，不同版本的實現會帶來不同的資源開銷。在本文所描述的軟件系統中，系統業務被解耦成多個微服務，包括Web前端、數據庫查詢、加密組件等，不同微服務之間相互協調從而構成服務鏈。

4.1.2 實驗分析

為實現本文提出的基于多樣性的微服務韌性部署方法，本文設計了第3章所述的原型系統，該系統包括一個SDN控制器（集成微服務編排器），兩臺服務器（共三個部署節點），一臺二層交換機，兩臺OpenFlow交換機，一臺PC作為用戶。

為了驗證策略實施的可行性和算法的有效性，本文在進行仿真實驗之前，預先在原型系統“運力查詢系統”上進行了驗證實驗。原型系統包括Web、Database和Encrypt三種微服務。每類微服務都分別基于Ubuntu、CentOS和Debian進行了三種實現，九種容器的資源消耗情況如表2所示。服務請求包括兩種實現：a）使用三種微服務進行響應的加密查詢;b）使用兩種微服務進行響應的普通查詢（不使用Encrypt服務），隨機使用兩種服務請求進行10次操作進行驗證。

如圖4、5所示，整體上看，Load-Min算法具有良好的負載均衡能力，這種均衡不僅體現在節點壓力上，同時部署的各微服務版本間也存在較好的均衡，這有利于在面對攻擊者針對某一已泄漏容器漏洞發起攻擊時，盡可能降低損失，避免系統喪失提供服務能力。

4.2 基于多樣性的韌性部署仿真實驗

4.2.1 實驗設置

a）平臺。本文仿真實驗在DELL T7920工作站上執行，其處理器為Intel Xeon Gold 6248R CPU@3.00 GHz×96（雙處理器），內存大小為512 GB，使用Ubuntu Server操作系統。為了驗證策略性能，本文使用Python 3.7進行仿真。

b）數據。本文所涉及的主要仿真參數如表3所示。

c）方法。將本文所使用的部署策略與六種算法進行對比，其中包括四種經典算法與兩種新近算法。

其中四種經典算法包括：

（a）貪婪負載均衡算法（LB-greedy）。該算法僅以追求負載均衡為目標，無論在確定實例版本還是節點負載上，每一次選擇都選擇使用最少的版本和負載最低的節點來承載實例。

（b）輪詢算法（Round-Robin）。該算法維護一個順序列表，在每次選擇實例部署版本和部署節點時都采用輪詢方式，這一方式有利于負載均衡的實現，是一種典型的負載均衡方法。

（c）隨機部署算法（Random）。該算法在每次選擇實例部署版本和部署節點時都采用隨機選擇的方式，這一方式有利于負載均衡的實現，是一種典型的負載均衡方法。

（d）集中部署算法（Concentrate）。該算法在選擇部署實例版本時與Load-Min類似，但在每次選擇部署節點時都盡可能將同屬于一個服務鏈的實例部署在同一節點上，這一方式有利于減少節點間的交互，減少鏈路負載的同時降低對鏈路的依賴。

兩種新近方案包括：

（a）混合整數線性程序（MILP）^[2]。在滿足目標服務鏈可用性級別的同時，降低由于多樣性和冗余而導致的資源成本，有利于在避免服務中斷的同時，為備份實例分配更少的資源。

（b）基于列表調度的微服務選擇算法（MSS）^[17]。這是一種基于子任務期限和緊迫性的服務選擇策略，通過這種方式完成微服務實例選擇，從而構成服務鏈。

將本文所提出的Load-Min算法分別在負載均衡、共享漏洞、節點故障三個方面與上述六種經典算法進行對比考察。

d）指標。主要包括兩個方面四項指標：資源效能方面，主要包括負載均衡和鏈路負載兩點，負載均衡考察各節點之間資源利用率的標準差，標準差越小說明各節點之間的負載越均衡；安全性能方面，主要考察在共享漏洞問題和節點故障問題中，各部署策略下服務請求的完成情況，包括受影響請求數和失敗服務請求數兩個指標。受影響請求是指服務鏈主鏈上的主執行容器遭到破壞無法繼續使用，從而啟用多樣性冗余的請求，該請求仍能完成，只不過性能會有略微影響。失敗服務請求是指由于故障等原因導致該服務鏈上某一微服務的實現被全部摧毀，無法繼續提供此項服務，因此服務請求無法完成。

4.2.2 資源效能評估

1）負載均衡 本節主要考察不同的部署方法下的負載均衡表現，如圖6所示，其中（a）～（e）表示不同算法實現下，各節點資源的負載情況，圖中cpu_usage_percentage表示節點CPU利用率，mem_usage_percentage表示節點內存利用率，resource_average為上述兩項的加權和。

其中：（α，β）為權重參數，表示對該項的重視程度。例如，在CPU密集型任務中，顯然CPU的狀態是更值得關注的對象，那么α的取值將遠大于β，由于本實驗中整體上來看CPU與內存負載壓力相差不大，所以取α=β=0.5。圖6展示了不同算法下各節點resource_average的標準差，可見負載均衡表現最好的是LB-greedy算法，稍好于Load-Min算法，但差距并不明顯，這是由于LB-greedy算法單純只追求負載均衡的結果，而Load-Min算法則需要兼顧主鏈集中部署的原則。除LB-greedy外的三種經典算法表現則與前兩者存在相當大的差距，此外，可見兩種新近算法也將負載均衡要素考慮在內。

2）鏈路負載 如表4所示，由于LB-Greedy、Round-Robin、Random算法在每次部署時更傾向于將同一服務鏈的容器部署到不同的節點上，因此利用這三種算法部署得到的鏈路負載遠遠大于另外兩種新算法。可見雖然LB-Greedy算法獲得了最好的負載均衡效果，但卻帶來了巨大的鏈路負載壓力。

Load-Min算法在鏈路負載方面的表現是所有算法中最好的，甚至遠小于Concentrate。Concentrate本身是一種集中式的部署方法，這種方式是有利于降低鏈路負載的，但是由于該算法必須要填滿一個節點后才能在下一個節點上進行部署，這種方式將導致大量的請求服務鏈部署在前后相鄰的兩個節點上，而Load-Min則靈活選擇資源壓力最小的節點部署整個主鏈，使盡可能多的服務鏈主鏈部署在單一節點上，從而帶來了相較于Concentrate算法實現更小的鏈路負載。此外，兩種新近策略中，MSS的鏈路負載顯然小于其余多數方案，甚至接近Concentrate的結果，原因是該算法需要強調響應時間，在這一目標下服務鏈將盡可能被約束在同一節點下，以此達到縮減響應時間的目標。而MILP的負載同樣相對較低的原因在于在該模型中，鏈路資源也是需要降低的資源成本之一。

4.2.3 安全性能評估

a）單鏡像漏洞泄露下對服務請求的影響。共享漏洞問題本質上是已經部署了服務的容器中，當某一類容器集體失效時，使得部分微服務失去提供服務的能力，從而導致服務鏈的不完整，最終使得服務請求失敗。共享漏洞問題主要與該微服務所部署的容器多樣性相關，由于所有容器在部署之前就已經通過編排得到了所要部署的微服務組件容器版本數量與部署數目，所以本小節主要考察在不同多樣性下用戶服務請求的受影響及完成情況。如圖7所示，隨著多樣性的增減，受影響的服務請求數不斷減少，而在圖8中則顯示，當多樣性水平（即每個微服務的實現版本數）大于等于2后，徹底失去服務能力而導致失敗的請求數就快速下降到了較低水平。

b）單節點故障下對服務請求的影響。當集群中某一個部署節點發生故障時，部署在該節點上的容器就會全部失去其提供服務的能力，從而對服務請求產生影響。為了更準確地評估這一故障帶來的損失，分別在每一批請求數量分別為{5，10，15，20，25}的情況下，針對每一個節點都可能發生的故障情況進行了反復實驗，通過多次實驗取均值的方式獲取了在不同部署模式下，隨著服務請求數量變化，而產生的服務請求受影響情況。根據圖9能夠獲知，隨著每一批次處理的服務請求數量不斷增加，因單節點故障而受影響的服務請求數量逐步上升，其中表現最好的是Concentrate和Load-Min算法，這是因為這兩種算法盡可能將同一服務鏈的主鏈放置到同一節點上的緣故，這導致了節點上的大量資源被少數幾個服務請求占據，因此在單節點故障時受影響最小。而另外三種經典算法則恰恰相反，另外三種都趨向于將容器分開部署，這樣部署的結果是單個節點的資源被大量服務請求共享，使得在節點故障時有大量的服務請求受到影響。兩種新近算法由于鏈路資源等原因考慮了將服務鏈上的實例集中部署，所以相對于上述三種經典算法有更好的表現。

圖10則展示了七種不同算法的部署結果在承受單節點損失下無法完成的服務請求數（圖中Round-Robin與Load-Min重合），在圖9中有著較好表現的Concentrate算法在這種情況下則表現最為糟糕。由于Concentrate算法在集中部署時，不僅將同一請求的主鏈部署在了同一節點上，其多樣性版本也同樣部署在了同一節點上，這導致了一旦節點發生故障無法繼續工作，所有將全部實例都部署在該節點上的微服務失去服務能力，從而導致服務請求失敗。Load-Min算法則巧妙地避開了這一尷尬結果，Load-Min算法只把主鏈部署在同一節點上，并且在部署其他版本的容器時，尤其注意避開已部署了同一微服務的節點，并盡可能分散部署，在分散這一點上，Load-Min和Round-Robin是一致的，因此兩者都在單節點故障下具有最小的損失。

5 結束語

本文針對微服務架構下如何基于多樣性對異構容器進行部署提出了一種最小負載部署算法（Load-Min）。該方案結合了集中式部署與負載均衡算法的優勢，既保留了集中式部署鏈路資源消耗低的優勢，又兼顧了負載均衡，降低了對單節點的依賴。結合應用多樣性條件下的編排算法，本文對Load-Min算法和其他六種算法進行了比較，實驗結果顯示Load-Min部署算法相較其他經典算法，顯得更加高效、安全和可靠。

本文提出的Load-Min算法是一種半在線部署方法，這種方法需要按時隙分批次對服務請求進行處理，這種處理方式每批次能處理的服務請求有限，并且這種部署方式可能增大服務時延。針對上述問題，下一步的研究工作將致力于研究完全在線的部署方案，甚至可以利用機器學習的手段對服務持續時間進行預測，從而更精確地對實時響應的服務請求作出更加合理的部署，進一步提高資源利用率，縮短響應時間。

參考文獻：

[1]Gesvindr D， Davidek J， Buhnova B. Design of scalable and resilient applications using microservice architecture in PaaS cloud[C]//Proc of International Conference on Software Technologies. 2019： 619-630.

[2]Alleg A， Ahmed T， Mosbah M， et al. Joint diversity and redundancy for resilient service chain provisioning[J].IEEE Journal on Selec-ted Areas in Communications，2020，38（7）：1490-1504.

[3]Esposito C， Castiglione A， Choo K-K R. Challenges in delivering software in the cloud as microservices[J].IEEE Cloud Computing，2016，3（5）：10-14.

[4]Douglis F， Nieh J. Microservices and containers[J].IEEE Internet Computing，2019，23（6）：5-6.

[5]Vayghan L A， Saied M A， Toeroe M， et al. Microservice based architecture： Towards high-availability for stateful applications with Kubernetes[C]//Proc of IEEE International Conference on Software Quality， Reliability and Security.Piscataway，NJ：IEEE Press，2019：176-185.

[6]Wang Sheng， Ding Zzhijun， Jiang Changjun. Elastic scheduling for microservice applications in clouds[J].IEEE Trans on Parallel and Distributed Systems，2020，32（1）：98-115.

[7]Combe T， Martin A， Pietro R D. To docker or not to docker： a secu-rity perspective[J].IEEE Cloud Computing，2016，3（5）：54-62.

[8]Mijumbi R， Serrat J， Gorricho J-L， et al. Network function virtua-lization： state-of-the-art and research challenges[J].IEEE Communications Surveys amp; Tutorials，2015，18（1）：236-262.

[9]Wan Xili， Guan Xinjie， Wang Tianjing， et al. Application deployment using microservice and docker containers： framework and optimization[J].Journal of Network and Computer Applications，2018，119：97-109.

[10]谷允捷，胡宇翔，謝記超.基于重疊網絡結構的服務功能鏈時空優化編排策略[J].電子與信息學報，2019，41（11）：2675-2683.（Gu Yunjie， Hu Yuxiang， Xie Jichao. A spatial and temporal optimal method of service function chain orchestration based on overlay network structure[J].Journal of Electronics amp; Information Technology，2019，41（11）：2675-2683.）

[11]Han Jungsu， Hong Yujin， Kim J. Refining microservices placement employing workload profiling over multiple Kubernetes clusters[J].IEEE Access，2020，8：192543-192556.

[12]Joseph C T， Chandrasekaran K. IntMA： dynamic interaction-aware resource allocation for containerized microservices in cloud environments[J].Journal of Systems Architecture，2020，111：101785-101799.

[13]Torkura K A， Sukmana M I H， Kayem A V D M. A cyber risk based moving target defense mechanism for microservice architectures[C]//Proc of IEEE International Conference Ubiquitous Computing and Communication.Piscataway，NJ：IEEE Press，2018：932-939.

[14]謝記超，伊鵬，張震，等.基于異構備份與重映射的服務功能鏈部署方案[J].網絡與信息安全學報，2018，4（6）：23-35.（Xie Jichao， Yi Peng， Zhang Zhen， et al. Service function chain deployment scheme based on heterogeneous backup and remapping[J].Chinese Journal of Network and Information Security，2018，4（6）：23-35.）

[15]Wen Zhenyu， Lin Tao， Yang Renyu， et al. GA-Par：dependable microservice orchestration framework for geo-distributed clouds[J].IEEE Trans on Parallel and Distributed Systems，2019，31（1）：129-143.

[16]張淼，季新生，艾健健，等.基于操作系統多樣性的虛擬機安全部署策略[J].網絡與信息安全學報，2017，3（10）：35-43.（Zhang Miao， Ji Xinsheng， Ai Jianjian， et al. Secure deployment strategy of virtual machines based on operating system diversity[J].Chinese Journal of Network and Information Security，2017，3（10）：35-43.）

[17]Ding Zhijun， Wang Sheng， Pan Meiqin. QoS-constrained service selection for networked microservices[J].IEEE Access，2020，8：39285-39299.

[18]仝青，郭云飛，霍樹民，等.自適應的時空多樣性聯合調度策略設計[J].通信學報，2021，42（7）：12-24.（Tong Qing， Guo Yunfei， Huo Shumin， et al. Design of self-adaptive spatio-temporal diversity joint scheduling strategy[J].Journal on Communications，2021，42（7）：12-24.）

[19]劉彩霞，盧干強，湯紅波，等.一種基于Viterbi算法的虛擬網絡功能自適應部署方法[J].電子與信息學報，2016，38（11）：2922-2930.（Liu Caixia， Lu Ganqiang， Tang Hongbo， et al. Adaptive deployment method for virtualized network function based on Viterbi algorithm[J].Journal of Electronics amp; Information Technology，2016，38（11）：2922-2930.）

[20]Tong Qing， Guo Yunfei， Hu Hongchao， et al. A diversity metric based study on the correlation between diversity and security[J].IEICE Trans on Information and Systems，2019，102（10）：1993-2003.