雪崩效應
現(xiàn)如今SOA、微服務風愈演愈烈，越來越多的業(yè)務和資源被以服務的形式包裝和發(fā)布，服務間又可能會依賴其他各種服務。由此而來不可避免的會產(chǎn)生很多問題。
比如一個服務，其依賴了另外30個服務。假設每個服務的可用率都有三個9（99.9%），那么我們計算一下：
99.99%^30 = 99.7%
現(xiàn)實很殘酷，這個服務的實際可用性只能是99.7%，也就是說每個月這個服務都要好宕機8000+秒~~~
正常用戶請求時，服務內(nèi)部依次請求A\P\H\I服務，兵返回響應結果。
非常不幸，我們的I服務出了某些問題，此時我們的用戶請求就被堵塞在I服務處。
更加悲劇的是，后續(xù)越來越多的請求都被堵塞在I服務處，而這些被堵塞的請求會占用線程、IO、網(wǎng)絡等系統(tǒng)資源，隨著資源被占用的越來越多，本來不存在的性能問題也會隨之而來，造成系統(tǒng)中的其他服務出現(xiàn)問題，甚至導致系統(tǒng)奔潰。
這也就是我們常說的雪崩效應
服務容災
為了避免出現(xiàn)服務的雪崩，我們需要對服務做容災處理。
常規(guī)的服務容災處理思路有：
資源隔離
超時設定
服務降級
服務限流
其中每種思路又可以有不同的解決方案。
比如資源隔離可以通過將不同的服務發(fā)布在獨立的docker容器或服務器中，這樣即使一個服務出現(xiàn)問題，也不會殃及池魚。
服務降級和服務限流可以通過前端nginx+lua來實現(xiàn)，當服務處理延遲或宕機時，nginx可以直接返回固定的降級/失敗響應，已快速跳過問題服務。
Hystrix
Hystrix，是Netflix的一個開源熔斷器，通過Hystrix，我們可以很方便的實現(xiàn)資源隔離、限流、超時設計、服務降級等服務容災措施，并且還提供了強大的監(jiān)控，可
