服務容錯保護（Hystrix服務降級）

在微服務架構中，我們將系統拆分成了乙個個的服務單元，各單元應用間通過服務註冊與訂閱的方式互相依賴。由於每個單元都在不同的程序中執行，依賴通過遠端呼叫的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現呼叫故障或延遲，而這些問題會直接導致呼叫方的對外服務也出現延遲，若此時呼叫方的請求不斷增加，最後就會出現因等待出現故障的依賴方響應而形成任務積壓，執行緒資源無法釋放，最終導致自身服務的癱瘓，進一步甚至出現故障的蔓延最終導致整個系統的癱瘓。如果這樣的架構存在如此嚴重的隱患，那麼相較傳統架構就更加的不穩定。為了解決這樣的問題，因此產生了斷路器等一系列的服務保護機制。

針對上述問題，在spring cloud hystrix中實現了執行緒隔離、斷路器等一系列的服務保護功能。它也是基於netflix的開源框架 hystrix實現的，該框架目標在於通過控制那些訪問遠端系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。hystrix具備了服務降級、服務熔斷、執行緒隔離、請求快取、請求合併以及服務監控等強大功能。

接下來，我們就從乙個簡單示例開始對spring cloud hystrix的學習與使用。

在開始使用spring cloud hystrix實現斷路器之前，我們先拿之前實現的一些內容作為基礎，其中包括：

下面我們可以複製一下之前實現的乙個服務消費者：eureka-consumer-ribbon，命名為eureka-consumer-ribbon-hystrix。下面我們開始對其進行改在：

第一步：pom.xml的dependencies節點中引入spring-cloud-starter-hystrix依賴：

org.springframework.cloud spring-cloud-starter-hystrix

第二步：在應用主類中使用@enablecircuitbreaker或@enablehystrix註解開啟hystrix的使用：

@enablecircuitbreaker
@enablediscoveryclient
@bean
@loadbalanced
public resttemplate resttemplate() 
public static void main(string args) 
}

@target()
@retention(retentionpolicy.runtime)
@documented
@inherited
@enablediscoveryclient
@enablecircuitbreaker
}

第三步：改造服務消費方式，新增consumerservice類，然後將在controller中的邏輯遷移過去。最後，在為具體執行邏輯的函式上增加@hystrixcommand註解來指定服務降級方法，比如：

@restcontroller
public class dccontroller 
class consumerservice 
public string fallback() 
}}

下面我們來驗證一下上面hystrix帶來的一些基礎功能。我們先把涉及的服務都啟動起來，然後訪問localhost:2101/consumer，此時可以獲取正常的返回，比如：services: [eureka-consumer-ribbon-hystrix, eureka-client]。

為了觸發服務降級邏輯，我們可以將服務提供者eureka-client的邏輯加一些延遲，比如：

public string dc() throws interruptedexception

重啟eureka-client之後，再嘗試訪問localhost:2101/consumer，此時我們將獲得的返回結果為：fallback。我們從eureka-client的控制台中，可以看到服務提供方輸出了原本要返回的結果，但是由於返回前延遲了5秒，而服務消費方觸發了服務請求超時異常，服務消費者就通過hystrixcommand註解中指定的降級邏輯進行執行，因此該請求的結果返回了fallback。這樣的機制，對自身服務起到了基礎的保護，同時還為異常情況提供了自動的服務降級切換機制。

服務容錯保護（Hystrix服務降級）

服務容錯保護Hystrix

服務容錯保護（5 服務熔斷）

Hystrix微服務容錯率和監控

服務容錯保護（Hystrix服務降級）

服務容錯保護Hystrix

服務容錯保護（5 服務熔斷）

Hystrix微服務容錯率和監控

相關推薦