一、Hystrix概述
熔斷器，斷路器，類似于家裡的保險絲，保證分布式服務的安全運作
1.1 服務雪崩
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導緻級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者"的不可用導緻“服務消費者”的不可用，并将不可用逐漸放大的過程。
如果下圖所示: A作為服務提供者，B為A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，并将不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
現實通常是更糟糕，當一切正常時，請求看起來是這樣的
把上面看成線程池或者tomcat，後面還有一個個的請求在排着隊等待處理
當其中有一個系統有延遲時，它可能阻塞整個使用者請求：
在高流量的情況下，一個後端依賴項的延遲可能導緻所有伺服器上的所有資源在數秒内飽和（PS：意味着後續再有請求将無法立即提供服務）
1.2 Hystrix作用
Hystrix是一個用于分布式系統的延遲和容錯的開源庫。在分布式系統裡，許多依賴不可避免的調用失敗，比如逾時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導緻整個服務失敗，避免級聯故障，以提高分布式系統的彈性（穩定性）。
阿裡有sentinel（SpringAlibaba），這裡講Netflix一套的Hystrix
1.2.1 服務降級
伺服器忙，請稍後再試，不讓用戶端等待并立刻傳回一個友好提示，fallback
哪些情況會出發降級：程式運作異常、逾時、服務熔斷觸發服務降級、線程池/信号量打滿也會導緻服務降級
類似于異常處理：沒有辦法傳回正常的結果（發生異常），給一個降級處理（有異常處理）
1.2.2 服務熔斷（降級到一定程度發生熔斷）
類比保險絲達到最大服務通路後，直接拒絕通路（無法請求），拉閘限電，然後調用服務降級的方法并傳回友好提示，就是保險絲：服務的降級->進而熔斷->恢複調用鍊路
1.2.3 服務限流（一般不用Hystrix）
還可以實作服務限流，替換産品較多，一般不用
二、服務降級
2.1 模拟高并發通路
8081
正常通路：8081調用兩個方法全是好的，7071調用8081的兩個方法，timeok是好的，timeout超過一秒報錯
模拟高并發通路8081的timeout
此時再去通路四種情況：8081的兩個方法還是好的，但在高并發的情況下處理時間明顯變長，極端情況下也會被拖死
而用7071去調用8081的timeok方法時已經報錯了，本來就處理的較慢，當高并發的情況下變得更慢，最終逾時。說明當一個服務依賴延遲時，其他正常的通路也會被影響，這就是服務雪崩。
當然7071去調用8081的timeout方法肯定還是報錯的，且響應時間更久。
2.2 處理方法
2.2.1 處理異常
在7071的controller加上異常處理
2.2.2 服務降級
你能想到的錯誤，你遇到過的錯誤可以用異常處理，但萬一出現你沒遇到過的異常狀況，還是要用服務降級來處理
2.2.2.1 添加依賴
理論上在生産者（8081）和消費者端（7071）都可以添加降級處理，一般在消費者端添加降級。
2.2.2.2 啟動類
2.2.2.3 配置檔案
#使用feign調用時啟用hystrix熔斷降級
feign:
hystrix:
enabled: true
2.2.2.4 使用方式
2.2.2.4.1 在每個方法上加降級方法（就是處理異常換個皮）
當發生降級時，去執行降級方法，方法名必須一緻
正常通路7071調用8081的timeout，出現逾時，執行降級方法timeoutfallback()
高并發通路7071調用8081的timeok，出現逾時，執行降級方法timeokfallback()
- 既然和異常處理差不多用異常處理不就好了，為什麼還要使用服務降級？
- 答：如果隻是為了降級，那麼換成異常處理也是可以的；但降級是可以可熔斷配合使用的，當一次處理不了我給你回報資訊，但每次都處理不了，降級的次數觸發太高，我就直接熔斷了，減少了伺服器性能的損耗，而異常處理是做不到熔斷的。
2.2.2.4.2 給一個controller的所有處理器方法指定一個統一的降級方法
- 在每個方法上打注解，不指定降級方法
- 在controller上打注解，指定整個controller的降級方法
- controller的方法隻要觸發降級就執行這個統一的降級方法
高并發測試
2.2.2.4.3 controller和降級方法可以分開單獨寫
建一個降級方法實作類去實作feign的Api類，并實作他的所有方法，就是降級方法
- 建實作類并實作方法為降級方法
- openfeign的api類打注解，找到這個降級方法類
注意：當有實作類時requestmapping不能定義在接口上，否則會報映射錯誤；因為你打在接口上，它的實作類也會有這個/stock路徑，是以真正執行調用方法時，此時會找到兩個有同樣路徑映射的實作類（Api接口底層會注入一個實作類），就會報路徑映射錯誤。是以用fallback實作類時，feign接口的路徑要都打在方法上。
高并發測試
2.2.2.5 配置降級觸發時間
注意：ribbon的預設逾時時間是1秒，但就算把時間配置超過1秒，也還是逾時。這是因為用了hystrix，降級的預設觸發時間也是1秒。是以二者通常搭配使用。
#之前配置的ribbon逾時時間
ribbon:
#建立連接配接後，從伺服器讀到可用資源的最長時間
ReadTimeout: 2000
#建立連接配接所用的最長時間，指網絡狀況正常的情況下兩端建立連接配接的時間
ConnectTimeout: 500
#配置降級的觸發時間
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 1500
#二者各管各的，通常一起搭配使用
三、服務熔斷
3.1 概述
熔斷機制是應對雪崩效應的一種微服務鍊路保護機制。
當扇對外連結路的某個微服務出錯不可用或者響應時間太長時，會進行服務的降級,進而熔斷該節點微服務的調用，快速傳回錯誤的響應資訊。
當檢測到該節點微服務調用響應正常後，恢複調用鍊路。
- Closed：關閉狀态（斷路器關閉），所有請求都正常通路。代理類維護了最近調用失敗的次數，如果某次調用失敗，則使失敗次數加1。如果最近失敗次數超過了在給定時間内允許失敗的門檻值，則代理類切換到斷開(Open)狀态。此時代理開啟了一個逾時時鐘，當該時鐘超過了該時間，則切換到半斷開（Half-Open）狀态。該逾時時間的設定是給了系統一次機會來修正導緻調用失敗的錯誤。
- Open：打開狀态（斷路器打開），所有請求都會被降級。Hystix會對請求情況計數，當一定時間内失敗請求百分比達到門檻值，則觸發熔斷，斷路器會完全關閉。預設失敗比例的門檻值是50%，請求次數最少不低于20次。
- Half Open：半開狀态，open狀态不是永久的，打開後會進入休眠時間（預設是5S）。随後斷路器會自動進入半開狀态。此時會釋放1次請求通過，若這個請求是健康的，則會關閉斷路器，否則繼續保持打開，再次進行5秒休眠計時。
3.2 斷路器的三個重要參數
涉及到斷路器的三個重要參數:快照時間窗、請求總數閥值、錯誤百分比閥值。
3.2.1快照時間窗
斷路器确定是否打開需要統計一些請求和錯誤資料，而統計的時間範圍就是快照時間窗，預設為最近的10秒。
3.2.2請求總數閥值
在快照時間窗内,必須滿足請求總數閥值才有資格熔斷。預設為20,意味着在10秒内,如果該hystrix指令的調用次數不足20次,即使所有的請求都逾時或其他原因失敗，斷路器都不會打開。
3.2.3錯誤百分比閥值
當請求總數在快照時間窗内超過了閥值，比如發生了30次調用，如果在這30次調用中，有15次發生了逾時異常，也就是超過50%的錯誤百分比，在預設設定50%閥值情況下，這時候就會将斷路器打開。
3.3 模拟熔斷
在7071建立一個controller
注意：降級不是隻能和feign一起使用，隻要會出現錯誤異常，都可以使用降級
這裡隻通路7071自己
多次通路/hy/test/0，都出錯都觸發降級，斷路器就會打開，此時正常通路/hy/test/1，也會直接給你降級方法，是對伺服器的一種保護
5秒過後會進入半開狀态，此時會放一個請求過來，請求成功，斷路器會關閉
3.4 配置斷路器屬性
四、HystrixDashboard
4.1 概述
Hystrix監控平台
SpringBoot支援監控資料的展示
①圓點：微服務的健康狀态，顔色有綠色、黃色、橙色、紅色，健康狀态依次降低
②線條：流量變化
③請求的方法
④成功請求（綠色）
⑤短路請求（藍色）
⑥壞請求（青色）
⑦逾時請求（黃色）
⑧被拒絕的請求（紫色）
⑨失敗請求（紅色）
⑩最近10秒鐘内請求錯誤的百分比
11請求頻率
12熔斷器狀态
13資料延遲統計
14線程池
4.2 建立監控微服務5051
展示Hystrix的監視資訊要再建一個5051項目
監控和被監控的項目都需要添加依賴
4.2.1 添加依賴
被監控項目7071
監控項目5051
4.2.2 監控項目5051配置檔案
4.2.3 監控項目5051的啟動類打注解
4.2.4 配置類
監控項目的配置類，配置一個servlet（Springboot的H版本必須添加這個配置，G不需要）
4.2.5 監控界面
在輸入框裡輸入你要監控的位址，顯示監控資訊