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