斷路器Hystrix（四）

原創

2020-06-20 14:22

Netflix 創建了一個名爲 Hystrix 的庫，實現了斷路器的模式。“斷路器” 本身是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。當然，在請求失敗頻率較低的情況下，Hystrix 還是會直接把故障返回給客戶端。只有當失敗次數達到閾值時，斷路器打開並且不進行後續通信，而是直接返回備選響應。當然，Hystrix 的備選響應也是可以由開發者定製的。

雪崩效應：在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因 “服務提供者” 的不可用導致 “服務消費者” 的不可用，並將不可用逐漸放大的過程。

1.在Ribbon中使用斷路器

在已建立的服務service-ribbon中添加hystrix的依賴：

在程序的啓動類ServiceRibbonApplication 加@EnableHystrix註解開啓Hystrix：

在之前的RibbonService中加入如下代碼（主要是在helloService上添加了@HystrixCommand，該註解對該方法創建了熔斷器的功能，並指定了fallbackMethod熔斷方法“ribbonError”，熔斷方法即訪問服務失敗時做的處理，這裏只是簡單返回錯誤字符串）：

啓動服務，查看服務：http:localhost:7000

註冊中心上可以看到端口爲7001和7004的服務

訪問http://localhost:7004/helloRibbon?Name=ribbon

正常返回：

當關掉服務提供者的服務Eureka-producer，再次訪問http://localhost:7004/helloRibbon?Name=ribbon

瀏覽器返回熔斷方法ribbonError裏返回的內容：

這就說明當 eureka-producer 服務不可用的時候，service-ribbon調用 eureka-producer的API接口時，會執行快速失敗，直接返回一組字符串，而不是等待響應超時，這很好的控制了容器的線程阻塞。

2.在Feign中使用斷路器

Feign是自帶斷路器的，在D版本的Spring Cloud之後，它沒有默認打開。需要在配置文件中配置打開它：

基於service-feign服務的改造，在FeignService接口中加入fallback指定類

新建一個FeignServiceHystrix類，並注入ioc容器中，實現FeignService接口，重寫helloFeign方法，在其中返回調用失敗需要提示的錯誤，如下：

啓動並訪問：localhost:7005/helloFeign?name=feign 正常訪問並返回：

關閉eureka-produce服務，再才訪問localhost:7005/helloFeign?name=feign，瀏覽器返回helloFeign方法裏的返回內容，說明斷路器起作用了。

3.監控

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