基於研究論文《Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study》（作者：周翔、彭鑫、謝濤、孫軍、冀超、李文海、丁丹）形成本文。該論文由復旦大學計算機科學技術學院彭鑫教授領導的智能化軟件開發 CodeWisdom 團隊與北京大學謝濤教授、新加坡管理大學孫軍副教授合作完成，並被評選為軟件工程領域的國際旗幟期刊、CCF A 類期刊《IEEE Transactions on Software Engineering》2018 年唯一的最佳論文。該獎項由評選委員會從該期刊 2018 年錄用的 109 篇論文中評選而出。此獎項本次是第一次頒發，隸屬於 IEEE 計算機學會 2019 年發起資助的最佳論文獎計划。這個計划的目的在於表彰和獎勵 IEEE 計算機學會旗下每個期刊雜志在上一年度發表的最佳論文。
論文鏈接：https://cspengxin.github.io/publications/tse19-msdebugging.pdf
相關研究數據：https://fudanselab.github.io/research/MSFaultEmpiricalStudy
微服務開源項目（TrainTicket）：https://github.com/FudanSELab/train-ticket
微服務故障案例實現：https://github.com/FudanSELab/train-ticket-fault-replicate
背景
近年來，越來越多的企業開始采用微服務架構。一個大型的企業級微服務系統通常會包含成百上千的微服務，每個微服務都可以由容器編排系統（例如Kubernetes，即k8s）創建並管理多個實例，整個系統運行在數以萬計的計算節點上，並通過大量的服務間調用響應用戶的各種請求。
微服務系統的這種天然的復雜性和運行環境的動態性給微服務的故障分析和調試帶來了巨大的挑戰。開發者定位一個故障根源往往需要理解非常復雜的服務調用鏈，其中大量都是異步調用，因此微服務系統故障分析與調試經常都非常費時費力。
針對這些問題，我們開展了此次針對微服務故障分析與調試的實踐研究。
01
我們首先調研了工業界微服務系統的典型故障案例以及故障分析與調試實踐方法。
01
然后，我們根據所調研的工業界微服務系統的特點開發了一個中等規模的開源微服務基准系統TrainTicket，並在該系統上重現了22個典型的微服務故障案例。
01
在此基礎上，我們提出了多種基於日志分析與可視化的微服務系統故障定位策略，構建了相應的分析工具，並在所重現的故障案例基礎上進行了實踐對比和分析。
1
微服務故障案例調研
我們邀請了16位具有微服務技術背景的資深工程師參與調研，整理了22個典型故障案例，涉及13種不同的微服務系統，相關系統規模從50個微服務到1000個微服務不等。圖1展示了22個典型的工業故障的詳細描述，對於每種情況，該表列出了故障的報告者、故障的症狀、故障的根源以及用於定位故障根源的時間。
圖1. 22個典型的微服務故障案例
根據這些故障的症狀（功能性或非功能性）和故障的根源（內部邏輯、服務交互、系統配置），我們把這些故障分為了6類，如圖2所示。
功能性故障
主要包括那些由於運行產生的不正確的結果而導致系統服務失效的情況
非功能性故障
主要包括那些會影響服務質量的情況，如性能和可靠性。
內部邏輯故障
主要表示那些由於單個微服務的內部實現錯誤導致的故障
服務交互故障
主要表示那些由於多個微服務之間的交互實現不合理導致的故障
系統配置故障
主要表示那些運行時基礎設施的配置不當導致的故障。
圖2. 微服務故障案例分類
2
微服務故障分析與調試實踐調研
與此同時，我們也調研了工業界的故障分析與調試實踐，歸納了如下三個層次的實踐方法，如圖3所示。
01
基本日志分析（Basic Log Analysis）：在原始日志上進行分析，在這個級別上日志通常是零散的，開發人員需要在各個不同的節點上分析系統生成的各種原始日志以定位故障；
02
可視化日志分析（Visual Log Analysis）：在日志數據上進行可視化分析，在這個級別上日志往往是結構化並且可視化的，結合相關統計圖表進行故障定位；
03
可視化軌跡分析（Visual Trace Analysis）：針對微服務執行軌跡（trace）進行可視化分析，在這個級別上開發人員可以結合系統的執行軌跡的信息（如微服務的服務之間的調用鏈的信息）進行故障定位。
圖3. 故障分析與調試實踐方法的三個層次
針對以上這6大類故障，以及三個故障分析與調試實踐方法層次，我們進一步分析了故障診斷過程中普遍存在的7個故障診斷步驟。如圖4所示，我們針對22個典型故障，分類並整理了各種不同故障類別，在不同的故障診斷成熟度級別下，在7個故障診斷步驟下所分別消耗的時間。
這7個步驟分別是初始理解（IU）、環境搭建（ES）、故障重現（FR）、故障識別（FI）、故障范圍界定（FS）、故障定位（FL）和故障修復（FF）。
我們根據這些匯總的信息，分析了不同故障類別下，不同成熟度對不同的故障診斷步驟所帶來的正面和反面的影響，及其背后蘊含的規律。
圖4. 微服務故障案例分析與調試實踐步驟
3
微服務開源基准系統
為了能進一步研究工業界故障案例及其相關故障診斷實踐，我們開發了一個開源微服務基准系統TrainTicket，部署運行在K8s+Istio上，集成了相關監控分析工具（包括ELK、Zipkin等）。
如圖5所示，TrainTicket系統提供典型的火車票預定相關功能，如車票查詢、車票預訂、付款、改簽和用戶通知等等。它是基於微服務的設計原則設計的，涵蓋了不同的服務間的交互模式，如同步調用、異步調用和消息隊列。系統包含41個與業務邏輯相關的微服務（不包括數據庫和基礎設施微服務）。它總共使用了四種編程語言：Java、Python、Node.js和Go。我們在此系統上重現了工業調研中的收集的所有故障案例，以支持我們的后續關於故障診斷的研究。
圖5. 微服務基准系統TrainTicket架構
4
微服務故障分析與調試經驗研究
為了進一步評估企業現有的微服務故障分析與調試方法的有效性並探索可能的技術改進，我們在微服務基准系統TrainTicket以及所復現的故障案例基礎上進一步進行了經驗研究。
01
定性分析
02
定量分析
03
改進的微服務系統故障分析方法
我們分別通過定性分析和定量分析來研究三個不同成熟度級別的調試實踐的有效性。對於每個故障案例，選擇三個開發人員使用不同成熟度級別進行調試。我們觀察到，對多數故障，使用更高級別的調試實踐（從基本日志分析、可視化日志分析、到可視化軌跡分析）會一定程度的縮短調試的總時間。在這些故障案例中，服務交互故障的調試是從更高級別的調試實踐中獲益最多的故障調試。
為了更好地支持微服務系統的故障分析和調試，我們在現有的分布式調試工具Shiviz（https://bestchai.bitbucket.io/shiviz/）基礎上提出了一套改進的微服務系統故障分析方法。Shiviz實現了一套非常友好的基於事件的服務間調用的可視化接口，並且支持很強大的調用鏈集合搜索功能，以及調用鏈比較功能，非常適合故障診斷。我們針對該可視化工具實現了相應的日志轉化，構建了相應的針對微服務故障的執行軌跡可視化工具用於輔助開發者進行故障診斷。具體思路如圖6所示。通過執行軌跡的兩兩比對（事件節點簇比對）來找出其不同點和相同點，並基於此定位到故障根源。例如，我們先通過比較同一故障的正確和出錯調用鏈之間的差別來找出故障大致的位置，然后比較同一故障的兩個出錯調用鏈的相同部分來進一步定位故障根源。
圖6. 改進的微服務故障分析方法
圖7展示了故障F10的服務級別分析示例，我們通過執行軌跡日志的轉換，以控制可視化視圖的監控單元（頂部節點）為微服務或微服務狀態，然后構建出如圖7所示Shiviz的執行軌跡比較視圖（左側為正確執行軌跡，右側為故障執行軌跡）。對比中看到紅框中有兩個差異（菱形），差異處即為潛在的故障根源位置。
圖7. 故障F10的服務級別的分析示例
圖8展示了故障F12的服務級別和服務狀態級別的綜合分析示例，當我們進行如圖8（a）所示的服務級別分析時，我們發現：失敗執行軌跡和成功執行軌跡之間沒有區別。於是，我們引入微服務狀態級分析，通過引入狀態變量或表達式來改進執行軌跡的比較。如圖8（b）和圖8（c）所示，在服務狀態級別的分析中，差異之處在於訂單服務節點的管理員車票檢查區域狀態這里，該狀態便是潛在的故障根源。
圖8. 故障F12的服務級別和服務狀態級別的綜合分析
示例
基於改進后的執行軌跡可視化工具的可視化策略分析和調試時間分析結果如圖9所示。在12個故障案例中，失敗的案例有2個（F3和F4），和改進前的現有的工業調試方法的執行軌跡可視化分析結果相同。對於F16，開發人員成功了，但使用的時間比改進前的現有的工業調試方法的執行軌跡可視化分析要長。這三種情況都是環境故障（F3和F4是非功能的，F16是功能性的），這樣的結果表明調試這些故障並不能從改進后的執行軌跡分析中受益。
在所有其他9個故障案例中，開發人員的平均調試時間從3.23小時縮短到2.14小時，效率明顯提高了。這9個故障案例都是交互故障，對於這些故障，故障定位、初始理解、故障重現是從改進后的分析中獲益最大的三個步驟。與改進前的現有的工業調試方法相比，這些步驟所用的時間分別減少了49%、28%和24%
圖9. 基於改進的執行軌跡可視化工具的調試策略和調試時間消耗分析
5
分析與展望
我們進行的針對微服務故障定位的實踐研究表明：通過適當的跟蹤、可視化技術，可以一定程度地幫助開發者調試微服務的各種故障。但是，我們同時也發現，微服務故障定位需要更自動化和更智能的相關工具的支持。
在大規模的工業微服務系統中，微服務的數量通常成百上千，產生的各種運行時事件的數量也經常會達到數萬甚至數百萬個。這樣的龐大的節點和事件數量會使得可視化分析變得幾乎不可行。我們建議，可以從如下方面來尋求突破。
首先，可以在可視化這里提供海量事件的縮放能力和節點/事件簇的能力，其中節點/事件簇可以自適應地將相關節點和事件分組在一起，以便於開發者分析和研究。通過這種可視化優化的方式來減少開發者需要檢查的節點和事件的數量。
其次，可以將一些傳統的故障定位技術引入進來，結合這些技術中故障定位的思路，實時分析微服務系統的執行軌跡數據，以自動化地定位出故障根源的可疑范圍。
再次，也可以把海量的歷史執行軌跡日志利用起來，采用數據驅動和基於學習的方法進行故障根源的預測。