服務(wù)網(wǎng)格中的級(jí)聯(lián)故障預(yù)測(cè)方法

李海飛 徐政鈞

(北京郵電大學(xué) 北京100876)

0 引 言

近年來微服務(wù)架構(gòu)發(fā)展迅猛，逐步成為主流部署模型。相對(duì)于單體架構(gòu)而言，微服務(wù)架構(gòu)有著明顯的優(yōu)勢(shì)，單體架構(gòu)龐大笨重，持續(xù)開發(fā)非常復(fù)雜[1]，可擴(kuò)展性差。微服務(wù)的誕生正好彌補(bǔ)了這一缺陷，微服務(wù)架構(gòu)將一個(gè)應(yīng)用拆分成多個(gè)微服務(wù)，每個(gè)微服務(wù)獨(dú)立開發(fā)、獨(dú)立部署、自由擴(kuò)展，實(shí)現(xiàn)了開發(fā)和部署的敏捷性和靈活性[2]。但是隨著人們對(duì)微服務(wù)系統(tǒng)的需求日益增加，對(duì)微服務(wù)架構(gòu)的要求也逐漸增高，不僅要求微服務(wù)平臺(tái)滿足服務(wù)隔離及彈性伸縮等靈活性需求，還要求微服務(wù)平臺(tái)保證高度的可靠性及可用性[3]。為此，就要盡可能避免系統(tǒng)故障發(fā)生，尤其是大規(guī)模系統(tǒng)故障。

為了實(shí)現(xiàn)更好的彈性伸縮及負(fù)載均衡，微服務(wù)架構(gòu)將應(yīng)用細(xì)分為多個(gè)微服務(wù)，且每個(gè)微服務(wù)可以部署多個(gè)實(shí)例，微服務(wù)間通過網(wǎng)絡(luò)層相互通信，實(shí)現(xiàn)良好的性能隔離，同時(shí)也實(shí)現(xiàn)了故障隔離，這意味著微服務(wù)可以被設(shè)置為單獨(dú)失敗[4]。但并不表示微服務(wù)間不存在干擾。當(dāng)系統(tǒng)達(dá)到一定規(guī)模時(shí)，微服務(wù)的數(shù)量變得相當(dāng)龐大，微服務(wù)間或因?yàn)榫W(wǎng)絡(luò)通信或因?yàn)橘Y源共享聯(lián)系在一起，形成一個(gè)復(fù)雜的關(guān)系網(wǎng)，這個(gè)網(wǎng)絡(luò)中有一個(gè)節(jié)點(diǎn)出現(xiàn)問題，就會(huì)級(jí)聯(lián)到其他節(jié)點(diǎn)，造成連鎖反應(yīng)，甚至可能發(fā)生雪崩，造成整個(gè)系統(tǒng)癱瘓[5-6]。

針對(duì)上述問題，本文提出了一套級(jí)聯(lián)故障預(yù)測(cè)方法。基于當(dāng)下具有很高研究熱度的服務(wù)網(wǎng)格系統(tǒng)，本文在服務(wù)網(wǎng)格邊緣嵌入故障預(yù)測(cè)組件，對(duì)系統(tǒng)進(jìn)行實(shí)時(shí)監(jiān)測(cè)[7-8]。每當(dāng)有大量微服務(wù)負(fù)載進(jìn)入系統(tǒng)時(shí)，組件被喚醒，依據(jù)當(dāng)前微服務(wù)間的調(diào)用關(guān)系和資源依賴關(guān)系，建立模型，利用GRU神經(jīng)網(wǎng)絡(luò)[9-11]進(jìn)行故障概率預(yù)測(cè)。

1 相關(guān)工作

隨著云服務(wù)市場(chǎng)的發(fā)展，微服務(wù)架構(gòu)勢(shì)頭更盛，國內(nèi)外包括AWS(亞馬遜)、Azure(微軟)、阿里云、騰訊云、百度云、華為云等都紛紛投入服務(wù)網(wǎng)格的應(yīng)用研究中。學(xué)術(shù)界也發(fā)表了一些關(guān)于微服務(wù)故障研究的文章，但針對(duì)服務(wù)網(wǎng)格的相對(duì)較少，更多的是關(guān)于分布式系統(tǒng)、云環(huán)境及Web服務(wù)中的故障研究。

文獻(xiàn)[12]提出了一種自適應(yīng)的基于多因素的心跳檢測(cè)算法，用以進(jìn)行微服務(wù)故障診斷。它結(jié)合了分布式系統(tǒng)中的心跳檢測(cè)機(jī)制和微服務(wù)的特征，采用了三因素拉模式心跳檢測(cè)機(jī)制。心跳檢測(cè)是分布式系統(tǒng)經(jīng)常采用的一種服務(wù)健康監(jiān)控機(jī)制，它通過服務(wù)的心跳確認(rèn)服務(wù)是否良好可運(yùn)行。文獻(xiàn)[13]提出了基于日志檢測(cè)的分布式服務(wù)異常診斷模型，并提出了一種基于混合圖模型的對(duì)數(shù)異常檢測(cè)算法。該模型捕獲服務(wù)的正常執(zhí)行流程，然后觀察與混合模型的偏差，由此觸發(fā)異常警報(bào)。文獻(xiàn)[14]提出了一個(gè)針對(duì)大規(guī)模時(shí)間序列異常進(jìn)行自動(dòng)檢測(cè)的通用可擴(kuò)展框架，模擬時(shí)間序列的正常行為，把與模型存在顯著偏差的節(jié)點(diǎn)作為異常處理。文獻(xiàn)[13-14]提出的方法都是基于單個(gè)服務(wù)進(jìn)行監(jiān)控并告警，忽略了服務(wù)間的關(guān)聯(lián)性。

文獻(xiàn)[15]提出了一種云環(huán)境中的故障轉(zhuǎn)移方法，并提出了一種表示容錯(cuò)模型的數(shù)學(xué)關(guān)系。該模型依據(jù)每個(gè)虛擬節(jié)點(diǎn)的服務(wù)請(qǐng)求通過率指定容錯(cuò)方案。面向節(jié)點(diǎn)進(jìn)行故障診斷可以作為分析故障的一個(gè)方面，但就微服務(wù)來說，還遠(yuǎn)遠(yuǎn)不夠，還需要以服務(wù)為單位進(jìn)行排查。文獻(xiàn)[16]提出了一種基于系統(tǒng)參數(shù)搜索的在線檢測(cè)模型，可以對(duì)向量機(jī)的參數(shù)進(jìn)行優(yōu)化。它通過皮爾森相關(guān)系數(shù)和主成分分析進(jìn)行云系統(tǒng)數(shù)據(jù)提取來做出故障預(yù)測(cè)。文獻(xiàn)[17]提出了一個(gè)分布式系統(tǒng)的數(shù)據(jù)跟蹤監(jiān)控框架，它克服了數(shù)據(jù)預(yù)先定義的限制，將系統(tǒng)當(dāng)前操作與動(dòng)態(tài)工具結(jié)合，使用戶能夠在系統(tǒng)運(yùn)行時(shí)的某一節(jié)點(diǎn)定義任何度量標(biāo)準(zhǔn)，同時(shí)還可以根據(jù)系統(tǒng)中的重要事件進(jìn)行數(shù)據(jù)過濾和分組。

以上文獻(xiàn)中的方法都適用于分布式系統(tǒng)，主要基于單個(gè)服務(wù)或單個(gè)節(jié)點(diǎn)展開。而服務(wù)網(wǎng)格中的級(jí)聯(lián)故障更多取決于服務(wù)間的依賴關(guān)系。

2 系統(tǒng)設(shè)計(jì)

2.1 系統(tǒng)架構(gòu)

Web服務(wù)規(guī)模不斷擴(kuò)大，促使單體應(yīng)用架構(gòu)向分布式微服務(wù)架構(gòu)轉(zhuǎn)化。但傳統(tǒng)的分布式架構(gòu)應(yīng)用模塊多且復(fù)雜，使得系統(tǒng)在進(jìn)行資源分配、部署、管理等方面面臨著巨大的重復(fù)性工作[18]。而容器化的出現(xiàn)有效地解決了以上提出的問題。本文采用的Docker+ Kubernetes+ Istio的服務(wù)網(wǎng)格部署模式，實(shí)現(xiàn)了容器的自動(dòng)化部署、高度的可擴(kuò)展性及更高的安全性。Docker實(shí)現(xiàn)了輕量級(jí)的操作系統(tǒng)虛擬化解決方案，克服了硬件層面虛擬的諸多弊端。它通過鏡像封裝容器啟動(dòng)代碼，以及應(yīng)用運(yùn)行的環(huán)境和依賴，可以快速地實(shí)現(xiàn)應(yīng)用的部署和遷移，同時(shí)為應(yīng)用提供了一個(gè)一致的運(yùn)行環(huán)境。Kubernetes是一個(gè)容器集群的自動(dòng)化部署、運(yùn)維平臺(tái)，針對(duì)Docker實(shí)現(xiàn)了更靈活的容器編排調(diào)度。它通過組件間的協(xié)同配合，實(shí)現(xiàn)更精準(zhǔn)的服務(wù)部署、更有效的資源分配和更便捷的更新迭代。Istio是一個(gè)服務(wù)網(wǎng)格架構(gòu)，它類似一個(gè)網(wǎng)絡(luò)代理，是微服務(wù)外層的一個(gè)基礎(chǔ)設(shè)施層，控制著微服務(wù)間的通信，并具備負(fù)載均衡、服務(wù)認(rèn)證和監(jiān)控等功能?？梢酝ㄟ^Istio配置各種流量規(guī)則和安全策略，無須改動(dòng)應(yīng)用代碼。

圖1所示為本文的系統(tǒng)架構(gòu)，在服務(wù)網(wǎng)格架構(gòu)基礎(chǔ)上嵌入了級(jí)聯(lián)故障預(yù)測(cè)組件。每次部署一個(gè)微服務(wù)實(shí)例，都會(huì)相應(yīng)啟動(dòng)一個(gè)代理，微服務(wù)間通過代理相互通信，它們與外界的所有交互也都由代理執(zhí)行。如此即可在不需要修改應(yīng)用代碼的條件下，獲取微服務(wù)的相關(guān)信息，并對(duì)微服務(wù)進(jìn)行管理配置。Mixer是微服務(wù)與系統(tǒng)交互的接口，它通過代理收集微服務(wù)遙測(cè)數(shù)據(jù)，并對(duì)微服務(wù)請(qǐng)求進(jìn)行策略檢查。所有的流量策略、安全策略、故障恢復(fù)策略，以及監(jiān)控策略等都寫在控制平面中，控制平面會(huì)將我們的策略解析為特定的配置文件，以便代理進(jìn)行解讀。本文方法形成一個(gè)級(jí)聯(lián)故障預(yù)測(cè)組件，它位于Mixer與控制平面之間，從Mixer獲取信息進(jìn)行分析預(yù)測(cè)，并將結(jié)果以策略文件的形式傳遞給控制平面。

圖1 系統(tǒng)架構(gòu)

2.2 系統(tǒng)工作流程

級(jí)聯(lián)故障發(fā)生在系統(tǒng)高負(fù)載運(yùn)行狀態(tài)下，系統(tǒng)接收到微服務(wù)請(qǐng)求后，Mixer按照負(fù)載策略將請(qǐng)求分發(fā)給各個(gè)代理，此時(shí)Mixer只能確定每個(gè)代理所代表的服務(wù)是否可訪問，但不能確定主機(jī)狀態(tài)和相關(guān)聯(lián)的微服務(wù)狀態(tài)。當(dāng)主機(jī)資源接近瓶頸，而Mixer在無法感知的情況下，會(huì)繼續(xù)對(duì)微服務(wù)發(fā)出訪問請(qǐng)求。此時(shí)節(jié)點(diǎn)一方面資源負(fù)載過高，可能出現(xiàn)微服務(wù)處理不及時(shí)，另一方面又會(huì)面臨新的微服務(wù)請(qǐng)求，如此就會(huì)發(fā)生級(jí)聯(lián)故障。

級(jí)聯(lián)故障預(yù)測(cè)組件嵌入后，作為一個(gè)獨(dú)立的組件，與Mixer等其他組件一樣，以容器的形式部署在平臺(tái)中。它并不會(huì)一直運(yùn)行，它會(huì)委派Mixer在系統(tǒng)迎來高負(fù)載時(shí)，喚醒該組件，并且將相關(guān)微服務(wù)信息傳遞給它。級(jí)聯(lián)故障預(yù)測(cè)組件對(duì)得到的微服務(wù)信息進(jìn)行處理計(jì)算，獲得針對(duì)特定微服務(wù)的級(jí)聯(lián)故障發(fā)生概率，并形成一定的規(guī)避策略，傳遞給控制平面?？刂破矫鎸?duì)用戶策略進(jìn)行解析，形成特定配置文件，進(jìn)而轉(zhuǎn)由Mixer傳達(dá)給代理執(zhí)行，這樣就規(guī)避了造成級(jí)聯(lián)故障風(fēng)險(xiǎn)的微服務(wù)調(diào)用。

3 級(jí)聯(lián)故障預(yù)測(cè)方法

3.1 級(jí)聯(lián)故障預(yù)測(cè)模型

微服務(wù)系統(tǒng)將單個(gè)應(yīng)用拆分成多個(gè)微服務(wù)，運(yùn)行在不同容器中，并依據(jù)需求為同一微服務(wù)啟動(dòng)多個(gè)容器，并將其綁定到不同節(jié)點(diǎn)來實(shí)現(xiàn)系統(tǒng)的高并發(fā)和負(fù)載均衡，使微服務(wù)系統(tǒng)能夠應(yīng)對(duì)大量訪問請(qǐng)求，同時(shí)也增加了系統(tǒng)復(fù)雜性。不同節(jié)點(diǎn)間微服務(wù)的通信及同一節(jié)點(diǎn)上微服務(wù)的交互增加，也使得級(jí)聯(lián)故障概率大大增強(qiáng)[19]。為了使微服務(wù)系統(tǒng)能夠?qū)?jí)聯(lián)故障做出及時(shí)響應(yīng)，本文從微服務(wù)運(yùn)行狀況和資源依賴的角度出發(fā)，設(shè)計(jì)了一套級(jí)聯(lián)故障預(yù)測(cè)方法[20]。

如圖2所示，首先構(gòu)建微服務(wù)調(diào)用樹，調(diào)用樹存儲(chǔ)著微服務(wù)間的調(diào)用關(guān)系和微服務(wù)執(zhí)行的時(shí)序關(guān)系，據(jù)此可以定位到一定時(shí)間段內(nèi)正在或?qū)⒁獔?zhí)行的微服務(wù)[21-22]，這些微服務(wù)是接下來進(jìn)行服務(wù)健康度及負(fù)載計(jì)算的對(duì)象。

圖2 級(jí)聯(lián)故障預(yù)測(cè)模型

當(dāng)系統(tǒng)產(chǎn)生大量服務(wù)請(qǐng)求時(shí)，會(huì)觸發(fā)微服務(wù)健康度計(jì)算模塊和微服務(wù)負(fù)載計(jì)算模塊，這兩個(gè)模塊會(huì)向調(diào)用樹模塊申請(qǐng)獲取當(dāng)前啟動(dòng)的微服務(wù)及預(yù)設(shè)時(shí)間段內(nèi)將會(huì)啟動(dòng)的微服務(wù)。微服務(wù)健康度通過微服務(wù)的服務(wù)特性和節(jié)點(diǎn)資源特性計(jì)算每一個(gè)微服務(wù)針對(duì)每一屬性的健康度，以及該屬性的健康標(biāo)準(zhǔn)。微服務(wù)負(fù)載計(jì)算模塊會(huì)根據(jù)每一個(gè)節(jié)點(diǎn)每一項(xiàng)資源的初始負(fù)載計(jì)算該資源的最大負(fù)載，依據(jù)鄰居節(jié)點(diǎn)計(jì)算該節(jié)點(diǎn)的額外負(fù)載，并計(jì)算負(fù)載代價(jià)。以上獲取的數(shù)據(jù)包括微服務(wù)健康度、健康標(biāo)準(zhǔn)、節(jié)點(diǎn)最大負(fù)載、額外負(fù)載和負(fù)載成本，還有實(shí)時(shí)微服務(wù)相關(guān)屬性將作為神經(jīng)網(wǎng)絡(luò)模型的輸入，用以訓(xùn)練并計(jì)算獲得級(jí)聯(lián)故障概率。

3.2 構(gòu)建調(diào)用樹

微服務(wù)系統(tǒng)中的每個(gè)請(qǐng)求是由多個(gè)微服務(wù)協(xié)同完成的，微服務(wù)間的相互調(diào)用形成了一個(gè)微服務(wù)請(qǐng)求的執(zhí)行軌跡[23]，我們將此執(zhí)行軌跡構(gòu)建為一個(gè)微服務(wù)調(diào)用樹，如圖3所示。調(diào)用樹中每個(gè)節(jié)點(diǎn)代表一個(gè)微服務(wù)，有向邊表示一個(gè)服務(wù)調(diào)用過程，虛線框代表一個(gè)節(jié)點(diǎn)，虛線有向邊表示跨節(jié)點(diǎn)的調(diào)用。調(diào)用樹記錄并跟蹤微服務(wù)調(diào)用路徑，以確認(rèn)實(shí)時(shí)微服務(wù)的映射。

圖3 微服務(wù)調(diào)用樹

對(duì)于同一個(gè)節(jié)點(diǎn)上的微服務(wù)，可以依據(jù)系統(tǒng)時(shí)鐘確認(rèn)執(zhí)行的先后順序。但是不同節(jié)點(diǎn)間由于網(wǎng)絡(luò)不穩(wěn)定等因素的影響很難實(shí)現(xiàn)時(shí)鐘的完全同步。因此本文提出在每個(gè)服務(wù)請(qǐng)求中插入一段監(jiān)控代碼，并為每個(gè)微服務(wù)生成兩個(gè)標(biāo)識(shí)信息元組，以此確定調(diào)用順序：

Mt={requestID,methodID,callID,info}

info={callType,order,duration}

系統(tǒng)每接收一個(gè)業(yè)務(wù)請(qǐng)求，都會(huì)為該請(qǐng)求生成一個(gè)唯一標(biāo)識(shí)符requestID。每一次微服務(wù)調(diào)用過程中，主調(diào)微服務(wù)都會(huì)將該requestID傳遞給被調(diào)微服務(wù)，被調(diào)微服務(wù)解析該字段以確定當(dāng)前調(diào)用歸屬哪一個(gè)業(yè)務(wù)請(qǐng)求。methodID是微服務(wù)標(biāo)識(shí)符，它用于標(biāo)記微服務(wù)本身之外，還會(huì)傳遞給被調(diào)微服務(wù)，并作為被調(diào)微服務(wù)的callID存儲(chǔ)，如此一來就確認(rèn)微服務(wù)間的調(diào)用關(guān)系。callType用于表示微服務(wù)調(diào)用類別，包括計(jì)算密集型，內(nèi)存敏感型和高存儲(chǔ)需求型。order字段繼承自主調(diào)微服務(wù)，并在主調(diào)微服務(wù)的基礎(chǔ)上依次遞增。duration字段記錄了兩次調(diào)用請(qǐng)求間的時(shí)間成本。

每一個(gè)微服務(wù)都使用本地請(qǐng)求作為根節(jié)點(diǎn)，依據(jù)methodID和callID依次匹配，構(gòu)造調(diào)用子樹，并依據(jù)order和duration確定調(diào)用順序。然后對(duì)具有相同requestID的子樹進(jìn)行聚合，并根據(jù)自上而下的寬度優(yōu)先級(jí)原理合并成完整的調(diào)用樹。其算法過程如算法1所示。

算法1構(gòu)建調(diào)用樹

輸入：Mt={requestID,methodID,callID,info}，info={callType,order,duration}。

輸出:微服務(wù)調(diào)用樹。

1.foreachMtandinfodo

2.ifrequestID相同then

3.將requestID的微服務(wù)劃分到同一組

4.endif

5.endfor

6.for每組微服務(wù)do

7.依據(jù)methodID和callID構(gòu)建調(diào)用子樹；

8.依據(jù)和確定調(diào)用順序；

9.子樹聚合形成調(diào)用樹

10.endfor

11.return微服務(wù)調(diào)用樹

3.3 微服務(wù)健康度計(jì)算

(1)

(2)

算法2微服務(wù)健康度計(jì)算

輸入：微服務(wù)調(diào)用樹，Ai，GCj。

1.遍歷調(diào)用樹定位目標(biāo)微服務(wù)

2.for每組微服務(wù)do

6.endfor

3.4 微服務(wù)負(fù)載及負(fù)載成本計(jì)算

微服務(wù)間除了相互調(diào)用之外，還有一個(gè)關(guān)鍵聯(lián)系——資源爭(zhēng)用。部署在同一節(jié)點(diǎn)上的微服務(wù)共享節(jié)點(diǎn)資源，那么就不可避免資源爭(zhēng)用。微服務(wù)系統(tǒng)的級(jí)聯(lián)故障起源于微服務(wù)的依賴關(guān)系，但微服務(wù)系統(tǒng)具有良好的隔離性，能夠?qū)崿F(xiàn)獨(dú)立失敗，因而由于調(diào)用關(guān)系而引起的級(jí)聯(lián)故障比重較小，特別是在高負(fù)載的狀態(tài)下，資源瓶頸顯得尤為突出。由于網(wǎng)絡(luò)延遲，CPU忙碌，內(nèi)存高負(fù)荷或遠(yuǎn)程調(diào)用無響應(yīng)等原因，微服務(wù)可能陷入長時(shí)間等待狀態(tài)，這在一般系統(tǒng)中可能不會(huì)造成大的危害，但是微服務(wù)系統(tǒng)服務(wù)體量太大，且存在故障重啟機(jī)制，大量甚至越來越多的微服務(wù)運(yùn)行并占用資源，進(jìn)一步加大系統(tǒng)壓力，進(jìn)而極易引發(fā)級(jí)聯(lián)故障。

對(duì)于級(jí)聯(lián)故障的預(yù)測(cè)不能局限于單純的微服務(wù)性能監(jiān)控或者心跳檢測(cè)等機(jī)制，應(yīng)該從資源方向入手。因此，本文提出了一種資源負(fù)載計(jì)算策略對(duì)微服務(wù)狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)控。假設(shè)節(jié)點(diǎn)i上資源j的初始負(fù)載為Lij，當(dāng)大量微服務(wù)請(qǐng)求涌入時(shí)，與節(jié)點(diǎn)i部署了相同微服務(wù)實(shí)例的節(jié)點(diǎn)，或者可以為節(jié)點(diǎn)i分擔(dān)負(fù)載壓力，或者可以成為節(jié)點(diǎn)i的負(fù)載來源，這樣的節(jié)點(diǎn)我們稱之為鄰居節(jié)點(diǎn)。在鄰居節(jié)點(diǎn)的作用下，可以計(jì)算一下每個(gè)節(jié)點(diǎn)的額外負(fù)載ΔLij，計(jì)算公式如下：

(3)

式中：N代表節(jié)點(diǎn)i的鄰居節(jié)點(diǎn)個(gè)數(shù);Cij代表節(jié)點(diǎn)i上資源j的最大負(fù)載。節(jié)點(diǎn)的最大負(fù)載同樣受鄰居節(jié)點(diǎn)影響，因而最大負(fù)載Cij的計(jì)算公式如下：

(4)

式中：α和β是兩個(gè)容差參數(shù)；Lijmin是鄰居節(jié)點(diǎn)中最低的初始負(fù)載。而為：

(5)

節(jié)點(diǎn)資源是有限的，因而存在一個(gè)關(guān)系：Lij+ΔLij

另一方面，如果不考慮代價(jià)，節(jié)點(diǎn)資源容量不受限制，那么可以說級(jí)聯(lián)故障完全可以避免。但是節(jié)點(diǎn)資源不能無限擴(kuò)張，其中要花費(fèi)的代價(jià)是需要考慮的問題。代價(jià)來源于節(jié)點(diǎn)資源負(fù)載，并受鄰居節(jié)點(diǎn)影響。本文把Cij重新表示為Cij=λijLij，把資源i的負(fù)載代價(jià)定義為ecj：

(6)

式中：i代表鄰居節(jié)點(diǎn)。

(7)

根據(jù)式(5)，又可以將其改寫為：

(8)

算法3微服務(wù)負(fù)載及負(fù)載成本計(jì)算

輸入：Lij，α，β。

輸出:Cij，ΔLij，ecj。

1.foreachSido

2.利用式(4)計(jì)算Cij；

3.利用式(3)計(jì)算ΔLij；

4.利用式(8)計(jì)算ecj

5.endfor

6.returnCij，ΔLij，ecj

3.5 基于GRU的微服務(wù)級(jí)聯(lián)故障預(yù)測(cè)

門控循環(huán)單元(GRU)是長短期記憶網(wǎng)絡(luò)(LSTM)的一種變體，LSTM實(shí)現(xiàn)了遞歸神經(jīng)網(wǎng)絡(luò)(RNN)基于時(shí)間序列的特性的同時(shí)，又克服了RNN梯度消失的問題，即隨著時(shí)間的遞進(jìn)傳播梯度逐漸下降，直至停止學(xué)習(xí)。對(duì)于這個(gè)問題，LSTM采取門控結(jié)構(gòu)的方式進(jìn)行解決。通過遺忘門、輸入門、輸出門控制信息的丟棄、保留、更新和傳遞，實(shí)現(xiàn)了有用信息的保留和無關(guān)信息的丟棄[25]。GRU是LSTM變體中最有效的一個(gè)，它只設(shè)置了重置門和更新門，如圖4所示。重置門決定是否丟棄之前的狀態(tài)，更新門決定是否將之前的狀態(tài)更新為新的狀態(tài)。GRU在保留了與LSTM相當(dāng)效果的前提下實(shí)現(xiàn)了更高的效率。

圖4 GRU神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)圖

本文采用兩層隱藏層的GRU神經(jīng)網(wǎng)絡(luò)，即輸入層、GRU隱藏層、GRU隱藏層、輸出層的結(jié)構(gòu)。輸入為前文總結(jié)計(jì)算得到的數(shù)據(jù)，包括微服務(wù)的可用性、吞吐量、時(shí)延、故障概率、I/O頻率、CPU使用率、內(nèi)存使用率、磁盤使用率、網(wǎng)絡(luò)訪問頻率、微服務(wù)健康度、健康標(biāo)準(zhǔn)、微服務(wù)資源最大負(fù)載、額外負(fù)載和負(fù)載代價(jià)14個(gè)特征值；輸出為級(jí)聯(lián)故障的發(fā)生概率。隱藏層包含30個(gè)神經(jīng)元，為全連接層，輸入層與隱藏層間采用ReLU為激活函數(shù)，兩層隱藏層之間采用softplus為激活函數(shù)。

同時(shí)，還需要一個(gè)損失函數(shù)來估計(jì)預(yù)測(cè)值與實(shí)際值之間的差異。由于均方誤差(MSE)對(duì)異常值的敏感性，將MSE作為本文預(yù)測(cè)方法的損失函數(shù)。關(guān)于優(yōu)化器方面，選擇自適應(yīng)矩估計(jì)(Adam)優(yōu)化器。算法過程如算法4所示。

算法4微服務(wù)級(jí)聯(lián)故障故障概率計(jì)算

輸出：故障概率。

1.在神經(jīng)網(wǎng)絡(luò)輸入層與隱藏層間嵌入ReLU函數(shù)

2.在兩層隱藏層之間嵌入softplus函數(shù)

3.利用Adma對(duì)模型訓(xùn)練進(jìn)行優(yōu)化

4.利用MSE計(jì)算訓(xùn)練誤差

5.foreachSido

6.將屬性帶入神經(jīng)網(wǎng)絡(luò)進(jìn)行計(jì)算

7.endfor

8.return故障概率

4 實(shí) 驗(yàn)

在基于Docker+ Kubernetes+ Istio的網(wǎng)格服務(wù)平臺(tái)基礎(chǔ)上，運(yùn)行本文的級(jí)聯(lián)故障預(yù)測(cè)組件，模擬CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)四個(gè)資源不足的應(yīng)用場(chǎng)景，并對(duì)比貝葉斯網(wǎng)絡(luò)和基于馬爾可夫的動(dòng)態(tài)故障樹兩種方法，來分析本文方法的優(yōu)勢(shì)及其效率。

4.1 實(shí)驗(yàn)環(huán)境

4.1.1硬件環(huán)境

本文系統(tǒng)建立在擁有12個(gè)物理服務(wù)器節(jié)點(diǎn)的集群之上，其中兩個(gè)主節(jié)點(diǎn)用于集群管理和集群調(diào)度，是系統(tǒng)的入口節(jié)點(diǎn)，余下的11個(gè)節(jié)點(diǎn)為工作節(jié)點(diǎn)。這些節(jié)點(diǎn)的配置信息如表1所示。

表1 服務(wù)器配置信息

4.1.2軟件環(huán)境

本文系統(tǒng)部署在64位的Ubuntu16.04操作系統(tǒng)之上，采用的軟件環(huán)境如表2所示。

表2 軟件版本信息

4.1.3微服務(wù)實(shí)例

在服務(wù)網(wǎng)格平臺(tái)上部署了72個(gè)具有代表性的微服務(wù)，這些微服務(wù)包括計(jì)算密集型服務(wù)、數(shù)據(jù)密集型和通信密集型服務(wù)，模擬不同的級(jí)聯(lián)故障問題場(chǎng)景，具體微服務(wù)類型如表3所示。

表3 微服務(wù)實(shí)例類型

4.2 故障注入

神經(jīng)網(wǎng)絡(luò)訓(xùn)練需要在大量有代表性有意義的數(shù)據(jù)的基礎(chǔ)上進(jìn)行，實(shí)驗(yàn)需要的數(shù)據(jù)包括系統(tǒng)正常運(yùn)行時(shí)的微服務(wù)狀態(tài)信息以及級(jí)聯(lián)故障下的微服務(wù)狀態(tài)信息。為了獲取足夠的數(shù)據(jù)，采用故障注入在系統(tǒng)中設(shè)置障礙模擬級(jí)聯(lián)故障。

本文構(gòu)建了一個(gè)故障注入控制器(FIC)。FIC是介于微服務(wù)請(qǐng)求者和微服務(wù)響應(yīng)者之間的一個(gè)故障注入代理，它通過控制微服務(wù)之間的請(qǐng)求和響應(yīng)消息來模擬和注入故障。FIC由攔截控制器(IC)和觸發(fā)控制器(TC)兩部分組成。在IC中預(yù)設(shè)了要攔截的目標(biāo)微服務(wù)，IC會(huì)進(jìn)行實(shí)時(shí)攔截，判定該請(qǐng)求是否針對(duì)目標(biāo)微服務(wù)，如圖5所示。如果是，則將該請(qǐng)求消息傳遞給TC，TC對(duì)該請(qǐng)求進(jìn)行更改，更改策略包括擴(kuò)大請(qǐng)求負(fù)載、延遲請(qǐng)求、篡改數(shù)據(jù)包及丟棄數(shù)據(jù)包。TC將更改后的數(shù)據(jù)包回送給IC，IC將該請(qǐng)求發(fā)出。

圖5 故障注入架構(gòu)

本次實(shí)驗(yàn)設(shè)置了三組故障場(chǎng)景，如表4所示。

表4 故障注入場(chǎng)景

續(xù)表4

4.3 GRU神經(jīng)網(wǎng)絡(luò)模型訓(xùn)練

在連續(xù)的時(shí)間內(nèi)周期性地向系統(tǒng)中注入級(jí)聯(lián)故障，使系統(tǒng)在正常運(yùn)行與故障運(yùn)行中交替進(jìn)行，以一次交替為周期，從每個(gè)周期中抽取85%為訓(xùn)練集，15%為測(cè)試集。分別從三個(gè)級(jí)聯(lián)故障場(chǎng)景中收集了3 000條數(shù)據(jù)，共9 000條數(shù)據(jù)，7 650條為訓(xùn)練集，1 350條為測(cè)試集，其中均交叉分布著故障數(shù)據(jù)和非故障數(shù)據(jù)。

用訓(xùn)練好的模型對(duì)測(cè)試集進(jìn)行測(cè)試，并計(jì)算了模型的精確率和MSE，獲得的結(jié)果如表5所示。

表5 模型精確率和MSE

模型對(duì)級(jí)聯(lián)故障預(yù)測(cè)的精確率在85%以上，最高可達(dá)91.66%，MSE低于0.02，由此可知本文模型訓(xùn)練是有效的，可以應(yīng)用到級(jí)聯(lián)故障預(yù)測(cè)中。

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

級(jí)聯(lián)故障的發(fā)生有其邊界性，當(dāng)系統(tǒng)負(fù)載達(dá)到某一程度，才可能引發(fā)故障。因此實(shí)驗(yàn)的第一步是找到一個(gè)故障高發(fā)的負(fù)載段，然后在此負(fù)載下，從前面設(shè)計(jì)的三個(gè)場(chǎng)景入手進(jìn)行對(duì)比實(shí)驗(yàn)，對(duì)本文故障預(yù)測(cè)方法進(jìn)行評(píng)估。

4.4.1動(dòng)態(tài)負(fù)載下的故障頻率

首先測(cè)試了兩個(gè)場(chǎng)景下隨著負(fù)載變化級(jí)聯(lián)故障發(fā)生概率，分別是單一資源爭(zhēng)用微服務(wù)和多資源競(jìng)爭(zhēng)微服務(wù)。

觀察隨著單一資源爭(zhēng)用微服務(wù)負(fù)載增加，級(jí)聯(lián)故障發(fā)生狀況。如圖6所示，在微服務(wù)負(fù)載低于300時(shí)，沒有級(jí)聯(lián)故障發(fā)生。只有當(dāng)微服務(wù)負(fù)載突破300后，才開始出現(xiàn)級(jí)聯(lián)故障，并且隨著單個(gè)微服務(wù)負(fù)載的增加，級(jí)聯(lián)故障發(fā)生概率開始呈上升趨勢(shì)，且在負(fù)載達(dá)到650左右時(shí)，故障概率穩(wěn)定在0.36左右。

圖6 故障概率與單一資源爭(zhēng)用微服務(wù)負(fù)載關(guān)系

當(dāng)存在多個(gè)資源競(jìng)爭(zhēng)的微服務(wù)負(fù)載動(dòng)態(tài)變化時(shí)，級(jí)聯(lián)故障的發(fā)生狀況又不一樣了。如圖7所示，當(dāng)微服務(wù)負(fù)載超過250時(shí)，系統(tǒng)就會(huì)出現(xiàn)一定程度的級(jí)聯(lián)故障，相比圖6出現(xiàn)得更早。也從一定程度上說明了微服務(wù)間的資源爭(zhēng)用關(guān)系越復(fù)雜越容易導(dǎo)致級(jí)聯(lián)故障的發(fā)生。另一方面，當(dāng)負(fù)載超過500時(shí)，級(jí)聯(lián)故障發(fā)生概率就達(dá)到了0.37左右，即接近單一資源爭(zhēng)用微服務(wù)動(dòng)態(tài)負(fù)載情況下的極限值，且在負(fù)載達(dá)到600左右時(shí)，故障概率穩(wěn)定在0.42左右。

圖7 故障概率與多資源爭(zhēng)用微服務(wù)負(fù)載的關(guān)系

綜合以上兩個(gè)實(shí)驗(yàn)數(shù)據(jù)，可以更加確定微服務(wù)間資源爭(zhēng)用導(dǎo)致級(jí)聯(lián)故障這一觀點(diǎn)的正確性，同時(shí)也顯示具有多個(gè)資源爭(zhēng)用關(guān)系的微服務(wù)實(shí)例，更易引起級(jí)聯(lián)故障。

4.4.2故障預(yù)測(cè)評(píng)估

基于前文提出的三個(gè)場(chǎng)景，設(shè)置了三組對(duì)比實(shí)驗(yàn)，對(duì)比本文方法與貝葉斯網(wǎng)絡(luò)和基于馬爾可夫鏈的動(dòng)態(tài)故障樹兩種方法的故障預(yù)測(cè)效果。三組實(shí)驗(yàn)數(shù)據(jù)同時(shí)從三個(gè)故障場(chǎng)景中采集，其中貝葉斯網(wǎng)絡(luò)輸入為微服務(wù)調(diào)用樹和微服務(wù)健康指標(biāo)(包括可用性、吞吐量、時(shí)延、故障概率、I/O頻率、CPU使用率、內(nèi)存使用率、磁盤使用率和網(wǎng)絡(luò)訪問頻率)，以存在調(diào)用依賴的微服務(wù)和9個(gè)微服務(wù)健康指標(biāo)為故障信息源節(jié)點(diǎn)構(gòu)建貝葉斯網(wǎng)絡(luò)?；隈R爾可夫鏈的故障樹輸入與貝葉斯網(wǎng)絡(luò)相同，它在微服務(wù)調(diào)用樹的基礎(chǔ)上進(jìn)行故障樹的轉(zhuǎn)換，將存在依賴的微服務(wù)的狀態(tài)作為故障樹的節(jié)點(diǎn)，狀態(tài)的判定以9個(gè)微服務(wù)健康指標(biāo)為依據(jù)。

1) 場(chǎng)景一。圖8為基于場(chǎng)景一的三種方法級(jí)聯(lián)故障預(yù)測(cè)準(zhǔn)確率隨微服務(wù)負(fù)載變化趨勢(shì)。通過之前的實(shí)驗(yàn)可以知道，當(dāng)微服務(wù)負(fù)載達(dá)到400時(shí)，系統(tǒng)才能顯現(xiàn)明顯的級(jí)聯(lián)故障，因此我們的實(shí)驗(yàn)從負(fù)載400開始。當(dāng)我們向系統(tǒng)中大量注入計(jì)算密集和通信密集型微服務(wù)時(shí)，本文方法一開始準(zhǔn)確率較低，低于貝葉斯方法。但隨著負(fù)載增加，方法預(yù)測(cè)的準(zhǔn)確率逐步上升，從負(fù)載600后優(yōu)勢(shì)逐漸明顯，在負(fù)載1 000時(shí)準(zhǔn)確率達(dá)到90%。而基于貝葉斯網(wǎng)絡(luò)和基于故障樹的級(jí)聯(lián)故障預(yù)測(cè)準(zhǔn)確率上升不明顯，且不穩(wěn)定。

圖8 基于場(chǎng)景一的級(jí)聯(lián)故障預(yù)測(cè)對(duì)比

2) 場(chǎng)景二。圖9是基于場(chǎng)景二的級(jí)聯(lián)故障下的對(duì)比實(shí)驗(yàn)正確率曲線，與場(chǎng)景一相似，本文方法在負(fù)載低于600時(shí)，準(zhǔn)確率較低，甚至低于余下兩種方法。但隨著負(fù)載增加，本文方法準(zhǔn)確率增勢(shì)明顯且更穩(wěn)定。

圖9 基于場(chǎng)景二的級(jí)聯(lián)故障預(yù)測(cè)對(duì)比

3) 場(chǎng)景三。圖10是場(chǎng)景三下的級(jí)聯(lián)故障預(yù)測(cè)的對(duì)比情況?？梢钥闯?，相比于場(chǎng)景一和場(chǎng)景二的曲線，場(chǎng)景三在負(fù)載低于600時(shí)，本文方法準(zhǔn)確率略高，增勢(shì)也很明顯，準(zhǔn)確率最高可達(dá)93%。余下兩種方法的準(zhǔn)確率仍舊相對(duì)平穩(wěn)，且存在一定波動(dòng)。

圖10 基于場(chǎng)景三的級(jí)聯(lián)故障預(yù)測(cè)對(duì)比

結(jié)合以上所有實(shí)驗(yàn)，本文方法在微服務(wù)系統(tǒng)中能夠有效地預(yù)測(cè)出級(jí)聯(lián)故障，且相比于貝葉斯網(wǎng)絡(luò)和基于馬爾可夫鏈的動(dòng)態(tài)故障樹，本文方法在高負(fù)載時(shí)具有明顯優(yōu)勢(shì)，準(zhǔn)確率更高而且更穩(wěn)定。但是在負(fù)載較低時(shí)，本文方法表現(xiàn)不如另外兩種方法，分析認(rèn)為，GRU神經(jīng)網(wǎng)絡(luò)更適合處理大量數(shù)據(jù)，它善于從海量數(shù)據(jù)中搜索規(guī)律，而對(duì)于小量數(shù)據(jù)的分析會(huì)存在一定偏差。

5 結(jié) 語

本文研究重點(diǎn)是服務(wù)網(wǎng)格中級(jí)聯(lián)故障的預(yù)測(cè)，為此提出了一種結(jié)合微服務(wù)性能、微服務(wù)依賴和微服務(wù)資源爭(zhēng)用的級(jí)聯(lián)故障建模方法，并利用能夠基于時(shí)間序列進(jìn)行學(xué)習(xí)的GRU神經(jīng)網(wǎng)絡(luò)算法對(duì)級(jí)聯(lián)故障進(jìn)行預(yù)測(cè)。搭建了實(shí)驗(yàn)平臺(tái)，并在平臺(tái)上進(jìn)行了對(duì)比實(shí)驗(yàn)，驗(yàn)證了本文方法的有效性和穩(wěn)定性。實(shí)驗(yàn)表明在高負(fù)載時(shí)，本文方法與另外兩種方法相比有明顯的優(yōu)勢(shì)，而且正確率可以達(dá)到90%以上。實(shí)驗(yàn)中發(fā)現(xiàn)，對(duì)于不同的因素，級(jí)聯(lián)故障的敏感度不同，因此未來可能會(huì)針對(duì)不同資源角度更加細(xì)致地研究微服務(wù)的故障因素以及針對(duì)不同故障可以采取的規(guī)避措施。