微服務架構系統靈活性，健壯性，擴充套件性好，特別適合需求變化迅速的場景。但系統複雜度高，部署，管理難度大。微服務除了開發期框架之外，還有需要一系列的執行期中介軟體支撐，如API閘道器，服務註冊中心，統一配置中心等。 目前國內比較成熟的吧，東軟有一支團隊在做，他們網站是 https://platform.neusoft.com/

在分散式系統都存在這樣一個問題，由於網路的不穩定性，任何一個服務的可用性都無法做到100% 。當網路不穩定時，作為服務的提供者，自身可能會被拖死，導致服務呼叫者阻塞，最終可能引發雪崩效應。

我們先來看一個分散式系統中常見的簡化模型。Web伺服器中的容器啟動時後臺初始化一個排程執行緒，這個執行緒主要負責處理Http請求，排程執行緒從執行緒池中取出一個工作者執行緒來處理該請求，從而實現併發控制的目的。

Servlet Container是我們的容器，如Tomcat、Netty等。一個使用者請求有可能依賴其它多個外部服務。考慮到應用容器的執行緒數基本都是固定的（比如Tomcat的執行緒池預設200），那麼在高併發場景下，如果某一個依賴的外部服務超時阻塞，就有可能使得整個主執行緒池打滿，增加記憶體消耗。

更進一步，如果執行緒池被佔滿，那麼整個服務將不可用，繼而會重複產生上述問題。整個系統就像雪崩一樣，最終崩掉。

流量激增：比如異常流量、使用者重試導致系統負載升高；

快取重新整理：假設A為客戶端，B為伺服器端，我們假設A的請求都流向B，如果請求超出了B的負載，就會造成B系統崩潰；

程式有Bug：程式碼迴圈呼叫的邏輯問題，資源未釋放引起的記憶體洩漏等問題；

硬體故障：比如宕機，機房斷電，光纖被挖斷等；

執行緒同步等待：系統間經常採用同步服務呼叫模式，核心服務和非核心服務共用一個執行緒池和訊息佇列。如果一個核心業務執行緒呼叫非核心執行緒，這個非核心執行緒交由第三方系統完成，當第三方系統本身出現問題，導致核心執行緒阻塞，一直處於等待狀態，而程序間的呼叫是有超時限制的，最終這條執行緒將斷掉，也可能引發雪崩。

針對上述雪崩情景，有很多對應的解決方案，但沒有一個萬能的模式能夠應對所有場景。

針對流量激增，採用自動擴縮容以應對突發流量，或在負載均衡器上安裝限流模組；

針對硬體故障，多機房容災，跨機房路由，異地多活等；

針對同步等待，使用Hystrix進行故障隔離、熔斷器機制等，可以解決依賴服務不可用的問題。