面向微服務(wù)架構(gòu)的軟件系統(tǒng)韌性增強(qiáng)技術(shù)研究*

余 航，許 博

(陸軍工程大學(xué) 指揮控制工程學(xué)院，江蘇 南京 210007)

0 引言

對(duì)于軟件系統(tǒng)，尤其是具有關(guān)鍵任務(wù)使命的系統(tǒng)而言，確保任務(wù)執(zhí)行不中斷、具備持續(xù)運(yùn)行能力、保證使命任務(wù)的完成至關(guān)重要。 事實(shí)上，許多風(fēng)險(xiǎn)都會(huì)對(duì)系統(tǒng)服務(wù)產(chǎn)生嚴(yán)重影響，例如自然災(zāi)害、硬件故障、性能過載、錯(cuò)誤配置、軟件漏洞、惡意程序、敵對(duì)攻擊等[1]，故障風(fēng)險(xiǎn)的增加會(huì)嚴(yán)重降低已部署服務(wù)的質(zhì)量，甚至導(dǎo)致服務(wù)完全中斷。

在安全領(lǐng)域，盡管許多科研人員仍然致力于構(gòu)建更加健全的外部安防體系，試圖將威脅拒止于受保護(hù)的系統(tǒng)之外，但一旦研究人員精心構(gòu)建的防被線被突破之后，所有的努力都將功虧一簣。 鑒于當(dāng)前網(wǎng)絡(luò)環(huán)境的復(fù)雜性、威脅形式的多樣性以及威脅的不可預(yù)測(cè)性，利用傳統(tǒng)的外部防御手段來實(shí)現(xiàn)無懈可擊的保護(hù)是不現(xiàn)實(shí)的。 并且復(fù)雜的安防系統(tǒng)會(huì)因?yàn)檫^于臃腫而導(dǎo)致資源的嚴(yán)重消耗以及系統(tǒng)網(wǎng)絡(luò)性能的下降[2]，因此需要改變思維方式，考慮當(dāng)外部防御失敗后的狀況。 也就是說，系統(tǒng)必須考慮在面對(duì)已經(jīng)到來的破壞情況下，如何確保服務(wù)得以持續(xù)，保證任務(wù)使命得以完成。

1 相關(guān)背景

1.1 系統(tǒng)韌性

系統(tǒng)抵抗風(fēng)險(xiǎn)可能帶來的破壞性并在災(zāi)害、故障、攻擊到來時(shí)維持服務(wù)持續(xù)運(yùn)行、確保使命必達(dá)的能力通常被稱為系統(tǒng)韌性。自美國(guó)國(guó)防部于2014年提出并推行“網(wǎng)絡(luò)韌性”以來，“韌性”一詞便在計(jì)算機(jī)領(lǐng)域受到廣泛關(guān)注。

韌性多用于表示實(shí)體或系統(tǒng)在發(fā)生擾動(dòng)后快速恢復(fù)到常態(tài)的能力[3]。 堪薩斯大學(xué) ResiliNets 項(xiàng)目對(duì)于韌性的定義是“當(dāng)正常操作面臨故障和挑戰(zhàn)時(shí)能夠提供并維持可接受的服務(wù)水平的能力”[4]。 而在軟件系統(tǒng)中，韌性能力是指確保軟件系統(tǒng)在遭受各種事故時(shí)，仍然能夠保持關(guān)鍵服務(wù)的可用性與可持續(xù)性，確保任務(wù)能夠完成[5]。

1.2 微服務(wù)架構(gòu)

到目前為止，最常見的用于部署應(yīng)用程序的體系結(jié)構(gòu)是單體架構(gòu)。 在單體架構(gòu)中，每個(gè)部署單元都是處理所有功能的自治實(shí)體。 但單體架構(gòu)存在擴(kuò)展性差、可靠性低、可重用性低、維護(hù)成本高等問題，近年來提出的微服務(wù)架構(gòu)[6]給出了一種新的解決思路。

微服務(wù)架構(gòu)最早由 Fred George 在2012 年 3 月的Agile India 上提出，Martin 和 James 在 Microservices[7]文中對(duì)其進(jìn)行了通俗易懂的闡述。 該架構(gòu)將復(fù)雜的應(yīng)用程序解耦為輕量級(jí)和松散耦合的組件，較為成功地克服了單體架構(gòu)的局限性。 每個(gè)組件都使用單獨(dú)的源代碼存儲(chǔ)庫(kù)獨(dú)立執(zhí)行微服務(wù)，并且可以在不涉及其他組件的情況下進(jìn)行更新。 此外，考慮到不同應(yīng)用程序組件的不同資源需求，微服務(wù)體系結(jié)構(gòu)支持獨(dú)立擴(kuò)展每個(gè)組件。 簡(jiǎn)而言之，微服務(wù)架構(gòu)提供了改善應(yīng)用程序開發(fā)的可伸縮性和彈性的可能性。 當(dāng)前，在微服務(wù)架構(gòu)被廣泛應(yīng)用于應(yīng)用程序部署之前，其仍處于起步階段，面臨許多挑戰(zhàn)。基于容器的虛擬化技術(shù)由于其輕量級(jí)和即時(shí)性，被認(rèn)為是在實(shí)踐中加速微服務(wù)架構(gòu)應(yīng)用的良好選擇。 單體架構(gòu)與微服務(wù)架構(gòu)圖如圖1 所示。

圖1 單體架構(gòu)與微服務(wù)架構(gòu)

在微服務(wù)架構(gòu)中，應(yīng)用程序被解耦成了服務(wù)的集合，每個(gè)微服務(wù)都有單一的功能，都是獨(dú)立開發(fā)、部署和管理的[8]。 在微服務(wù)架構(gòu)下，軟件產(chǎn)品的更新和新特性可以以每天數(shù)百次的頻率不斷發(fā)布，使應(yīng)用程序非常動(dòng)態(tài)。 微服務(wù)這種松散耦合的特性給軟件系統(tǒng)韌性增強(qiáng)帶來了高度的敏捷性。

微服務(wù)架構(gòu)下服務(wù)通常部署在容器中[9]，尤其是近年來 Docker 容器技術(shù)[10]的興起，利用 Docker 技術(shù)構(gòu)建微服務(wù)架構(gòu)的軟件系統(tǒng)已經(jīng)成為了行業(yè)內(nèi)的實(shí)際標(biāo)準(zhǔn)。 為了簡(jiǎn)化容器的管理與編排，提高實(shí)際應(yīng)用中的生產(chǎn)效率，在一段時(shí)間內(nèi)出現(xiàn)了容器云管理平臺(tái)百家爭(zhēng)鳴的局面。 目前三大主流的容器平臺(tái)分別是 Swarm、Mesos 和 Kubernetes，其中 Google 公司的Kubernetes 目前已經(jīng)成為了行業(yè)內(nèi)的實(shí)際標(biāo)準(zhǔn)。

2 微服務(wù)架構(gòu)下的韌性增強(qiáng)技術(shù)

由于微服務(wù)松散耦合、分散治理的理念，使得微服務(wù)架構(gòu)的軟件系統(tǒng)能夠具備服務(wù)微小化、模塊化設(shè)計(jì)、高度自治、可獨(dú)立替換、組件可獨(dú)立升級(jí)等優(yōu)良特性[7]，這些特性使得在微服務(wù)架構(gòu)的基礎(chǔ)上應(yīng)用大量韌性增強(qiáng)技術(shù)成為了可能，例如冗余、多樣性、資源擴(kuò)展、遷移等，本節(jié)主要介紹在微服務(wù)框架下的韌性增強(qiáng)技術(shù)。

2.1 冗余與多樣性

基于微服務(wù)架構(gòu)構(gòu)建的軟件系統(tǒng)，得益于松散耦合的優(yōu)勢(shì)，可以將軟件系統(tǒng)拆分成相互獨(dú)立的若干個(gè)部分，各個(gè)部分之間獨(dú)立工作，結(jié)合容器技術(shù)，各個(gè)獨(dú)立的部分都可以打包成不同的實(shí)例，作為構(gòu)建完整軟件系統(tǒng)的組件。 這就給軟件系統(tǒng)的韌性增強(qiáng)提供了巨大的潛力，在此基礎(chǔ)之上應(yīng)用多樣性和冗余技術(shù)，以此來提高系統(tǒng)的可用性。

2.1.1 冗余

虛擬化環(huán)境和微服務(wù)架構(gòu)提供的靈活性將取代傳統(tǒng)單體架構(gòu)下軟件系統(tǒng)的剛性。 在傳統(tǒng)單體架構(gòu)下，通常通過部署多個(gè)完整的軟件應(yīng)用來構(gòu)建一個(gè)有冗余的健壯的軟件系統(tǒng)，從而導(dǎo)致高昂的成本。 而在基于虛擬化實(shí)現(xiàn)的微服務(wù)架構(gòu)軟件系統(tǒng)中，只需通過添加一組輔助或冗余組件來確保對(duì)關(guān)鍵組件發(fā)生故障時(shí)的恢復(fù)能力，如圖2 所示。

圖2 系統(tǒng)冗余示意圖

2.1.2 多樣性

2016 年歐洲電信標(biāo)準(zhǔn)協(xié)會(huì)[11]提倡開發(fā)者設(shè)計(jì)和實(shí)現(xiàn)多樣性以作為容錯(cuò)的一種手段，并討論了旨在實(shí)現(xiàn)自動(dòng)控制軟件多樣性的技術(shù)方法。

多樣性的基本思想在于用若干個(gè)擁有相同功能的不同實(shí)現(xiàn)組成的實(shí)例池替換單個(gè)實(shí)例。 如圖3所示，這些實(shí)例以并行方式集體地執(zhí)行與原始實(shí)例相同的功能，并且同時(shí)處理與原始實(shí)例相同的業(yè)務(wù)，在這種情況下，其中部分實(shí)例的故障將不會(huì)對(duì)業(yè)務(wù)造成致命的影響。

圖3 系統(tǒng)多樣性示意圖

2.1.3 冗余、多樣性的相關(guān)研究

冗余和多樣性的混合策略策略在服務(wù)功能鏈(SFC)的部署上已經(jīng)得到了廣泛應(yīng)用，Hmaity 等人[12]在服務(wù)功能鏈的冗余保護(hù)機(jī)制中提出了三種冗余保護(hù)方案，分別是：(1)端到端冗余保護(hù)；(2)虛擬節(jié)點(diǎn)冗余保護(hù)；(3)虛擬鏈路冗余保護(hù)。

除此之外，使用冗余和多樣性方法后還帶來了實(shí)例的“放置”問題。 Herker 等人[13]開發(fā)了一種服務(wù)鏈嵌入算法，該算法考慮了服務(wù)可用性約束，并比較了使用不同數(shù)據(jù)中心架構(gòu)的幾種備份策略，提供了有關(guān)如何選擇可提供高可用性的“最佳”數(shù)據(jù)中心拓?fù)涞囊娊狻?依賴VNF 備份通常會(huì)導(dǎo)致路由路徑更長(zhǎng)，從而增加了端到端延遲。 為了克服這個(gè)問題，Vizarreta 等人[14]提出了兩種 VNF 放置策略，可以在不影響可用性和端到端延遲的前提下，降低運(yùn)營(yíng)商的服務(wù)部署成本。 但是，基于可用性的放置會(huì)導(dǎo)致資源浪費(fèi)，因?yàn)閷⒂肋h(yuǎn)不會(huì)使用不滿足所需可用性閾值的資源。 就資源利用而言，這與成本效益的最初目標(biāo)相矛盾。 類似地，Qu 等人[15]提出了一種解決方案，該方案使用混合流量路由策略提供了最佳的網(wǎng)絡(luò)服務(wù)放置，同時(shí)在帶寬消耗和端到端延遲性能之間取得了平衡。

Alleg 等人提出了一種聯(lián)合選擇多樣性和定制的冗余機(jī)制[1]，以在 NFV 框架中提供韌性服務(wù)。 為求解模型，作者提出了基于混合整數(shù)線性規(guī)劃(MILP)的服務(wù)功能鏈部署解決方案，旨在滿足目標(biāo)SFC 可用性級(jí)別，同時(shí)降低由于多樣性和冗余而導(dǎo)致的固有成本，這對(duì)于增強(qiáng)微服務(wù)架構(gòu)的軟件系統(tǒng)韌性同樣具有借鑒意義。

由于大量使用冗余來保證可用性，這導(dǎo)致了微服務(wù)架構(gòu)的軟件系統(tǒng)中大部分微服務(wù)組件都是同質(zhì)的，大量共享漏洞被引入系統(tǒng)[16-17]，因此容易受到利用多微服務(wù)中相同漏洞實(shí)施的多步攻擊[18]的威脅。 針對(duì)共享漏洞問題，Kennedy 等人提出了運(yùn)用動(dòng)態(tài)目標(biāo)防御(MTD)的思想來解決問題[19]。 為了防止攻擊者利用已知目標(biāo)系統(tǒng)的漏洞，Kennedy 等人先對(duì)微服務(wù)執(zhí)行風(fēng)險(xiǎn)分析來檢測(cè)漏洞并確定其優(yōu)先級(jí)，再利用自動(dòng)代碼生成技術(shù)來轉(zhuǎn)換微服務(wù)的編程語(yǔ)言和容器鏡像，由此改變攻擊面，降低被攻擊成功的風(fēng)險(xiǎn)。

2.2 服務(wù)編排

關(guān)于編排問題的優(yōu)化解決方案，由于時(shí)間復(fù)雜度高，研究人員已經(jīng)證實(shí)，在大規(guī)模云環(huán)境中，諸如混合整數(shù)非線性規(guī)劃(MINLP)或線性規(guī)劃(MIP)等方法是不可行的[20]，遺傳算法已被廣泛用于優(yōu)化資源調(diào)度，服務(wù)編排和任務(wù)分配[21]。

早期關(guān)于服務(wù)編排機(jī)制的工作主要基于QoS感知開展。 QoS 屬性通常包括響應(yīng)時(shí)間、可用性、可靠性和價(jià)格成本等，文獻(xiàn)[22]專注于基于 QoS 感知的服務(wù)組合及其在中間件中的實(shí)現(xiàn)，然而沒有定量描述帶有風(fēng)險(xiǎn)的安全目標(biāo)，并在實(shí)際的云環(huán)境中解決它們。

大規(guī)模分布式云環(huán)境的高度復(fù)雜性導(dǎo)致了大量的不確定性，而這些不確定性無法通過常規(guī)信息安全方法的可用性來建模。Wen Zhenyu 等人[23]創(chuàng)新地從安全性角度出發(fā)，針對(duì)內(nèi)部安全威脅和外部環(huán)境不確定性進(jìn)行建模，并提出了一種用于在基于云的服務(wù)組件不確定的情況下，定量測(cè)量安全級(jí)別及其可用性方面的通用方法。

傳統(tǒng)的編排機(jī)制側(cè)重于單個(gè)服務(wù)鏈的QoS 優(yōu)化，而忽略了實(shí)例間的共享和競(jìng)爭(zhēng)。 為了解決這個(gè)問題，Ding 等人[24]提出了一種基于列表調(diào)度的微服務(wù)選擇算法MSS。 該算法采用工作流模型對(duì)服務(wù)鏈進(jìn)行描述，分析實(shí)例的處理速度、網(wǎng)絡(luò)傳輸速度和任務(wù)并發(fā)程度，計(jì)算每個(gè)任務(wù)的分期限，根據(jù)分期限和其他信息，實(shí)時(shí)計(jì)算和更新每個(gè)任務(wù)的調(diào)度緊迫性。 最后，提出了基于分期限和緊迫性的兩種服務(wù)選擇策略，以完成微服務(wù)實(shí)例選擇，構(gòu)成服務(wù)鏈。

2.3 負(fù)載均衡

負(fù)載均衡是指在單臺(tái)設(shè)備處理性能不足以支撐起系統(tǒng)業(yè)務(wù)需求的情況下，利用現(xiàn)有的設(shè)備、網(wǎng)絡(luò)等資源，將多臺(tái)設(shè)備通過一個(gè)共用的服務(wù)入口連接起來組成一個(gè)服務(wù)集群，在工作時(shí)將業(yè)務(wù)按照一定的規(guī)則分配到不同的服務(wù)節(jié)點(diǎn)，整個(gè)集群共同承擔(dān)系統(tǒng)業(yè)務(wù)，從而解決了單個(gè)服務(wù)節(jié)點(diǎn)性能不足的問題。

負(fù)載均衡的方式巧妙地避免了因單臺(tái)設(shè)備性能不足而不得不購(gòu)買昂貴的高性能設(shè)備，降低了企業(yè)的部署成本。 除此之外，負(fù)載均衡的另一大優(yōu)勢(shì)是增強(qiáng)了系統(tǒng)韌性，設(shè)備故障是不可避免的，隨著使用年限的增長(zhǎng)，設(shè)備的故障概率也隨之上升，同時(shí)還有遭受非正常因素破壞帶來的風(fēng)險(xiǎn)。 由單個(gè)高性能設(shè)備構(gòu)建的系統(tǒng)在面對(duì)意外與挑戰(zhàn)時(shí)，一旦設(shè)備出現(xiàn)故障或遭到破壞， 系統(tǒng)運(yùn)行也將隨之停止，這對(duì)于關(guān)鍵系統(tǒng)而言是不可接受的。 而對(duì)使用了負(fù)載均衡技術(shù)的系統(tǒng)而言，單個(gè)設(shè)備或系統(tǒng)單個(gè)模塊的問題將無法對(duì)系統(tǒng)造成致命打擊，大大降低了系統(tǒng)停止服務(wù)的風(fēng)險(xiǎn)，因而進(jìn)一步增強(qiáng)了系統(tǒng)韌性。

2.4 資源擴(kuò)展

如圖4 所示，關(guān)于資源的動(dòng)態(tài)擴(kuò)展，主要可以分為兩類：一種是添加更多的虛擬機(jī)或容器，這被稱為水平縮放，另一種方法是向已部署的虛擬節(jié)點(diǎn)分配更多資源，這稱為垂直擴(kuò)展。

圖4 資源的水平擴(kuò)展與垂直擴(kuò)展

在實(shí)踐中，已經(jīng)有學(xué)者做了一些工作來利用容器部署微服務(wù)架構(gòu)的應(yīng)用程序。Zhou 等人[25]研究了旨在最大化部署微服務(wù)收入的微服務(wù)調(diào)度問題。Guerrero 等人[26]設(shè)計(jì)了遺傳方法來確定分配給每個(gè)微服務(wù)的資源數(shù)量，以及如何在工作負(fù)載變化時(shí)有效地?cái)U(kuò)展規(guī)模。 但是，大多數(shù)現(xiàn)有工作并未考慮容器的功能，例如以細(xì)粒度進(jìn)行動(dòng)態(tài)資源縮放，圖像分層和庫(kù)重用，這將影響資源使用效率和應(yīng)用程序部署成本。 Wan 等人[2]基于以上工作存在的問題，結(jié)合Docker 容器的功能，提出一個(gè)可伸縮的框架ADMD 和一種以分布式和增量方式工作下的次優(yōu)算法來確定容器放置和任務(wù)分配，以根據(jù)系統(tǒng)需求和狀態(tài)動(dòng)態(tài)調(diào)整分配給每個(gè)應(yīng)用程序的資源量，并最大程度降低總成本，同時(shí)化解了全局最優(yōu)帶來的NP 難題，不足之處是沒能避免共享漏洞問題，同樣存在安全隱患。 微服務(wù)架構(gòu)下的資源擴(kuò)展圖如圖5所示。

圖5 微服務(wù)架構(gòu)下的資源擴(kuò)展

2.5 遷移技術(shù)

為了進(jìn)一步保證軟件系統(tǒng)在遭受攻擊、出現(xiàn)故障或意外事故后仍然能夠按時(shí)完成所執(zhí)行的關(guān)鍵任務(wù)，需要在前述基于Docker 容器技術(shù)的微服務(wù)架構(gòu)基礎(chǔ)之上，進(jìn)一步建立一種情境認(rèn)知的服務(wù)動(dòng)態(tài)部署遷移機(jī)制。 其基本思想在于利用容器化微服務(wù)所實(shí)現(xiàn)的應(yīng)用服務(wù)不再依賴于固定的物理網(wǎng)絡(luò)和物理設(shè)備這一特點(diǎn)，使得網(wǎng)絡(luò)業(yè)務(wù)可以在不同物理設(shè)備和網(wǎng)絡(luò)之間按需進(jìn)行遷移，保證了服務(wù)的可遷移性。 由于服務(wù)運(yùn)行于虛擬化主機(jī)和網(wǎng)絡(luò)之上，避免了與具體的物理設(shè)備和物理網(wǎng)絡(luò)相關(guān)聯(lián)。

在動(dòng)態(tài)遷移技術(shù)方面，目前已經(jīng)較為成熟的遷移技術(shù) 包括 Pre-copy、Post-copy、CRIU 等 。 除 此之外，還有一些利用日志記錄和重放手段實(shí)現(xiàn)的Docker容器熱遷移[27]，但這種方法由于在容器運(yùn)行時(shí)間較長(zhǎng)的情況下宕機(jī)時(shí)間過長(zhǎng)，并未得到業(yè)界的廣泛認(rèn)同。 Carpio 等人[28]基于復(fù)制和遷移技術(shù)提出了一種用于主動(dòng)配置的線性模型，以提高服務(wù)的可靠性。實(shí)驗(yàn)結(jié)果表明，復(fù)制與遷移相結(jié)合可以提高資源利用率，而不會(huì)降低可靠性。但是，由于沒有足夠的備用資源，他們的恢復(fù)解決方案不能為每個(gè)VNF 支持多個(gè)副本故障。 Nadgowda 等人[29]也提出了一種容器遷移服務(wù)Voyager，該技術(shù)與文件系統(tǒng)、供應(yīng)商無關(guān)，可為開發(fā)人員提供一致的全系統(tǒng)遷移。

目前關(guān)于虛擬機(jī)和容器的熱遷移技術(shù)已經(jīng)比較成熟， 然而大量關(guān)于遷移技術(shù)的研究都只聚焦于單個(gè)虛擬機(jī)或容器，與之相對(duì)應(yīng)的是，張強(qiáng)針對(duì)在Kubernetes 大規(guī)模應(yīng)用的背景下 Pod 遷移問題提出了一種解決方案PodMS[30]，一種面向數(shù)據(jù)中心Kubernetes 環(huán)境的容器在線遷移機(jī)制，該機(jī)制支持Kubernetes 環(huán)境下的容器在線遷移，提供了 Pod 在線遷移的完整支持。 美中不足的是，該機(jī)制對(duì)網(wǎng)絡(luò)遷移的支持還存在不足，并且未對(duì)前文所提到的CRIU問題進(jìn)行完善和改進(jìn)。

3 存在的問題

3.1 復(fù)雜性問題

軟件系統(tǒng)的微服務(wù)化不可避免地要對(duì)傳統(tǒng)單體架構(gòu)的軟件系統(tǒng)進(jìn)行拆分，并就微服務(wù)架構(gòu)的指導(dǎo)思想和目前的企業(yè)實(shí)踐而言，應(yīng)用的服務(wù)功能拆分得越細(xì)越好，在享受組件模塊化優(yōu)勢(shì)的同時(shí)，也不可避免地導(dǎo)致了系統(tǒng)的進(jìn)一步復(fù)雜化，引入了大量復(fù)雜性問題。

3.1.1 故障檢測(cè)復(fù)雜性

盡管微服務(wù)架構(gòu)下系統(tǒng)具備一定的容錯(cuò)能力，但在發(fā)生故障之后必須及時(shí)發(fā)現(xiàn)并采取相應(yīng)的手段進(jìn)行恢復(fù)。 在一個(gè)大型微服務(wù)架構(gòu)的軟件系統(tǒng)中，系統(tǒng)由大量的微服務(wù)構(gòu)成，由于服務(wù)隨時(shí)可能發(fā)生故障，因此能否快速實(shí)現(xiàn)故障檢測(cè)顯得至關(guān)重要。 但由于系統(tǒng)微服務(wù)化，軟件的大量組件與設(shè)備都成為了需要監(jiān)視的對(duì)象，這將使得監(jiān)視系統(tǒng)的構(gòu)建與監(jiān)視數(shù)據(jù)的存儲(chǔ)、調(diào)用、組織成為了一件復(fù)雜的事情。

對(duì)于這一問題，應(yīng)當(dāng)基于微服務(wù)基礎(chǔ)架構(gòu)平臺(tái)建立完善的監(jiān)視系統(tǒng)，不僅包括對(duì)硬件設(shè)備的監(jiān)視，同時(shí)更應(yīng)著重于對(duì)應(yīng)用程序各組件、正在運(yùn)行的各項(xiàng)業(yè)務(wù)的監(jiān)控，完善的監(jiān)視系統(tǒng)可以為發(fā)生錯(cuò)誤的情況提供預(yù)警系統(tǒng)，從而觸發(fā)自動(dòng)恢復(fù)機(jī)制，同時(shí)也有利于開發(fā)團(tuán)隊(duì)進(jìn)行跟進(jìn)和調(diào)查。

3.1.2 模塊通信復(fù)雜性

當(dāng)軟件系統(tǒng)的組件具有遠(yuǎn)程通信的服務(wù)功能時(shí)，無論在系統(tǒng)重構(gòu)上還是調(diào)用組織上都將比單體架構(gòu)困難得多。 簡(jiǎn)單來說，微服務(wù)化軟件系統(tǒng)中各個(gè)組件的停機(jī)都將直接影響整個(gè)服務(wù)鏈上的業(yè)務(wù)運(yùn)行，進(jìn)而影響整個(gè)系統(tǒng)的業(yè)務(wù)執(zhí)行，這也是開發(fā)者不得不考慮的問題。

針對(duì)這一問題，開發(fā)者應(yīng)當(dāng)基于統(tǒng)一的開發(fā)與編排平臺(tái)，利用通用接口進(jìn)行開發(fā)，以避免在調(diào)用時(shí)因接口不統(tǒng)一引發(fā)的業(yè)務(wù)邏輯問題。

3.1.3 遷移復(fù)雜性

傳統(tǒng)的遷移只需要考慮對(duì)單個(gè)虛擬機(jī)(或容器)進(jìn)行遷移，在運(yùn)行中的業(yè)務(wù)系統(tǒng)面言，則需要考慮盡可能減小遷移所帶來的影響，如造成停機(jī)則需要盡可能地縮短停機(jī)時(shí)間。 而在微服務(wù)架構(gòu)系統(tǒng)中則需要考慮一次性遷移數(shù)個(gè)容器，并且還需要配合底層平臺(tái)進(jìn)行相應(yīng)的修改，即遷移對(duì)象將不再是簡(jiǎn)單的單個(gè)容器，而是封裝在一個(gè)組件中的若干容器。當(dāng)前容器遷移已經(jīng)是相對(duì)比較成熟的技術(shù)，并且已有例如CRIU 等相對(duì)成熟的技術(shù)， 該問題最直接的解決方式，是在已有的技術(shù)和容器編排與管理平臺(tái)的條件下，進(jìn)行適應(yīng)性開發(fā)，形成一套新的成熟的遷移機(jī)制。

3.2 兼容性問題

3.2.1 底層操作系統(tǒng)不兼容

構(gòu)建微服務(wù)架構(gòu)的軟件系統(tǒng)最簡(jiǎn)單的方式是基于成熟容器的編排與管理平臺(tái)，如Swarm、Mesos和Kubernetes 等，但這些平臺(tái)在部署時(shí)都必須要求底層設(shè)備使用相同的操作系統(tǒng)，這對(duì)于實(shí)現(xiàn)系統(tǒng)多樣性指標(biāo)將成為一種阻礙，從而無法充分利用多樣性實(shí)現(xiàn)更加高層次的系統(tǒng)韌性。

3.2.2 容器不兼容

除了操作系統(tǒng)之外，容器多樣性的實(shí)現(xiàn)也存在相同的問題，基于不同容器的成熟管理平臺(tái)還未出現(xiàn)，基于容器的編排與管理平臺(tái)進(jìn)行實(shí)現(xiàn)就必須使用同一種容器技術(shù)，在這種情況下系統(tǒng)多樣性將無法得到進(jìn)一步拓展。

兼容性問題的解決不是靠個(gè)別研究人員的努力就能實(shí)現(xiàn)的，這需要開發(fā)者、運(yùn)營(yíng)商、標(biāo)準(zhǔn)制定組織共同的努力。 對(duì)于研究人員而言，應(yīng)當(dāng)盡可能地基于統(tǒng)一的標(biāo)準(zhǔn)進(jìn)行開發(fā)，從而獲得彼此之間相互兼容的技術(shù)產(chǎn)品。

3.3 資源優(yōu)化問題

運(yùn)用冗余和多樣性的目的在于應(yīng)對(duì)系統(tǒng)部分組件可能出現(xiàn)的故障與風(fēng)險(xiǎn)，但同時(shí)也將不得不導(dǎo)致資源的浪費(fèi)問題。 組件的故障只是個(gè)概率問題，因此在各組件正常運(yùn)行的大量時(shí)間內(nèi)，出于冗余和多樣性目標(biāo)所消耗的大量資源都造成嚴(yán)重的浪費(fèi)。過多的資源用于冗余和多樣性可能導(dǎo)致部分資源將一直處于閑置狀態(tài)，而用于冗余和多樣性的資源不足則有可能導(dǎo)致無法起到保護(hù)作用或系統(tǒng)韌性無法滿足要求。

資源優(yōu)化問題的解決，一方面需要兼顧資源優(yōu)化和韌性增強(qiáng)兩個(gè)方面，使得恰好能夠滿足系統(tǒng)韌性指標(biāo)，同時(shí)最小化資源消耗。另一方面，進(jìn)一步增強(qiáng)軟件的可靠性與穩(wěn)定性，使得軟件系統(tǒng)需要的冗余度進(jìn)一步降低，而達(dá)到資源友好的目標(biāo)。除此之外，更好地將冗余和多樣性結(jié)合起來也是解決問題的關(guān)鍵。

3.4 安全性問題

3.4.1 容器安全問題

盡管容器的輕量級(jí)特性使得其在物理機(jī)上可以更大規(guī)模地部署，從而提供更高的性能，但是和基于 Hypervisor 的虛擬化相比， 研究人員普遍認(rèn)為后者比容器技術(shù)更為安全[31]。原因在于基于Hypervisor的虛擬化下每一個(gè)VM 都帶有自身的內(nèi)核，運(yùn)行在VM 上的 APP 只需與 VM 內(nèi)核通信即可，隔離了主機(jī)內(nèi)核，如圖 6 所示。 而 Docker 之上的 APP 則可以直接與主機(jī)內(nèi)核進(jìn)行通信，相比前者更容易遭到攻擊。 在以“特權(quán)”身份運(yùn)行容器時(shí)，Docker 會(huì)授予用戶對(duì)該容器的最高權(quán)限，這與在主機(jī)上本地運(yùn)行的進(jìn)程的訪問權(quán)限幾乎相同。

圖6 Docker 容器和虛擬機(jī)對(duì)比圖

容器逃逸問題也是研究人員最關(guān)心的問題之一， 內(nèi)核漏洞是對(duì)操作系統(tǒng)安全性的巨大挑戰(zhàn)，盡管Docker 擁有許多用于自身安全性的設(shè)計(jì)和策略，但是其共享內(nèi)核的體系結(jié)構(gòu)模型使一些外部安全性問題擴(kuò)展到了容器中[32]。 Docker 面臨著被惡意用戶利用內(nèi)核漏洞進(jìn)行攻擊的風(fēng)險(xiǎn)，一旦容器中的漏洞利用程序啟動(dòng)有效的逃逸攻擊，就可以獲得主機(jī)的根特權(quán)，將影響其他容器和整個(gè)系統(tǒng)的可靠性。

3.4.2 服務(wù)安全問題

由于微服務(wù)框架下軟件系統(tǒng)由大量微服務(wù)組成，微服務(wù)之間可以根據(jù)標(biāo)識(shí)對(duì)其他微服務(wù)進(jìn)行調(diào)用，因此不得不考慮其中某一項(xiàng)微服務(wù)可能會(huì)被非法調(diào)用，即便不發(fā)生這樣的情況，在系統(tǒng)部分微服務(wù)進(jìn)行獨(dú)立升級(jí)時(shí)，其中部分組件的更改也可能會(huì)破壞其他微服務(wù)。 開發(fā)者需要通過合理的設(shè)計(jì)以盡可能地容忍軟件系統(tǒng)中的變更，避免使用過多的版本控制。

4 發(fā)展趨勢(shì)

當(dāng)前，微服務(wù)正處于發(fā)展階段，專門將微服務(wù)用于軟件系統(tǒng)韌性增強(qiáng)領(lǐng)域的研究更是處于探索階段，因此未來的發(fā)展很大程度上將考慮進(jìn)一步挖掘微服務(wù)架構(gòu)可用于增強(qiáng)系統(tǒng)韌性方面的特性，本節(jié)將就下一步可能的發(fā)展方向進(jìn)行展望。

一是在考慮冗余和多樣性的同時(shí)盡可能地減少資源消耗。 當(dāng)前的主要趨勢(shì)是優(yōu)化改進(jìn)調(diào)度策略以實(shí)現(xiàn)更優(yōu)的資源動(dòng)態(tài)擴(kuò)展，從而縮小冗余和多樣性的規(guī)模，減輕系統(tǒng)在資源消耗上的負(fù)擔(dān)，從而在增強(qiáng)韌性的同時(shí)，盡可能地縮減開支。

二是增強(qiáng)兼容性，包括下層操作系統(tǒng)的兼容和對(duì)多種容器技術(shù)的兼容。 這對(duì)容器編排與管理平臺(tái)提出了更高的要求，這一問題的解決將使得微服務(wù)架構(gòu)下軟件系統(tǒng)的靈活性進(jìn)一步得到釋放，既有利于多樣性的發(fā)揮，又能使得部署更為輕松。

三是盡可能解決現(xiàn)存在的安全問題，包括容器的安全問題和微服務(wù)框架下服務(wù)的安全問題。 其中Docker 容器的問題又需要從守護(hù)進(jìn)程(Docker Deamon)、容器鏡像、容器網(wǎng)絡(luò)等多角度入手解決。如可以通過將容器放置在虛擬機(jī)內(nèi)部來實(shí)現(xiàn)等方法。 針對(duì)可能的攻擊，可以在保持容器輕量級(jí)優(yōu)點(diǎn)的同時(shí)減小攻擊面，如引入攻擊面轉(zhuǎn)換技術(shù)。

四是更加完善的動(dòng)態(tài)遷移技術(shù)。 在研究遷移策略時(shí)，還需要考慮以下幾個(gè)原則：(1)需要帶狀態(tài)遷移，即熱遷移，以保證遷移完成后服務(wù)得以延續(xù)；(2)遷移帶來的停機(jī)時(shí)間需盡可能短，讓用戶感覺不到有什么明顯的變化；(3)遷移目的需是負(fù)載較輕的節(jié)點(diǎn)，以免帶來新的過載問題?；谝陨显瓌t，研究的方向在容器遷移、虛擬機(jī)遷移的基礎(chǔ)上，進(jìn)一步對(duì)微服務(wù)架構(gòu)下的服務(wù)遷移問題進(jìn)行研究。

5 結(jié)論

本文深入探討了軟件系統(tǒng)的韌性增強(qiáng)問題，針對(duì)微服務(wù)架構(gòu)松散耦合、獨(dú)立自治的重要特性進(jìn)行分析，并結(jié)合當(dāng)前生產(chǎn)實(shí)踐中使用的技術(shù)手段，根據(jù)當(dāng)前研究現(xiàn)狀總結(jié)了可在微服務(wù)架構(gòu)下用于增強(qiáng)系統(tǒng)韌性的相關(guān)技術(shù)手段，包括：冗余與多樣性、負(fù)載均衡、資源擴(kuò)展、遷移技術(shù)以及容器編排與管理技術(shù)。

由于微服務(wù)架構(gòu)剛剛提出不久，該領(lǐng)域內(nèi)尚存在一些關(guān)鍵問題未能得到解決，主要包括復(fù)雜性問題、兼容性問題、資源優(yōu)化問題和安全性問題，這些問題的存在制約著微服務(wù)架構(gòu)下軟件系統(tǒng)的韌性增強(qiáng)問題的進(jìn)一步解決。

由于當(dāng)前網(wǎng)絡(luò)攻擊成本的不斷下降，這使得如何增強(qiáng)軟件系統(tǒng)韌性更加具有重要意義。 因此，針對(duì)韌性增強(qiáng)需要解決的問題，結(jié)合當(dāng)前理論與實(shí)踐，本文提出一套完善的軟件系統(tǒng)韌性增強(qiáng)方法，對(duì)于保證關(guān)鍵業(yè)務(wù)的連續(xù)性，進(jìn)而保證軟件系統(tǒng)使命任務(wù)的完成，具有一定的意義。