服務容錯保護hystrix
hystrix服務降級
前言在微服務架構中，我們將系統拆分成了乙個個的服務單元，各單元應用間通過服務註冊與訂閱的方式互相依賴。由於每個單元都在不同的程序中執行，依賴通過遠端呼叫的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現呼叫故障或延遲，而這些問題會直接導致呼叫方的對外服務也出現延遲，若此時呼叫方的請求不斷增加，最後就會出現因等待出現故障的依賴方響應而形成任務積壓，執行緒資源無法釋放，最終導致自身服務的癱瘓，進一步甚至出現故障的蔓延最終導致整個系統的癱瘓。如果這樣的架構存在如此嚴重的隱患，那麼相較傳統架構就更加的不穩定。為了解決這樣的問題，因此產生了斷路器等一系列的服務保護機制。
針對上述問題，在spring cloud hystrix中實現了執行緒隔離、斷路器等一系列的服務保護功能。它也是基於netflix的開源框架 hystrix實現的，該框架目標在於通過控制那些訪問遠端系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。hystrix具備了服務降級、服務熔斷、執行緒隔離、請求快取、請求合併以及服務監控等強大功能。
接下來，我們就從乙個簡單示例開始對spring cloud hystrix的學習與使用。
動手試一試
在開始使用spring cloud hystrix實現斷路器之前，我們先拿之前實現的一些內容作為基礎，其中包括：
eureka-server工程：服務註冊中心，埠：1001
eureka-client工程：服務提供者，兩個例項啟動埠分別為2001
下面我們可以複製一下之前實現的乙個服務消費者：eureka-consumer-ribbon，命名為eureka-consumer-ribbon-hystrix。下面我們開始對其進行改在：
第一步：pom.xml的dependencies節點中引入spring-cloud-starter-hystrix依賴：
org.springframework.cloud
spring-cloud-starter-hystrix
第二步：在應用主類中使用@enablecircuitbreaker或@enablehystrix註解開啟hystrix的使用：
為了觸發服務降級邏輯，我們可以將服務提供者eureka-client的邏輯加一些延遲，比如：
hystrix斷路器
前言 在前面（hystrix服務降級）和（hystrix依賴隔離）中，我們對hystrix提供的服務降級和依賴隔離有了基本的認識。下面我們將繼續說說hystrix的另外乙個重要元件：斷路器。
斷路器
斷路器模式源於martin fowler的circuit breaker一文。「斷路器」本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，「斷路器」能夠及時的切斷故障電路，防止發生過載、發熱、甚至**等嚴重後果。
在分布式架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之後，通過斷路器的故障監控（類似熔斷保險絲），直接切斷原來的主邏輯呼叫。但是，在hystrix中的斷路器除了切斷主邏輯的功能之外，還有更複雜的邏輯，下面我們來看看它更為深層次的處理邏輯。
以在服務容錯保護（hystrix服務降級）一文中實現的服務降級例子為示例，我們來說說斷路器的工作原理。當我們把服務提供者eureka-client中加入了模擬的時間延遲之後，在服務消費端的服務降級邏輯因為hystrix命令呼叫依賴服務超時，觸發了降級邏輯，但是即使這樣，受限於hystrix超時時間的問題，我們的呼叫依然很有可能產生堆積。
這個時候斷路器就會發揮作用，那麼斷路器是在什麼情況下開始起作用呢？這裡涉及到斷路器的三個重要引數：快照時間窗、請求總數下限、錯誤百分比下限。這個引數的作用分別是：
• 快照時間窗：斷路器確定是否開啟需要統計一些請求和錯誤資料，而統計的時間範圍就是快照時間窗，預設為最近的10秒。
• 請求總數下限：在快照時間窗內，必須滿足請求總數下限才有資格根據熔斷。預設為20，意味著在10秒內，如果該hystrix命令的呼叫此時不足20次，即時所有的請求都超時或其他原因失敗，斷路器都不會開啟。
• 錯誤百分比下限：當請求總數在快照時間窗內超過了下限，比如發生了30次呼叫，如果在這30次呼叫中，有16次發生了超時異常，也就是超過50%的錯誤百分比，在預設設定50%下限情況下，這時候就會將斷路器開啟。
那麼當斷路器開啟之後會發生什麼呢？我們先來說說斷路器未開啟之前，對於之前那個示例的情況就是每個請求都會在當hystrix超時之後返回fallback，每個請求時間延遲就是近似hystrix的超時時間，如果設定為5秒，那麼每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20，並且錯誤百分比超過50%，這個時候熔斷器開啟。開啟之後，再有請求呼叫的時候，將不會呼叫主邏輯，而是直接呼叫降級邏輯，這個時候就不會等待5秒之後才返回fallback。通過斷路器，實現了自動地發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。
在斷路器開啟之後，處理邏輯並沒有結束，我們的降級邏輯已經被成了主邏輯，那麼原來的主邏輯要如何恢復呢？對於這一問題，hystrix也為我們實現了自動恢復功能。當斷路器開啟，對主邏輯進行熔斷之後，hystrix會啟動乙個休眠時間窗，在這個時間窗內，降級邏輯是臨時的成為主邏輯，當休眠時間窗到期，斷路器將進入半開狀態，釋放一次請求到原來的主邏輯上，如果此次請求正常返回，那麼斷路器將繼續閉合，主邏輯恢復，如果這次請求依然有問題，斷路器繼續進入開啟狀態，休眠時間窗重新計時。
通過上面的一系列機制，hystrix的斷路器實現了對依賴資源故障的埠、對降級策略的自動切換以及對主邏輯的自動恢復機制。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護，同時對於一些具備降級邏輯的業務需求可以實現自動化的切換與恢復，相比於設定開關由監控和運維來進行切換的傳統實現方式顯得更為智慧型和高效。
服務容錯保護（Hystrix服務降級）
在微服務架構中，我們將系統拆分成了乙個個的服務單元，各單元應用間通過服務註冊與訂閱的方式互相依賴。由於每個單元都在不同的程序中執行，依賴通過遠端呼叫的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現呼叫故障或延遲，而這些問題會直接導致呼叫方的對外服務也出現延遲，若此時呼叫方的請求不斷增加，...
服務容錯保護（5 服務熔斷）
當請求後端服務失敗數量超過一定比例 預設50 斷路器會切換到開路狀態 open 這時所有請求會直接失敗而不會傳送到後端服務.斷路器保持在開路狀態一段時間後 預設5秒 自動切換到半開路狀態 half open 和服務降級很相似，但是服務降級沒有熔斷策略的設定。斷路器確定是否開啟需要統計一些請求和錯誤資...
Hystrix微服務容錯率和監控
由於整個專案是由多個微服務組成的，並且呼叫關係非常複雜，乙個大的專案可能由幾十個幾百個甚至幾千個微服務組成，某個微服務如果在某個節點執行緩慢，或者出現其他問題，由於呼叫關係複雜，有可能造成大面積癱瘓，也就是說會產生雪崩效應 hystrix主要是為了在某個微服務出現故障的時候，不至於影響其他服務，產生...