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

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

關(guān)鍵詞：微服務； 多樣性； 軟件系統(tǒng)韌性； 容器部署； 服務組合

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

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

doi：10.19734/j.issn.1001-3695.2021.08.0347

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

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

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 引言

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

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

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

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

1 相關(guān)工作

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

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

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

2 基于多樣性的韌性微服務鏈動態(tài)部署模型

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

2.1 基于多樣性的韌性系統(tǒng)模型與故障場景

2.1.1 基于多樣性的韌性系統(tǒng)模型

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

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

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

2.1.2 故障場景

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

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

2.2 問題建模

2.2.1 容器多樣性模型

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

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

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

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

2.2.2 韌性部署問題模型

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

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

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

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

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

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

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

2.3 模型分析

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

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

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

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

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

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

3 算法描述

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

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

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

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

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

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

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

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

4 性能評估

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

4.1 基于多樣性的韌性部署原型系統(tǒng)實現(xiàn)

4.1.1 基于多樣性的微服務架構(gòu)軟件系統(tǒng)原型

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

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

4.1.2 實驗分析

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

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

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

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

4.2.1 實驗設(shè)置

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

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

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

其中四種經(jīng)典算法包括：

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

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

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

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

兩種新近方案包括：

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

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

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

d）指標。主要包括兩個方面四項指標：資源效能方面，主要包括負載均衡和鏈路負載兩點，負載均衡考察各節(jié)點之間資源利用率的標準差，標準差越小說明各節(jié)點之間的負載越均衡；安全性能方面，主要考察在共享漏洞問題和節(jié)點故障問題中，各部署策略下服務請求的完成情況，包括受影響請求數(shù)和失敗服務請求數(shù)兩個指標。受影響請求是指服務鏈主鏈上的主執(zhí)行容器遭到破壞無法繼續(xù)使用，從而啟用多樣性冗余的請求，該請求仍能完成，只不過性能會有略微影響。失敗服務請求是指由于故障等原因?qū)е略摲真溕夏骋晃⒎盏膶崿F(xiàn)被全部摧毀，無法繼續(xù)提供此項服務，因此服務請求無法完成。

4.2.2 資源效能評估

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

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

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

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

4.2.3 安全性能評估

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

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

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

5 結(jié)束語

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

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

參考文獻：

[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]谷允捷，胡宇翔，謝記超.基于重疊網(wǎng)絡(luò)結(jié)構(gòu)的服務功能鏈時空優(yōu)化編排策略[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]謝記超，伊鵬，張震，等.基于異構(gòu)備份與重映射的服務功能鏈部署方案[J].網(wǎng)絡(luò)與信息安全學報，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]張淼，季新生，艾健健，等.基于操作系統(tǒng)多樣性的虛擬機安全部署策略[J].網(wǎng)絡(luò)與信息安全學報，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]仝青，郭云飛，霍樹民，等.自適應的時空多樣性聯(lián)合調(diào)度策略設(shè)計[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算法的虛擬網(wǎng)絡(luò)功能自適應部署方法[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.