服務雪崩 （微服務面臨的問題）

多個微服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其它的微服務，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”.

對于高流量的應用來說，單一的后端依賴可能會導致所有服務器上的所有資源都在幾秒鐘內飽和。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關系的失敗，不能取消整個應用程序或系統。
所以，通常當你發現一個模塊下的某個實例失敗后，這時候這個模塊依然還會接收流量，然后這個有問題的模塊還調用了其他的模塊，這樣就會發生級聯故障，或者叫雪崩。

是什么？

Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統里，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分布式系統的彈性。

“斷路器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地占用，從而避免了故障在分布式系統中的蔓延，乃至雪崩。

哪些情況會出現降級

● 程序運行異常
● 超時
● 服務熔斷觸發服務降級
● 線程池/信號量打滿也會導致服務降級

服務熔斷

類比保險絲達到最大服務訪問后，直接拒絕訪問，拉閘限電，然后調用服務降級的方法并返回友好提示

服務的降級->進而熔斷->恢復調用鏈路

服務限流

秒殺高并發等操作，嚴禁一窩蜂的過來擁擠，大家排隊，一秒鐘N個，有序進行

模擬高并發（JMeter）

當大量的請求訪問到一個處理時間較長的服務時，大量線程占用導致一些簡單的服務在調用時出現卡頓或請求失敗

因此需要服務降級處理

解決

在調用方法上添加以下注解

@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")})

當響應時間超過3s調用fallbackMethod里方法（超時異常，運行異常等）

出現問題：每個業務方法對應一個兜底的方法，代碼膨脹

解決方法：統一和自定義的分開

定義一個全局反饋

@DefaultProperties(defaultFallback = "")

1：1 每個方法配置一個服務降級方法，技術上可以，實際上傻X

1：N 除了個別重要核心業務有專屬，其它普通的可以通過@DefaultProperties(defaultFallback = “”) 統一跳轉到統一處理結果頁面

通用的和獨享的各自分開，避免了代碼膨脹，合理減少了代碼量，O(∩_∩)O哈哈~

通配服務降級

在客戶端調用服務時服務宕機，則根據調用服務的方法，fallback其實現類中的對應方法

此時服務端provider已經down了，但是我們做了服務降級處理，讓客戶端在服務端不可用時也會獲得提示信息而不會掛起耗死服務器

服務熔斷

熔斷機制概述
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當扇出鏈路的某個微服務出錯不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回錯誤的響應信息。當檢測到該節點微服務調用響應正常后，恢復調用鏈路。

在Spring Cloud框架里，熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗，就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。

涉及到斷路器的三個重要參數：快照時間窗、請求總數閥值、錯誤百分比閥值。
1：快照時間窗：斷路器確定是否打開需要統計一些請求和錯誤數據，而統計的時間范圍就是快照時間窗，默認為最近的10秒。

2：請求總數閥值：在快照時間窗內，必須滿足請求總數閥值才有資格熔斷。默認為20，意味著在10秒內，如果該hystrix命令的調用次數不足20次，即使所有的請求都超時或其他原因失敗，斷路器都不會打開。

3：錯誤百分比閥值：當請求總數在快照時間窗內超過了閥值，比如發生了30次調用，如果在這30次調用中，有15次發生了超時異常，也就是超過50%的錯誤百分比，在默認設定50%閥值情況下，這時候就會將斷路器打開。

斷路器打開之后

1：再有請求調用的時候，將不會調用主邏輯，而是直接調用降級fallback。通過斷路器，實現了自動地發現錯誤并將降級邏輯切換為主邏輯，減少響應延遲的效果。

2：原來的主邏輯要如何恢復呢？
對于這一問題，hystrix也為我們實現了自動恢復功能。
當斷路器打開，對主邏輯進行熔斷之后，hystrix會啟動一個休眠時間窗，在這個時間窗內，降級邏輯是臨時的成為主邏輯，當休眠時間窗到期，斷路器將進入半開狀態，釋放一次請求到原來的主邏輯上，如果此次請求正常返回，那么斷路器將繼續閉合，主邏輯恢復，如果這次請求依然有問題，斷路器繼續進入打開狀態，休眠時間窗重新計時。

Hystrix圖形化Dashboard搭建

除了隔離依賴服務的調用以外，Hystrix還提供了準實時的調用監控（Hystrix Dashboard），Hystrix會持續地記錄所有通過Hystrix發起的請求的執行信息，并以統計報表和圖形的形式展示給用戶，包括每秒執行多少請求多少成功，多少失敗等。Netflix通過hystrix-metrics-event-stream項目實現了對以上指標的監控。Spring Cloud也提供了Hystrix Dashboard的整合，對監控內容轉化成可視化界面。

http://localhost:9001/hystrix

1：Delay：該參數用來控制服務器上輪詢監控信息的延遲時間，默認為2000毫秒，可以通過配置該屬性來降低客戶端的網絡和CPU消耗。

2：Title：該參數對應了頭部標題Hystrix Stream之后的內容，默認會使用具體監控實例的URL，可以通過配置該信息來展示更合適的標題。

注意：配置監控儀表盤需要在服務8001主啟動類中配置如下代碼：

/***此配置是為了服務監控而配置，與服務容錯本身無關，springcloud升級后的坑*ServletRegistrationBean因為springboot的默認路徑不是"/hystrix.stream"，*只要在自己的項目里配置上下面的servlet就可以了*/
@Bean
public ServletRegistrationBean getServlet() {HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);registrationBean.setLoadOnStartup(1);registrationBean.addUrlMappings("/hystrix.stream");registrationBean.setName("HystrixMetricsStreamServlet");return registrationBean;
}

填寫監控地址：http://localhost:8001/hystrix.stream

實心圓：共有兩種含義。它通過顏色的變化代表了實例的健康程度，它的健康度從綠色<黃色<橙色<紅色遞減。
該實心圓除了顏色的變化之外，它的大小也會根據實例的請求流量發生變化，流量越大該實心圓就越大。所以通過該實心圓的展示，就可以在大量的實例中快速的發現故障實例和高壓力實例。

曲線：用來記錄2分鐘內流量的相對變化，可以通過它來觀察到流量的上升和下降趨勢。