將單體應用遷移到分布式框架后，很大可能會遇到這樣的問題：系統僅有一個控制單元，它會調用多個運算單元，如果某個運算單元（作為服務提供者）不可用，將導致控制單元（作為服務調用者）被阻塞，最終導致控制單元崩潰，進而導致整個系統都面臨着癱瘓的風險。
服務化后面臨的挑戰：
-
服務管理：敏捷迭代后的微服務可能越來越多，各個業務系統之間的交互也越來越多，如何做高效集群通信方案也是問題。
-
應用管理： 每個業務系統部署后對應着一個進程，進程可以啟停。如果機器掉電或者宕機了，如何做無縫切換都需要強大的部署管理機制。
-
負載均衡：為應對大流量場景及提供系統可靠性，同一個業務系統也會做分布式部署即一個業務實例部署在多台機器上。如果某個業務系統掛掉了，如何按需做自動伸縮分布式方案方案也需要考慮。
-
問題定位：單體應用的日志集中在一起，出現問題定位很方便，而分布式環境的問題定界定位，日志分析都較為困難。
-
雪崩問題：分布式系統都存在這樣一個問題，由於網絡的不穩定性，決定了任何一個服務的可用性都不是 100% 的。當網絡不穩定的時候，作為服務的提供者，自身可能會被拖死，導致服務調用者阻塞，最終可能引發雪崩效應。
Michael T. Nygard 在精彩的《Release It!》一書中總結了很多提高系統可用性的模式，其中非常重要的兩條是：使用超時策略和使用熔斷器機制。
-
超時策略：如果一個服務會被系統中的其它部分頻繁調用，一個部分的故障可能會導致級聯故障。例如，調用服務的操作可以配置為執行超時，如果服務未能在這個時間內響應，將回復一個失敗消息。然而，這種策略可能會導致許多並發請求到同一個操作被阻塞，直到超時期限屆滿。這些阻塞的請求可能會存儲關鍵的系統資源，如內存、線程、數據庫連接等。因此，這些資源可能會枯竭，導致需要使用相同的資源系統的故障。在這種情況下，它將是優選的操作立即失敗。設置較短的超時可能有助於解決這個問題，但是一個操作請求從發出到收到成功或者失敗的消息需要的時間是不確定的。
-
熔斷器模式：熔斷器的模式使用斷路器來檢測故障是否已得到解決，防止請求反復嘗試執行一個可能會失敗的操作，從而減少等待糾正故障的時間，相對與超時策略更加靈活。
雪崩問題的本質：
我們先來看一個分布式系統中常見的簡化的模型。Web服務器中的Servlet Container，容器啟動時后台初始化一個調度線程，負責處理Http請求，然后每個請求過來調度線程從線程池中取出一個工作者線程來處理該請求，從而實現並發控制的目的。
Servlet Container是我們的容器，如Tomcat。一個用戶請求有可能依賴其它多個外部服務。考慮到應用容器的線程數目基本都是固定的（比如Tomcat的線程池默認200），當在高並發的情況下，如果某一外部依賴的服務（第三方系統或者自研系統出現故障）超時阻塞，就有可能使得整個主線程池被占滿，增加內存消耗，這是長請求擁塞反模式（一種單次請求時延變長而導致系統性能惡化甚至崩潰的惡化模式）。
更進一步，如果線程池被占滿，那么整個服務將不可用，就又可能會重復產生上述問題。因此整個系統就像雪崩一樣，最終崩塌掉。
雪崩效應產生的幾種場景
-
流量激增：比如異常流量、用戶重試導致系統負載升高；
-
緩存刷新：假設A為client端，B為Server端，假設A系統請求都流向B系統，請求超出了B系統的承載能力，就會造成B系統崩潰；
-
程序有Bug：代碼循環調用的邏輯問題，資源未釋放引起的內存泄漏等問題；
-
硬件故障：比如宕機，機房斷電，光纖被挖斷等。
-
線程同步等待：系統間經常采用同步服務調用模式，核心服務和非核心服務共用一個線程池和消息隊列。如果一個核心業務線程調用非核心線程，這個非核心線程交由第三方系統完成，當第三方系統本身出現問題，導致核心線程阻塞，一直處於等待狀態，而進程間的調用是有超時限制的，最終這條線程將斷掉，也可能引發雪崩；
常見解決方案
針對上述雪崩情景，有很多應對方案，但沒有一個萬能的模式能夠應對所有場景。
-
針對流量激增，采用自動擴縮容以應對突發流量，或在負載均衡器上安裝限流模塊。
-
針對緩存刷新，參考Cache應用中的服務過載案例研究
-
針對硬件故障，多機房容災，跨機房路由，異地多活等。
-
針對同步等待，使用Hystrix做故障隔離，熔斷器機制等可以解決依賴服務不可用的問題。
通過實踐發現，線程同步等待是最常見引發的雪崩效應的場景。