在微服務架構中，一台服務往往會去遠端呼叫別的服務，但是如果別的服務出現了故障，或者因為網路問題導致遲遲沒有給出響應，這時我們的請求會一直佔據著資源，如果在高併發的時候，還會把服務壓垮，導致此服務不能使用，依賴於這個服務的所有服務都會出現問題，導致服務雪崩。
為了解決這一的問題，hystrix解決的方案有兩種：
執行緒隔離，服務降級
服務熔斷
hystrix為每個服務開啟了乙個執行緒池，當這個執行緒池已經滿了，後面再來的請求就會直接進行拒絕，預設情況不採用排隊。
因為分配了執行緒池，這個時候使用者請求不再直接訪問服務，而是交給執行緒池利用空閒的執行緒去進行訪問服務，如果執行緒池沒有空閒的執行緒，或者請求超時，都會進行降級處理（服務降級）。
觸發hystrix服務降級的情況：執行緒池已滿，請求超時
類似家裡的電路保險絲，如果電路發生短路，保險絲立刻就會斷開，後面的就不會再通電了。
在微服務中也是類似的效果，如果服務的呼叫方發現了某些服務反應很慢，或者連著不上去的時候，能夠主動熔斷，防止系統被拖垮。
在有些系統熔斷後不能自動重連，但是hystrix可以實現彈性容錯，當情況好轉後可以自動重連。
主要可以在熔斷後將後續的請求直接拒絕，一段時候後執行部分請求通過，如果呼叫成功則可以繼續使用，否則繼續斷開
熔斷狀態 會有三個狀態：
closed：關閉狀態，所有請求都可以正常訪問
open：開啟狀態，所有請求都會被降級，hystrix會根據請求情況進行技術，當一定時間內失敗的請求達到某個值的時候會觸發熔斷器，熔斷器就會開啟，預設比例是50%，請求次數不少於20次
half open：半開啟狀態，開啟狀態不是永久的（預設是5s），隨後熔斷器會進入半開狀態。此時部分請求會通過，如果這些請求都成功了，那麼就會關閉熔斷器，否則繼續開啟再次等待。
匯入依賴
>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-netflix-hystrixartifactid
>
dependency
>
在控制器上 新增註解@hystrixcommand(fallbackmethod = 「selectaddressfallback」)
3.1 其中fallbackmethod 指定的是方法，當遠端服務呼叫超時時，呼叫本服務的方法
3.2 註解上指定了超時後執行的方法能夠快速的給使用者反饋，避免瀏覽器一致轉圈圈
這個方法 返回型別和引數必須和請求方法一致
控制層**
@restcontroller
("address"
)@defaultproperties
(defaultfallback =
"selectaddressfallback"
)public
class
addresscontroller")
@hystrixcommand
public result
>
selectaddress
(@pathvariable
("parent_id"
)int parent_id)
throws ioexception
public result
>
selectaddressfallback()
throws ioexception
}
#配置hystrix的超時時間 為3秒
hystrix.command.default.execution.isolation.thread.timeoutinmilliseconds=3000
Spring Could之Ribbon負載均衡
當生產者有多個相同的serciceid的例項後，消費者從rureka中獲取的服務列表中就會包含多個服務例項，這個時候消費者怎麼樣去進行選擇使用哪乙個服務例項呢 ribbon會獲取到服務列表後，ribbon可以根據自己的負載均衡的演算法，自動的選擇某乙個服務去進行請求。ribbon本身也提供了一些負載...
SpringCould之熔斷器（四）
雪崩效應 在微服務架構中通常會有多個服務之間進行相互呼叫，基礎服務的故 障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務 雪崩效 應 服務雪崩效應是一種因 服務提供者 的不可用導致 服務消費者 的不可用,並將 不可用逐漸放大的過程。為解決 雪崩效應 微服務架構提供了一種了斷路器...
學習SpringCloud之斷路器Hystrix
以下示例均基於springcloud的greenwich.sr1版本。org.springframework.cloudgroupid spring cloud starter netflix hystrixartifactid dependency dependencies 以 enablehys...