1. 回顧服務器
前面已用Eureka實現了微服務的註冊與發現，Ribbon實現了客戶端側的負載均衡，Feign實現了聲明式的API調用。網絡
2. 實現容錯的手段架構
若是服務提供者響應很是慢，那麼消費者對提供者的請求就會被強制等待，知道提供者響應或超時。併發
在高負載場景下，若是不作任何處理，此類問題可能會致使服務消費者的資源耗竭甚至整個系統的崩潰。負載均衡
例如，曾經發生過一個案例——某電子商務網站在一個黑色星期五發生過載。過分的併發請求，致使用戶支付的請求延遲好久微服務
都沒有響應，在等待很長時間後最終失敗。支付失敗又致使用戶從新刷新頁面並再次嘗試支付，進一步增長了服務器的負載，網站
最終整個系統都崩潰了。spa
當依賴的服務不可用時，服務自身會不會被拖垮？這是咱們要考慮的問題。線程
3. 雪崩效應代理
微服務架構的應用系統一般包含多個服務層。微服務之間經過網絡進行通訊，從而支撐起整個應用系統，所以，微服務之間不免存在
依賴關係。任何微服務都並不是100%可用，網絡每每也很脆弱，所以不免有些請求會失敗。
咱們常把「基礎服務故障」致使「級聯故障」的現象稱爲雪崩效應。雪崩效應描述的是提供者不可用致使消費者不可用，並將不可用逐漸放大的過程。
好比，A做爲服務提供者（基礎服務），B做爲A的服務消費者，C和D是B的服務消費者。當A不可用引發B的不可用，並將不可用像滾雪球同樣
放大到C和D時，雪崩效應就造成了。
4. 如何容錯
要想防止雪崩效應，必須有一個強大的容錯機制。該容錯機制需實現如下兩點。
- 爲網絡請求設置超時
正常狀況下，一個遠程調用通常在幾十毫秒內就能獲得響應了。若是依賴的服務不可用或網絡有問題，那麼響應時間就會變得很長（幾十秒）
一般狀況下，一次遠程調用對應着一個線程/進程。若是響應太慢，這個線程/進程就得不到釋放。而線程/進程又對應着系統資源，
若是得不到釋放的線程/進程越積越多，資源就會逐漸會耗盡，最終致使服務的不可用。
所以，必須爲每一個網絡請求設置超時，讓資源儘快釋放。
- 使用斷路器模式
若是對某個微服務的請求有大量超時（經常說明該微服務不可用），再去讓新的請求訪問該服務已經沒有任何意義，只會無謂耗費資源。
例如，設置了超時時間爲1秒，若是短期內有大量的請求沒法在1秒內獲得響應，就沒有必須再去請求依賴的服務了。
斷路器可理解爲對容易致使錯誤的操做的代理。這種代理可以統計一段時間內調用失敗的次數，並決定是正常請求依賴的服務仍是直接返回。
斷路器可實現快速失敗，若是它在一段時間內檢測到許多相似的錯誤（例如超時），就會在以後的一段時間內，強迫對該服務的調用快速失敗，
即再也不請求所依賴的服務。這樣，應用程序就無需再浪費CPU時間去等待長時間的超時。
斷路器也可自動診斷依賴的服務是否已經恢復正常。若是發現依賴的服務已經恢復正常，那麼就會恢復請求該服務。使用這種方式，
就能夠實現微服務的「自我恢復」——當依賴的服務不正常時打開斷路器時快速失敗，從而防止雪崩效應；當發現依賴的服務恢復正常時，
又會恢復請求。
斷路器的大體流程以下：
> 正常狀況下，斷路器關閉，可正常請求依賴的服務。
> 當一段時間內，請求失敗率達到必定閾值（例如錯誤率達到50%，或100次/分鐘等），斷路器就會打開。此時，不會再去請求依賴的服務。
> 斷路器打開一段時間後，會自動進入「半開」狀態。此時，斷路器可容許一個請求訪問依賴的服務。
若是該請求可以調用成功，則關閉斷路器；不然繼續保持打開狀態。
5. 總結
本文講解了容錯機制的重要性，以及一個良好的容錯機制應該實現哪些功能。
下文將講解使用Hystrix實現容錯。敬請期待~~~
6. 參考
周立 --- 《Spring Cloud與Docker微服務架構與實戰》