李榮宸,姜瑛,姒鑒哲
(1.云南省計算機技術應用重點實驗室,云南 昆明 650500;2.昆明理工大學 信息工程與自動化學院,云南 昆明 650500)
近年來,隨著云計算技術的不斷發展,越來越多的企業和組織將其業務遷移到云端。然而,在云計算環境下,服務故障的傳播路徑更加復雜,因此準確識別服務故障的傳播路徑對于保障云計算服務的可靠性和穩定性至關重要[1]。但是,由于云計算環境的高度分布式和異構性等特點,識別服務故障的傳播路徑面臨著許多難點,包括如何有效地收集和處理海量的監控數據,如何準確地識別故障源和故障傳播路徑等[2]。快速動態地識別服務故障傳播路徑,可以及時定位故障發生的區域并確定服務故障的傳播和擴散情況,降低系統不正常運行的風險。
因此,研究云計算環境下服務故障傳播路徑識別具有重要意義:一方面,可以幫助企業和組織及時發現和解決服務故障,提高云計算服務的可靠性和穩定性;另一方面,可以為云計算服務的優化和改進提供有價值的參考和支持,推動云計算技術的進一步發展和應用[3-4]。因此,如何快速準確地識別云計算環境下的服務故障傳播路徑,成為亟待解決的問題。
近年來,故障傳播路徑識別受到廣泛關注。文獻[5]認為模塊之間通過函數調用交互,故障可以通過模塊接口傳播,抽象出核心模塊之間的依賴關系,識別故障在模塊之間的傳播路徑。文獻[6]提出了一種以異常傳播為導向的微服務故障診斷方法,它利用微服務的測量信息和服務之間的調用行為來構造一張微服務的依賴圖,在此基礎上對異常的微服務進行檢測,來獲得服務的故障傳播圖,并確定異常的根源。文獻[7]將目標鎖定在分布式系統中,在服務之間存在著不同的執行軌跡,使用注射代理的方法對業務進行攔截并轉發,通過分布式跟蹤系統采集服務調用信息,可以很好地發現在服務調用路徑中存在的異常。文獻[8]中提出了一種在云計算環境下的服務故障傳播路徑識別方法,該方法利用服務呼叫關系來構建一個服務互動圖,并對該圖進行優化,從而構建出一個服務關系圖,對其進行全面的研究,最終對服務故障傳播的影響因素進行了全面的分析和計算,從而對其進行識別。然而,服務的高頻調用產生海量數據,給服務異常的實時性分析帶來挑戰[9]。貝葉斯網絡結構學習是從給定數據集中推斷事件關聯關系的常用方法,能夠從實時數據中學習服務故障傳播結構。文獻[10]提出一種基于父節點濾波的高斯貝葉斯網絡故障傳播路徑識別推理算法,通過結構學習算法構建貝葉斯網絡,再根據參數權值和對父節點集進行約簡,求出約簡父集可能子集的最大條件概率,逐層推理確定故障的傳播路徑網絡。貝葉斯網絡[11]的結構學習已經被證明是NP-hard 問題,因此構建網絡的算法應盡可能保證準確率并降低時間開銷。
綜上所述,基于服務調用信息構建服務依賴關系是識別服務故障傳播路徑的常用方法,但服務的高頻調用為服務故障傳播路徑的實時性分析帶來挑戰。而通過貝葉斯網絡結構學習推斷完整的故障傳播路徑需要一定的時間開銷。針對這些問題,本文提出一種基于因果圖模型的服務故障傳播路徑識別方法,在未知服務之間依賴關系的情況下推斷服務故障事件因果關系,構建服務故障傳播圖以識別出服務故障的傳播路徑。
在云計算環境下,服務故障事件之間具有因果關系,可以通過推斷因果關系來構建服務故障傳播圖,識別服務故障傳播路徑。由服務故障傳播導致的事件因果關系存在一個特點:作用于服務故障傳播方的隨機事件更易影響感染方,而作用于服務故障感染方的隨機事件不太可能影響傳播方。
基于以上特點,本文提出一種基于因果圖的服務故障傳播路徑識別方法,在不知道服務間依賴關系的前提下,從服務運行數據中提取服務故障事件,推斷故障事件之間的因果關系以構建服務故障傳播圖,并根據服務故障傳播圖與故障服務列表確定服務故障傳播路徑。方法的主要步驟包括服務故障事件度量、服務故障傳播圖構建和服務故障傳播路徑識別。
服務由于運行結果錯誤或性能下降而無法正常運行的現象稱為服務故障事件。使用服務運行數據來度量單個服務故障事件,可以反映單個服務的故障情況,同時也是分析不同服務故障事件之間因果關系的基礎。
故障使服務無法正確處理請求或處理請求的時間過長,進而導致服務占用系統資源異常,通常會出現資源使用率、服務執行時間等指標過高或過低的現象。其次,當服務對物理資源存在較為穩定的調度邏輯時,會使得各項物理資源之間產生穩定的關聯關系,例如,服務通過網絡接收用戶請求并進行處理時,網絡流量較大也會使得CPU 資源占用較高。而故障使得服務資源調度出錯并進一步導致服務運行結果出錯時,物理資源之間的調度邏輯也會發生變化。此外,服務被調用次數決定了服務占用多少系統資源,所以指標過高或過低也會受到服務被調用次數的影響。
為了衡量服務運行數據指標期望偏離與服務調度邏輯的變化情況,本研究將統計量作為服務故障事件度量值。該方法在去除服務正常運行時方差為0 的指標及非平穩的指標后,通過主成分分析(Principal Component Analysis,PCA)算法去除數據中的完全共線性以避免度量值小于0,再使用協方差矩陣消除指標間的線性關系,從而可以直接使用指標均值偏離情況度量這兩類情況。統計量的計算公式如式(1)所示:
式中:u和Σ分別為服務正常運行數據集中各項指標均值構成的均值向量和協方差矩陣;Xˉ和n為當前服務運行數據集中各項指標均值構成的均值向量和數據集數據量。當某服務高于閾值時,則認為該服務發生故障。
取n=1 時可求出某服務在某段時間內每一時刻的度量值,根據時間順序排列成行向量后得到該服務的故障事件度量向量,將所有服務的故障事件度量向量組合成一個矩陣,這個矩陣為服務故障事件度量矩陣。服務故障事件度量矩陣反映了服務故障事件之間的因果關系。當服務由正常變為故障時,度量值升高。服務異常程度越高,度量值越大。因此,服務故障傳播導致服務故障事件度量矩陣中對應服務的行向量線性相關。
服務故障傳播圖為帶權有向圖,節點表示故障服務,邊的方向表示故障傳播方向,權重表示故障事件因果效應強度。由于服務故障傳播使得服務故障事件度量向量線性相關,因此服務故障事件服從線性結構因果模型[12]。在線性結構因果模型中,若服務x故障導致服務y故障,則因果關系可表示為y=wx+e,其中e為隨機擾動項,代表x以外的服務調用次數、服務故障等隨機事件對y的影響,w為因果效應強度。因此,對于n個服務的故障事件x1,x2,…,xn,其因果關系表示為如下形式:
式(2)的矩陣形式為x=Wx+e,x為服務故障事件度量矩陣,e是殘差矩陣,W是服務故障傳播圖的鄰接矩陣。為了求解系數矩陣W構建服務故障傳播圖,本文采用DirectLiNGAM 算法[13]首先分析變量與隨機擾動項的獨立性遞歸求出外生變量以得到因果順序排列,使得排列在后面的事件不影響前面的事件,即求出x1,x2,…,xn分別對應哪個服務,最后估計參數得到矩陣W。
然而,在使用DirectLiNGAM 算法推斷事件因果關系求解系數矩陣W時,可能出現一些特殊情況。例如,某服務在處理完請求后因為停止運行或不被調用造成服務運行數據缺失,此時該服務沒有傳播故障,也沒有被傳播故障,所以該服務的狀態不受其他服務影響,但在線性結構因果模型中,最不容易受到其他變量影響的變量會被識別為外生變量,因此如果某個服務缺失數據越多,這個服務就越容易被識別為故障的傳播方。為避免此類情況的發生,本文優化DirectLiNGAM 算法,在分析變量與隨機擾動項獨立性求解外生變量時,僅使用兩個服務同時運行的數據,若沒有同時運行的數據,則判定兩個服務故障事件獨立性最強,即變量與隨機擾動項獨立性最弱。
通過調整后的DirectLiNGAM 算法推斷出服務故障事件的因果關系,從而構建出服務故障傳播圖,以確定服務故障的傳播方向及故障事件間的因果效應強度。
服務故障傳播圖是一種所有服務之間都有一條有向邊連接的有向無環圖,且圖中邊的權重表示因果效應的強度。服務故障傳播導致不同服務故障事件具有較強的線性關系,從而圖中對應邊會有更高的權重。因此,服務故障傳播路徑是服務故障傳播圖中以故障服務為起點,且因果效應較強的路徑。
為了從服務故障傳播圖中獲取服務故障傳播路徑,首先依據2.1 節方法篩選出故障服務,然后標準化處理服務故障傳播圖權重;其次遍歷服務故障傳播圖,篩選出所有以故障服務為起點的路徑;最后將路徑上所有邊權重相乘,作為該路徑的因果效應強度,并對所有路徑按因果效應強度降序排序。路徑排列越靠前,則故障由這條路徑進行傳播的概率越大。服務故障傳播路徑識別算法如下所示:
服務故障傳播路徑識別算法的主要開銷為圖的遍歷和對標圖的邊權重進行標準化,因此如果服務數量為n,時間段長度為m,算法的時間復雜度為O (mn3)。
為了驗證本文方法的有效性,本文使用兩種實驗環境。
環境1:使用Python 語言開發的10 個服務,實現根據用戶請求進行計算與匯總的功能。10 個服務部署在Docker 容器中,其中1 個服務負責處理請求,8 個服務執行計算功能,最后1 個服務對計算結果進行匯總處理。通過程序插樁方式獲取每次調用時每個服務的處理請求耗費時間、用戶請求內容、請求與執行結果的數據包大小和服務調用關系,環境1 服務依賴結構如圖1 所示。

圖1 實驗環境1 服務依賴結構
如圖1所示,服務ReqProce負責處理用戶請求,服務CalcA、CalcB、CalcC、CalcD、CalcE、CalcF、CalcG 和CalcH構成了應用的計算節點。服務ReqProc 在接收用戶請求后,會根據用戶請求內容分析需要調用計算節點哪些服務進行計算,然后再調用對應服務執行計算功能。在計算節點服務計算完成后,服務ReqProc 調用CalcSum對計算節點服務的計算結果進行匯總處理,其中計算節點的計算結果通過數據庫進行存儲。在故障注入時,使用Python 語言開發程序向服務ReqProc 發送大量請求,隨機調整用戶請求內容,改變服務需要處理的數據量及對計算節點服務的調用方式。
環境2:微服務應用SockShop。SockShop 是一個由Java、Go、.NET 和NodeJS 等多種語言開發的微服務電商平臺,包含13 個微服務,服務依賴結構如圖2 所示。

圖2 實驗環境2 服務依賴結構
如圖2 所示,frontend 接收用戶請求并提供前端頁面。orders、payment、carts、catalogue、user 分別提供訂單、支付、購物車、產品目錄管理和用戶信息管理功能,shipping 接收訂單并提供發貨功能,queue-master 模擬發貨過程。另外,部分核心服務由對應的數據庫管理服務進行管理數據存儲。本文將服務SockShop 部署在Docker 容器中,使用Docker stats 工具采集每個服務對應容器的CPU、內存、網絡和磁盤資源的使用情況,并通過WeaveScope 監控服務之間的調用關系。在注入故障時,使用WeaveWorks 壓力測試工具向frontend 發送大量請求,通過WeaveScope 觀察到故障注入導致SockShop產生frontend→orders、orders→user、orders→carts、orders→payment、carts→catalogue 這幾條調用路徑。
格蘭杰因果檢驗(Granger Causality Test)是一種常用的因果關系檢驗方法,格蘭杰因果檢驗將兩個時間序列分別表示為X和Y,然后建立兩個AR 模型,分別是X的AR 模型及X和Y的VAR 模型。然后通過比較這兩個模型的預測誤差,判斷Y是否受到了X的影響,即X是否是Y的因果變量。可以處理非平穩時間序列和多變量時間序列,并且可以進行因果關系的方向推斷。但是,它也有一些局限性,如只能檢測線性因果關系,對噪聲敏感等。格蘭杰因果關系定義為作為因的變量的過去信息更有助于解釋作為果的變量的變化。與格蘭杰因果檢驗不同,本文因果關系定義為作用于因的隨機事件更容易影響作為果的隨機事件。因此將本文方法與格蘭杰因果檢驗進行對比。
本次實驗針對兩個實驗環境進行故障注入并采集數據,由于兩種方法都對數據敏感,因此采用隨機樣本容量隨機抽取連續數據樣本的方法來獲取故障發生的任意階段數據。首先計算每個樣本中服務的故障事件度量值,然后分別使用本文方法和格蘭杰因果檢驗推斷服務故障事件度量值之間的因果關系,從而識別故障傳播路徑。實驗中針對每條路徑抽取500 個樣本,統計兩種方法故障傳播路徑識別準確率與方法平均運行時間,對比兩種方法的有效性及性能。實驗結果如表1 所示。

表1 服務故障傳播路徑識別對比實驗結果
如表1所示,格蘭杰因果檢驗平均準確率為35.13%,平均運行時間為10.131 9 s;本文方法平均準確率為77.04%,平均運行時間為0.251 3 s。在準確率方面,本文方法優于格蘭杰因果檢驗,原因在于格蘭杰因果檢驗主要分析事件兩兩之間的關系,而本文方法綜合考慮了所有事件,避免了因為遺漏重要變量而產生的內生性問題,從而提升了準確率。然而,在識別環境2 中路徑frontend→orders時,本文方法識別準確率降低,原因是在環境2中,雖然frontend 調用orders 導致orders 故障,但frontend 需要獲取orders 的處理結果并為用戶提供對應的前端界面,造成了服務之間雙向依賴關系。這種關系產生的環路導致內生性問題,造成識別準確率下降。
在性能方面,本文方法遠遠優于格蘭杰因果檢驗,原因是格蘭杰因果檢驗在推斷因果關系時需要對服務大量的過去信息進行分析,需要較大的時間開銷。
綜上所述,本文所提出方法能夠有效識別服務故障傳播路徑,且時間開銷較低,但當服務存在雙向依賴關系導致故障傳播出現環路時,會因為內生性問題造成識別準確率下降。
針對云計算環境下的高頻調用導致服務故障傳播路徑的實時性分析困難,以及貝葉斯網絡結構學習推斷完整的故障傳播路徑時間開銷大的問題,本文提出了一種基于線性結構因果模型的服務故障傳播路徑識別方法。首先,監測并收集服務運行數據,通過服務運行數據度量服務故障事件;然后,應用DirectLiNGAM 算法推斷服務故障事件之間的因果關系并構建服務故障傳播圖;最后,基于服務故障傳播圖確定故障傳播路徑。
實驗表明,本文方法能夠以較短的時間開銷準確識別服務故障傳播路徑。但是,本文方法在識別存在雙向依賴關系的服務故障傳播路徑時,會因為內生性問題使得識別的準確率降低。因此,接下來將深入分析如何結合服務調用鏈路構建因果推斷的先驗知識,在具備先驗知識的情況下識別服務故障傳播路徑。
注:本文通訊作者為姜瑛。