導讀

在大規模微服務架構中，雪崩故障是極具破壞力卻又難以預防的系統性威脅。本文基於百度搜索架構與運維團隊的實戰經驗，深入解析雪崩從“非穩態”到“自強化崩潰”的微觀演化機制，揭示重試風暴、容量退化等正反饋迴路的形成過程。文章提出系統化的治理思路，並詳細介紹百度落地的多項核心實踐，包括重試預算、隊列限流、全局TTL控制等自愈機制，以及秒級流量調度與降級預案。通過真實案例與生產數據，為行業提供了一套可借鑑的雪崩預防與治理框架。

説明：本文是由2025 SRECon會議的《Preventing Avalanche Failures in Large-Scale Microservice Systems》的演講者翻譯並整理而成。

01 摘要

大規模微服務系統在享受分佈式架構帶來的靈活性和擴展性的同時，也面臨着雪崩故障的嚴重威脅。雪崩是一種系統性故障模式，破壞力極大，難以預防，會給企業帶來巨大損失。

本文深入分析雪崩的形成機理和演進模式，建立理論模型，從微觀層面推導災變過程，並通過真實生產案例驗證了雪崩的快速演化路徑。接着，通過系統化的思辨，探討可能的治理方法。然後，介紹了百度的系統性的雪崩治理框架及一系列的核心實踐機制。最後總結了近幾年的治理成果，為行業提供了可借鑑的實踐經驗。

02 背景

大規模微服務系統本質是一張由大量節點和依賴交織而成的網絡。請求從入口gateway進入系統，再層層向下形成深度調用鏈，往往還伴隨着交叉依賴與高扇出。這種特點雖然帶來了靈活性與擴展性，但天然埋着三類穩定性風險：其一是“未知中的未知”，如冷門鏈路、冷門代碼在突發場景被激活；其二是容量級聯風險，任一節點變慢都會把反壓沿鏈路放大回傳；其三是重試風暴，自我強化的流量會指數級擴散。在這種架構中，任何局部抖動都會以毫秒級在系統中傳播。理解這張網絡，就為理解‘雪崩’發生的原因奠定了基礎。

大規模微服務系統依靠多種高可用機制來提升性能，表現為：

• 分佈式架構避免單點故障並帶來彈性擴展能力；
• 緩存抵擋流量激增並降低延遲；
• 重試實現瞬時恢復並提高成功率；
• 請求隊列平滑流量尖刺並維持穩定吞吐量。

然而，在雪崩條件下，同樣的機制會翻轉到另一面，表現為：

• 分佈式架構引入複雜依賴和更大的爆炸半徑；
• 緩存失效引發流量洪峯和延遲激增；
• 不受控的重試導致指數級流量風暴；
• 後端變慢導致隊列超時和入隊失敗。

03 直觀感受雪崩的威力

這裏舉一個真實的例子給大家直觀感受雪崩的威力。在一個IDC中，少量實例出現輕微健康退化，引發中等程度的延遲上升和輕微的可用性下降——沒什麼令人擔憂的，只是典型的小波動。幾乎同時，隨着上游重試機制啓動指數退避策略，流量迅速激增，導致服務在幾秒內變得不可用。

然後，根據預定義的SLA執行自動預案，將大量負載從受影響的IDC轉移到其他健康的IDC。但這些"健康"的IDC，只能在正常容量範圍內運行，此時突然遭受顯著的放大了的流量衝擊，也變得過載。

緊急擴容馬上被觸發，擴充並啓動更多的實例，但級聯過載的蔓延的速度仍然比我們擴容策略的響應速度更快。

緊接着，多項嘗試止損的動作被並行執行——流量比例調整、緩存命中率優化、超時時間縮減——然而它們在呈指數級的故障放大效應面前仍然無效。此刻，系統處理的主要是重試流量，其數量遠超設計容量，線程池完全耗盡，請求隊列被已超過SLA閾值並且註定要失敗的請求填滿。

這進一步引發了所有IDC的級聯故障，最終導致系統級的完全崩潰，影響了大量用户。

在這個案例中，起初只是一個影響了少量實例的小問題，最終演變成了完全的系統崩潰。整個過程在僅僅2分鐘內發生——這是大規模微服務系統在雪崩場景下如何自我毀滅的可怕呈現。

04 雪崩的特點

以上，我們直觀感受到了雪崩的威力。那麼，什麼是雪崩？讓我們從4個雪崩的特點來介紹雪崩。雪崩發生前，系統都會首先進入“非穩定”狀態，這種狀態“貌似正常、實則脆弱”。各項指標也許還在閾值內，但可用餘量極少，表現為：負載上升，延遲上漲……此時的系統對擾動極為敏感，任何輕微擾動都會使它偏離穩定狀態。

第二個特點是需要小的觸發源扭轉狀態。觸發源可能是多種多樣的，比如，流量尖刺、網絡瞬時抖動、硬件故障、軟件冷門邏輯被觸發……。它們本身並不致命，但在不穩定狀態邊緣，哪怕微小的觸發都足以把系統推過臨界點。真正導致系統邊界違規的不是觸發的強度，而是系統自身餘量不足。然而，微小觸發仍然是必要條件。

一旦越過臨界點，系統會迅速進入自強化階段，這是雪崩最典型的一個特點。在這種情形下，高可用優化機制統統都站到了反面。系統每增加一點惡化，高可用機制就產生一些正向反饋，從而導致進一步惡化。這條惡化-反饋循環持續加強，複雜且迅速。圖中展示了幾個例子。迴路一：請求失敗導致重試，然後導致負載上升，進而導致更多失敗，最終形成指數級的重試風暴；迴路二：少量實例略不健康導致被摘除，然後導致剩餘實例更忙，進而導致更多實例被判不健康，最終引起容量指數級退化；迴路三：錯誤事件導致大量的日誌和監控，然後導致I/O用量上升，進而導致更多錯誤，最終使性能進一步惡化。

隨着自強化階段的持續，系統很快進入到失控和崩潰狀態，這種狀態最大的特點是無法靠自身恢復。線程池被耗盡，請求隊列被已超時或必然失敗的請求塞滿，後端被無意義工作佔滿並拖慢，上游開始全面超時。

常見修復措施並不能奏效，甚至適得其反。比如，臨時擴容往往慢於正反饋的加速導致資源就緒時系統早已熔燬，調cache難以解決重試反饋帶來的流量放大，等等。需要專用的機制才能緩解，就像不能滅火器撲滅一顆正在爆炸中的核彈。唯有改變微觀機制上的反饋結構，才能真正抑制雪崩。

讓我們簡要回顧雪崩的4個特徵來理解雪崩的定義：

• 非穩態：系統看似正常但餘量極少，對擾動高度敏感；
• 微小觸發：流量尖刺或網絡抖動等輕微擾動就能推動系統越過臨界點；
• 自強化：高可用機制創建正反饋循環，通過重試風暴和容量損失放大惡化；
• 無法自我恢復：系統崩潰，資源耗盡。常見修復措施適得其反，需要專門干預。

05 理論模型

讓我們從微觀層面看一下雪崩。首先，我們看一個基本的模型。在這個模型中，流量以rps的吞吐流經一個服務的請求隊列；然後，該服務的workers以concurrency的併發度處理隊列中的請求，併發向後端進一步處理。在正常情況下，發向後端的吞吐也是rps。從請求到達本服務到本服務處理完成，所用的時間是latency。

基於Little's Law，我們有這樣的公式：rps <= concurrency / latency。

真實的系統可以看做基礎模型的管道似的級聯連接。在這套連接系統中，需要保持任意位置的吞吐在實際流量之上，即在任意位置，都要維持這個rps <= concurrency / latency式子滿足。

整個系統的吞吐受限於最薄弱的環節。需要精心地維持各環節脆弱的平衡。若任何位置的平衡哪怕短時間被打破，也會迅速觸發級聯反應，使系統雪崩。

06 微觀災變過程

接下來，讓我帶大家從微觀層面看一下雪崩過程發生了什麼。在這個抽象例子中，拓撲結構為 gateway → A → B → C，其中服務C變慢併成為觸發點。

這張圖使用“狀態聚焦”的視角展示雪崩的快速微觀演化過程。首先説明圖中顏色的含義：紅色代表惡化；灰色表示此階段暫無新增變化。我們僅高亮當前需要重點關注的信號。

• 在健康狀態下：系統延遲低，排隊最少，吞吐量最優。
• 在觸發階段：C開始變慢，其延遲明顯上升。
• 隨着問題擴散，B和A的線程利用率和延遲幾乎同時激增，而吞吐量和隊列長度保持相對不變，顯示出典型的’嚴重積壓前的快速傳播’行為。
• 隨即來到堆積階段：當併發達到上限後，B 和 A 的隊列開始快速堆積，表明排隊機制已被觸發。
• 很快系統進入重試狀態，B的超時觸發上游重試。B接收到更多流量，而好吞吐比例下降，顯示服務質量正在惡化。
• 接下來，流量開始放大，gateway級重試被觸發，在A處造成流量激增，在B處造成第二次流量激增。對B產生的壓力導致好吞吐進一步下降。
• 最終迅速坍塌到雪崩階段：重試的重試形成正反饋循環，線程與隊列被大量無效工作佔滿，系統徹底崩潰。

請注意三個關鍵點：線程利用率首先增加，隊列長度快速跟進，吞吐量表現出兩次或更多的快速躍升。

07 真實案例驗證

讓我們用真實的生產數據來驗證前面的模型。由於這個故障發生在幾年前，我們現在展示的這些指標是當時能夠獲取到的最完整的一組，儘管未能把前面模型裏提到的所有指標都收集到。左邊這個小圖把B的總時間拆成了三部分：排隊時間、本地處理時間、以及後端時間；右邊的三張曲線的時間軸是對齊的。

這次故障仍然是C變慢了。首先，B的後端時間、整體延遲、線程使用量幾乎同時抬升，與此同時，A的整體延遲也開始上漲。緊接着，B的排隊時間開始上漲，很快，A的排隊時間也跟着抬頭——這正對應前一頁的“擴散到堆積”的階段轉換。

接着我們發現一個有趣的現象：B的本地處理時間不增反降。其實原因很簡單：線程更多時間在等後端返回，CPU空出來了，局部被處理到的請求就顯得更快，這是常見的“局部變快錯覺”。

再看吞吐曲線：A和B的RPS先出現一次階躍，這是gateway的重試流量被激發；隨後B的RPS再次躍升，這是A觸發了二次重試。雖然我們沒有直接畫出“重試率”和“好吞吐佔比”，但“排隊時間增長”和“RPS兩次階躍”的組合，足以驗證雪崩過程中由重試的驅動的故障放大路徑。

整個過程大約發生在三分鐘之內。

08 系統性思辨

既然我們理解了什麼是雪崩以及它們在微觀機制層面是如何工作的，讓我們採用系統性方法來分析我們的選擇。我想通過一個結構化的框架帶着你來思考。在這個框架中，我們將檢查雪崩的每個特徵，並問：“我們能在這裏干預嗎？”通過這種系統性分析，我們能發現應該在哪些地方進行發力，以及哪些方法是現實的而非理想化的。

首先，是非穩態的避免。對於大規模分佈式系統來説，完全避免非穩態是不現實的。系統本質上是面臨無限觸發源的複雜網絡，其中HA機制更是一把雙刃劍。它們從根本上是具有內在不穩定性的脆弱管道的級聯。

儘管如此，我們仍然可以通過一些措施提升系統進入不穩定狀態的閾值，使其更難進入不穩定狀態，在面對更多觸發源時能從容地運行。

接下來，我們思考能否消除所有觸發源。實際上，這是完全不可行的。觸發源對應的是一個無限的開放空間，不可枚舉——包括網絡抖動、流量尖刺、軟件缺陷、硬件故障以及無數其他不可預測的因素。

雖然我們可以通過設計冗餘機制來減輕干擾對系統穩定性的影響，但這種方法有兩個主要侷限性：首先是巨大的成本。例如，在網絡基礎設施層實施冗餘鏈路聚合，在數據中心基礎設施層面建設多套製冷系統，等等。而且，建設冗餘機制往往涉及跨職能基礎設施工程工作，實施困難且超出SRE的職責範疇。

接下來，我們能否消除自強化反饋迴路呢？不可行！因為這些迴路與HA機制內在相關，迫使我們必須做出權衡。

然而，將緩解機制嵌入到反饋迴路內部，通過改變微觀層面的反饋結構，可以將指數級放大轉化為線性、可控的影響，大大降低其破壞力。就像用控制棒來阻止核反應中失控的中子放大。

最後，我們來探討能否防止系統崩潰。這是可行的，主要通過兩種互補的方法：最大化可用吞吐量與構建彈性恢復機制。即使系統超越臨界閾值，我們仍可通過建立內部容錯機制與外部干預預案，避免系統全面崩潰，併為系統創造多次恢復機會。

經過以上分析，我們發現可以在這些關鍵點實施雪崩治理工作，如右圖所示。接下來，我們將詳細介紹我們的核心實踐。

09 我們的實踐

前面説過，由於觸發源眾多，無法逐一驗證系統在各種觸發源下的行為，因此我們將所有觸發源抽象為有限的幾類場景，確保系統在這些場景下保持穩定——最大限度保持好吞吐。

這些場景分為兩個維度：第一個維度是流量壓力：包括流量逐步上升和瞬時激增。第二個維度是系統容量變化：包括絕對容量減少（如服務下線）和相對容量退化（如響應變慢）。

針對這四類場景，我們直接在生產環境中進行系統化驗證：對於流量風險，我們在生產環境執行全鏈路壓測，模擬流量的漸進式增長和瞬時尖刺。對於容量問題，我們在生產環境開展混沌工程，在真實環境下模擬服務容量縮減和延遲注入。

通過生產環境驗證，我們提前發現潛在風險，確保系統在雪崩場景下保持最大可用吞吐的預期行為，結果可信且能代表實際系統性能。

早期檢測對雪崩預防至關重要。我們建立了全面的監控系統，跟蹤先導指標：

• 端到端失敗數量
• 所有服務的通用指標，包括實例健康狀態、實例CPU/內存/磁盤/IO利用率，以及coredump計數，等等
• 核心服務關鍵指標：包括請求隊列長度、線程利用率、分位點延遲，等等
• 分片服務：分片丟失率

所有指標都是以秒級實時進行監控，並建立預警策略，使我們能第一時間感知到異常。

我們對系統自身的改進是建設一系列的"自愈"能力。首先是"重試預算"，用於在client側就地收斂重試風暴。每個請求攜帶"全鏈路重試狀態"信息，RPC組件據此識別兩類重試：直接重試（本服務對下游）與間接重試（上游祖先節點發起）。RPC組件維護一個"預算池"，對兩類重試流量配置不同的預算閾值，超過預算即快速失敗。預算策略會隨後端服務容量自適應調整，以充分使用後端容量。該機制把自增負載限制在可控範圍內，避免指數級擴散。

在服務器端，我們還構建了一個稱為“隊列限流”的吞吐保護機制。我們將服務側的請求隊列做成多級優先級隊列，並設置限流器。請求入隊前先經過優先級過濾，在擁塞時，高優先級的請求允許通過，低優先級的請求被丟棄；限流器則根據實際處理速率自適應放行，同時，對於隊列中超時的請求也會及時排出。在server側容量到達瓶頸時，這套機制讓有限的算力用於處理“好吞吐”。

我們也在系統中建設了更精細化的減少無謂的算力浪費的機制，即，全局TTL控制。每個請求在入口獲得初始TTL，並隨着請求在全鏈路傳遞；在各處理階段結束後，按實際消耗的時間扣減TTL，並判斷剩餘值。若剩餘TTL仍然大於0，則將這個新TTL作為後續階段的TTL繼續傳遞；否則，立即在此位置結束並返回。

雖然自愈機制已經將雪崩風險降至非常低的水平，但我們仍然為極其罕見的雪崩場景設計了多維度的秒級干預系統。

第一個維度是跨數據中心流量切換。我們實時監控多個敏感指標，當發生異常時，全局流量控制器在一秒內將流量從受影響的IDC遷移到其他IDC。

第二個維度是系統流量降級。流量分為不同等級，非用户流量（緩存刷新、預取等）按層級逐步減少直至關閉，為更高價值的用户請求讓路。

第三個維度是架構裁剪。服務被分為不同級別（L2：低價值召回，L1：精確排序，L0：核心召回）。當損失發生時，我們做出秒級決策並按優先級逐步關閉服務級別。

第四個維度是超時套餐切換。多套系統級超時套餐根據損害程度自動適配，在吞吐和質量之間精妙地平衡。

10 治理結果

最後總結一下我們在治理雪崩上的成果。幾年前，雪崩給我們的系統帶來了比較多的PV損失，經過以上深入分析和系統治理，近幾年完全沒發生過雪崩，並且也幾乎沒有雪崩引起的PV損失。