爲什麼要使用斷路器Hystrix?
在微服務架構中，我們將業務拆分成一個個的服務，服務與服務之間可以相互調用（RPC）。爲了保證其高可用，單個服務有必須集羣部署。由於網絡原因或者自身的原因，服務並不能保證服務的100%可用，如果單個服務出現問題，調用這個服務就會出現網絡延遲，此時若有大量的網絡湧入，會形成任務累計，導致服務癱瘓，甚至導致服務“雪崩”。爲了解決這個問題出現了短路器，相當於現實生活中的保險絲。
什麼是服務雪崩？
多個服務之間調用的時候，假設服務A調用服務B和服務C，服務B和服務C又調用其他的服務，這就是所謂的“扇出”。如果“扇出”的鏈路上某個服務調用響應時間過長或者不可用，對服務A的調用就會佔用越來越多的系統資源，
進而引起系統崩潰，所謂的 “ 雪崩效應 ”。
對於高流量的應用來說，單一的後端依賴可能會導致所有服務器上的所有資源都在幾秒鐘內飽和。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關係的失敗，不能取消整個應用程序或系統。
所以，通常當你發現一個模塊下的某個實例失敗後，這時候這個模塊依然還會接受流量，然後這個有問題的模塊還調用了其他的模塊，這樣就會發生級聯故障，或者叫 雪崩。
要避免這樣的級聯故障，就需要有一種鏈路中斷的方案：
服務降級、服務熔斷
Hystrix 簡介：
Hystrix是一個用於處理分佈式系統的延遲和容錯的開源庫，在分佈式系統裏，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，已提高分佈式系統的彈性。
“ 斷路器 ” 本身是一種開關裝置，當某個服務單元發送故障之後，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。
Hystrix重要概念：
1.服務降級：
服務器忙，請稍後再試，不讓客戶端等待並立刻返回一個友好提示，fallback
哪些情況會發出降級？
程序運行異常
超時
服務熔斷觸發服務降級
線程池 / 信號量打滿也會導致服務降級
2.服務熔斷
類似保險絲達到最大服務訪問後，直接拒絕訪問，拉閘限電，然後調用服務降級的方法並返回友好提示
3.服務限流
秒殺高併發等操作，嚴禁一窩蜂的過來擁擠，大家排隊，一秒鐘N個，有序進行
配置項目：
需要在啓動類配置的註解爲：
@EnableHystrix
業務代碼爲：
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentTimeOutFallBackMethod", commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
})
public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
return paymentHystrixService.paymentInfo_TimeOut(id);
}
配置的文件爲application.yml：
feign:
hystrix:
enabled: true
一般都是在消費端配置斷路器，因爲不用來回傳值。