spring boot內建Hystrix
- 1. 什麼是Hystrix
- 2. Hystrix解決了什麼問題
- 3. Hystrix設計原則
- 4. Hystrix工作機制
- 5. RestTemplate和Ribbon使用Hystrix
- 5.1 建立項目
- 5.2 配置
- 5.3 添加注解
- 5.4 建立Ribbon配置
- 5.5 建立Ribbon Service
- 5.6 建立controller
- 5.7 驗證
- 6. 在Feign上使用熔斷器
- 6.1 建立項目
- 6.2 配置
- 6.3 添加注解
- 6.4 feign配置
- 6.5 feign調用
- 6.6 feign的hystrix處理
- 6.7 service
- 6.8 controller
- 6.9 驗證
- 7. RestTemplate和Feign對比
- 8. Hystrix Dashboard & RestTemplate
- 8.1 建立
- 8.2 配置
- 8.3 配置hystrix dashboard
- 8.4 配置ribbon
- 8.5 service
- 8.6 controller
- 8.7 注解
- 8.8 啟動
- 9. Hystrix Dashboard & Feign
- 9.1 建立
- 9.2 配置
- 9.3 配置hystrix dashboard
- 9.4 配置feign
- 9.5 dao.feign
- 9.6 hystrix.feign
- 9.7 service
- 9.8 controller
- 9.9 注解
- 9.10 啟動
- 10. Turbine聚合監控
- 10.1 建立
- 10.2 配置
- 10.3 啟動
git位址
https://github.com/a18792721831/studySpringCloud.git
1. 什麼是Hystrix
在分布式系統中，服務與服務之間的依賴錯綜複雜，一種不可避免的情況就是某些服務會出現故障，導緻依賴于它們的其他服務出現遠端排程的線程阻塞。Hystrix 是 Netflix公司開源的一個項目，它提供了熔斷器功能，能夠阻止分布式系統中出現關聯故障。Hystrix 是通過隔離服務的通路點阻止關聯故障的，并提供了故障的解決方案，進而提高了整個分布式系統的彈性。
2. Hystrix解決了什麼問題
在複雜的分布式系統中，可能有幾十個服務互相依賴，這些服務由于某些原因，例如機房的不可靠性、網絡服務商的不可靠性等，導緻某個服務不可用。如果系統不隔離該不可用的服務，可能會導緻整個系統不可用。
在高并發的情況下，單個服務的延遲會導緻整個請求都處于延遲狀态，可能在幾秒鐘就使整個服務處于線程負載飽和的狀态。
某個服務的單個點的請求故障會導緻使用者的請求處于阻塞狀态，最終的結果就是整個服務的線程資源消耗殆盡。由于服務的依賴性，會導緻依賴于該故障服務的其他服務也處于線程阻塞狀态，最終導緻這些服務的線程資源消耗殆盡，直到不可用，進而導緻整個問服務系統都不可用，即雪崩效應。
為了防止雪崩效應，因而産生了熔斷器模型。Hystrix 是在業界表現非常好的一個熔斷器模型實作的開源元件，它是Spring Cloud 元件不可缺少的一部分。
3. Hystrix設計原則
總的來說，Hystrix的設計原則如下。
- 防止單個服務的故障耗盡整個服務的Servlet容器（例如Tomcat）的線程資源。
- 快速失敗機制，如果某個服務出現了故障，則調用該服務的請求快速失敗，而不是線程等待。
- 提供回退（fallback）方案，在請求發生故障時，提供設定好的回退方案。
- 使用熔斷機制，防止故障擴散到其他服務。
- 提供熔斷器的監控元件Hystrix Dashboard，可以實時監控熔斷器的狀态。
4. Hystrix工作機制
首先，當服務的某個 API 接口的失敗次數在一定時間内小于設定的閥值時，熔斷器處于關閉狀态，該 API接口正常提供服務。當該API 接口處理請求的失敗次數大于設定的閥值時，Hystrix判定該API接口出現了故障，打開熔斷器，這時請求該 API 接口會執行快速失敗的邏輯（即 fallback 回退的邏輯），不執行業務邏輯，請求的線程不會處于阻塞狀态。處于打開狀态的熔斷器，一段時間後會處于半打開狀态，并将一定數量的請求執行正常邏輯。剩餘的請求會執行快速失敗，若執行正常邏輯的請求失敗了，則熔斷器繼續打開；若成功了，則将熔斷器關閉。這樣熔斷器就具有了自我像複的能力。
5. RestTemplate和Ribbon使用Hystrix
5.1 建立項目
5.2 配置
配置服務名稱，eureka server，日志等
配置eureka client服務提供者的連接配接名稱
5.3 添加注解
5.4 建立Ribbon配置
5.5 建立Ribbon Service
當Hystrix認為eureka client的服務提供者提供的服務不可用時，就會通路fallbackMethod的方法
5.6 建立controller
5.7 驗證
首先啟動eureka server
然後啟動本項目
注意，此時沒有啟動eureka client服務提供者，那麼服務是不可用的。
通路Hystrix的接口，會調用service裡面的fallbackMethod的方法。
接下來啟動eureka client 服務提供者。
此時服務可達，是以，此時應該能夠正确的通路的
當然，需要多試試，才能成功。
這就是Hystrix的自我修複。
将熔斷器設定為半開狀态，嘗試請求，成功就将服務設定可用，否則繼續熔斷。
6. 在Feign上使用熔斷器
6.1 建立項目
6.2 配置
6.3 添加注解
6.4 feign配置
6.5 feign調用
6.6 feign的hystrix處理
6.7 service
6.8 controller
開啟eureka client和feign
因為feign已經引入了hystrix的依賴，是以我們這裡開啟就行。
因為feign調用時寫的是接口，而hystrix的熔斷調用的方法就是實作了feign調用的接口的類。
同時這些類和接口需要被spring管理。
在feign調用的接口需要指定熔斷處理類…
6.9 驗證
啟動，首先需要啟動eureka-server和eureka client服務提供者
接着啟動feign-hystrix(也就是feign)
通路：
關閉eureka client服務提供者
就去調用熔斷處理的方法了。
7. RestTemplate和Feign對比
兩者都能實作熔斷處理。不過feign比RestTemplate更好。
- RestTemplate是使用寫死指定熔斷處理方法的，而feign則是指定類
- RestTemplate熔斷處理方法沒有限制，而feign則是實作接口，其方法已被定義
- RestTemplate請求單一，而feign有HttpUrlConnection,HttpClient,OkHttp多種方式
- RestTemplate需要自己增加依賴，而feign已內建，無需管理
- RestTemplate學習成本小于feign
8. Hystrix Dashboard & RestTemplate
8.1 建立
8.2 配置
8.3 配置hystrix dashboard
注意：
這裡的urlMapping就是熔斷器的中繼資料通路位址，如果不配置，會無法通路導緻異常。
當然也可以添加多個，比如
因為内部是一個list，不存在覆寫的問題
8.4 配置ribbon
8.5 service
8.6 controller
8.7 注解
8.8 啟動
注意，需要先啟動eureka server以及eureka client服務提供者。
剛開始沒有通路任何服務，此時eureka client還未擷取eureka server 服務清單。
接着通路hystrix dashboard的主界面
接着通路：
其實就是配置的url實際上是等價的。
9. Hystrix Dashboard & Feign
9.1 建立
9.2 配置
9.3 配置hystrix dashboard
9.4 配置feign
9.5 dao.feign
9.6 hystrix.feign
9.7 service
9.8 controller
9.9 注解
9.10 啟動
通路
這個就是中繼資料通路不到。
10. Turbine聚合監控
10.1 建立
10.2 配置
10.3 啟動
通路