1、微服務故障背景
假設Tomcat線程池有100個線程， 每次有新的用戶請求過來，Tomcat就會從中找出一個空閒的線程去執行， 拋開那些瑣碎的小細節，這些請求其實非常簡單， 無非就是這麼幾件事：
- 根據用戶ID調用用戶服務， 獲取用戶對象。
- 獲取該用戶的推薦商品
- 獲取該用戶的積分。
- 把這些信息組合起來，返回給瀏覽器。
有意思的是前三件事情全是HTTP調用，需要調用某個地方的所謂“微服務”：
比如線程A執行到“推薦服務”時，推薦服務沒有立刻返回，導致推薦服務掛起，隨着新用戶請求的增加，線程池被耗完，那麼Tomcat只能“系統繁忙、暫停營業”。雖然重啓可能暫時解決問題，但問題可能還會重現。
2 隔離
怎麼把一個微服務的故障給隔離起來呢？讓他們互不影響呢？
Netflix的程序員們想了一個點子， 對每個微服務，都分配一個線程池，像這樣：
比如說調用“推薦服務”的時候，就會從“推薦服務線程池” （假設有5個線程）中找到一個線程執行。如果這個HTTP系統調用遲遲沒有返回，那這個線程就會一直等待，新的請求就需用使用池中別的線程。
如果5個“推薦服務”線程被耗光，可以人爲這個服務不可用，需立即返回。
這些新的線程池，是一種隔離的手段， 一個微服務一旦出了問題，很快就會被識別出來。
3 熔斷
所以Netflix的程序員又想了一個辦法：使用熔斷器（也叫斷路器），注意：當這個熔斷器關閉的時候，外面的請求可以直接調用，如果打開，就把外界的請求給阻斷了。
具體的做法：系統會檢測請求失敗的比率（失敗數/總請求數）， 一旦這個比率達到一個閾值的時候，熔斷器就開啓， 直接拒絕執行用戶請求。然後休眠一段時間，嘗試放過一部分流量（比如一個請求），如果調用成功，熔斷器閉合，恢復到正常狀態，否則繼續進行休眠週期。
熔斷機制狀態轉移圖如下：
主要在三種狀態中轉換：
關閉狀態 ：當熔斷器處於關閉狀態時，請求是可以被放行的；
當熔斷器統計的失敗次數觸發開關時，轉爲打開狀態。
打開狀態 ：當熔斷器處於打開狀態時，所有請求都是不被放行的，直接返回失敗；
只有在經過一個設定的時間窗口週期後，熔斷器纔會轉換到半開狀態
半開狀態 ：當熔斷器處於半開狀態時，當前只能有一個請求被放行；
這個被放行的請求獲得遠端服務的響應後，假如是成功的，熔斷器轉換爲關閉狀態，否則轉換到打開狀態。