今日目標

• 了解雪崩產生的原因
• 理解常見解決方案

隨著微服務架構的廣泛應用，應用程序的復雜性已經得到了顯著提高，但與之同時，微服務雪崩問題也開始引起廣泛關注。微服務雪崩是指在微服務架構中，一個或多個微服務出現故障或不可用時，導致整個系統的不穩定甚至崩潰。本文將介紹微服務雪崩的產生原因以及一些常見的解決方案。

1. 雪崩介紹

微服務中，服務間調用關系錯綜復雜，一個微服務往往依賴于多個其它微服務。

圖片

如圖，如果服務提供者I發生了故障，當前的應用的部分業務因為依賴于服務I，因此也會被阻塞。此時，其它不依賴于服務I的業務似乎不受影響。

圖片

但是，依賴服務I的業務請求被阻塞，用戶不會得到響應，服務器的這個線程不會釋放，于是越來越多的用戶請求到來，越來越多的線程會阻塞：

圖片

服務器支持的線程和并發數有限，請求一直阻塞，會導致服務器資源耗盡，從而導致所有其它服務都不可用，那么當前服務也就不可用了。

那么，依賴于當前服務的其它服務隨著時間的推移，最終也都會變的不可用，形成級聯失敗，雪崩就發生了：

圖片

總結雪崩產生原因

• 依賴關系復雜性： 在微服務架構中，各個服務之間存在復雜的依賴關系。如果一個服務出現故障，它可能會導致依賴于它的其他服務也無法正常工作。
• 大規模部署： 大規模部署意味著有大量的服務實例在運行，當其中一部分實例出現問題時，整個系統可能受到影響。
• 同時故障： 有時，多個服務可能因相同的原因（如硬件故障、網絡問題或配置錯誤）而同時故障，導致雪崩效應。
• 超時和重試： 如果某個服務在請求時長時間未響應，其他服務可能會發起重試請求，導致更多的負載，最終導致系統崩潰。
• 資源耗盡： 當某個服務的資源（如數據庫連接、線程池）被過度消耗時，它可能會無法響應請求，從而引發雪崩。

2. 雪崩解決方案

雪崩解決常見解決方案有以下幾種:

• 超時處理：對于每個微服務的請求，應該設置合理的超時時間。超時時間應該充分考慮服務的響應時間和業務需求，以避免等待時間過長導致的問題
• 艙壁模式（Bulkhead Pattern for Avalanche）:系統遇到雪崩風險時，通過隔離不同服務或組件，以防止一個故障或高負載情況影響整個系統的穩定性。是一種應對潛在雪崩的設計模式
• 限流（Rate Limiting）: 限流可以控制對服務的請求速率，確保不會超出服務的處理能力。這可以防止流量過多而導致系統崩潰
• 熔斷器模式（Circuit Breaker Pattern）：熔斷器模式是一種容錯模式，用于避免雪崩效應。熔斷器會監控服務的健康狀態，當服務連續出現故障或響應時間超過閾值時，熔斷器會打開，阻止進一步的請求流量流向該服務，從而保護系統的穩定性
• 降級策略（Fallback）： 降級是一種處理服務不可用或性能下降的策略，它允許系統在出現問題時提供有限但穩定的功能，而不是完全失敗。當服務出現問題時，降級策略可以返回默認值、緩存數據、執行備用操作或者提供一個基本的響應，以確保用戶仍然能夠訪問系統的一部分功能

2.1. 超時處理

針對服務調用增加超時機制(一般dubbo默認30s)，一旦超時自動釋放資源，因釋放資源較快一定程度可抑制資源耗盡問題。但如果在超時釋放的時間內陡增大量請求，依然會導致服務宕機不可用。

圖片

2.2. 艙壁模式（Bulkhead Pattern for Avalanche）

倉壁模式來源于船艙的設計：船艙都會被隔板分離為多個獨立空間，當船體破損時，只會導致部分空間進入，將故障控制在一定范圍內，避免整個船體都被淹沒。于此類似，我們可以限定每個業務能使用的線程數，避免耗盡整個服務器的資源，因此也叫線程隔離。

圖片

2.3. 熔斷器模式（Circuit Breaker Pattern）

熔斷器模式：由熔斷器統計業務執行的異常比例，如果超出閾值則會熔斷該業務，攔截訪問該業務的一切請求。

熔斷器會統計訪問某個服務的請求數量，異常比例

圖片

當發現訪問服務D的請求異常比例過高時，認為服務D有導致雪崩的風險，會攔截訪問服務D的一切請求，形成熔斷：

圖片

2.4. 限流

限流：限制業務訪問的QPS，避免服務因流量的突增而故障。

圖片

3.總結

雪崩問題:

• 微服務之間相互調用，因為調用鏈中的一個服務故障，引起整個鏈路都無法訪問的情況。

解決方案:

限流是對服務的保護，避免因瞬間高并發流量而導致服務故障，進而避免雪崩。是一種預防措施。

超時處理、線程隔離、降級熔斷是在部分服務故障時，將故障控制在一定范圍，避免雪崩。是一種補救措施。