Spring Cloud -- Hystrix服務熔斷
前言
上一篇，我們探討了Hystrix如何在Client端實現服務降級，這篇我們接續的來討論Hystrix的服務熔斷的功能。
服務熔斷的概念就好像是電線的保險絲一樣，保險絲的作用就是，當電線的電流即將過大超出電線可以負載的電量時，保險絲會提前燒斷，中斷這個線路，避免因電流過大引起火災，服務熔斷也是有相類似的功能，當系統接受到的訪問量達到最大量時，服務熔斷機制會啟動，直接拒絕訪問，並調用服務降級的方法返回一個友好提示。
熔斷機制概述
熔斷機制是一種應對服務雪崩效應的一種微服務鍊路保護機制，當扇出的某個微服務出錯不可用，或是回應時間過長，會進行服務的降級，進而熔斷該節點的微服務調用，快速返回錯誤相對應的回應訊息。而當再檢測到該微服務回復正常後，即恢復調用線路。
在Spring Cloud框架裡，熔斷機制通過Hystrix來實現，Hystrix會監控微服務調用的狀況，當失敗的呼叫到達一定的數值，就會啟動熔斷機制。
Hystrix服務熔斷案例
1. 首先，我們來針對hystrix-payment8001來做修正
2. 找到PaymentService，加入以下服務熔斷的模擬程式
運作流程如下：
(1). 請求呼叫次數是否已達設定次數 ( HystrixCommandProperties.circuitBreakerRequestVolumeThreshold() ) 這裡設定10次
(2). 請求呼叫設定次數內的錯誤次數是否已達設定的百分比內 ( HystrixCommandProperties.circuitBreakerErrorThresholdPercentage() ) 這裡設定為超過60% (6次)則開啟斷路器
(3). 若超過設定次數，斷路器(circuit-breaker)由CLOSED轉變成OPEN
(4). 超過斷路器設定的開啟時間後 ( HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds() )會先將狀態轉呈半開HALF-OPEN來確認是否還有錯誤，若仍有錯誤，則斷路器維持OPEN，若已無偵測到錯誤，斷路器即轉變為CLOSED，並且由第(1)步，循環反覆的執行。
3. 找到PaymentController，加入測試的服務熔斷Controller
4. 啟動Eureka 7001、hystrix-payment8001兩個微服務
5. 在網頁上開啟 http://localhost:8001/payment/circuit/31 ，我們可以看到因為id=31是正常的值，因此我們顯示正確的畫面
6. 再來，我們給一個id為負數的值，可以看到顯示錯誤的畫面
7. 接下來，我們很快的連續重新整理(最好超過10次)，都是給id為負數的值，可以看到一直都是錯誤的畫面，這時，我們再將id給一個正常的值，可以看到，因為錯誤次數已經超過設定的次數，熔斷器OPEN的狀況下，即使是輸入正確的值，還是一樣顯示錯誤畫面
8. 然後，我們再連續給幾次正確的值，多按幾次後，才會回到正確的畫面，可以看到HALF_OPEN運作後，確定系統已恢復正常，才讓原本應該運作的系統恢復調用
以上，就是本次Hystrix 服務熔斷的案例分享，下一篇我們會繼續探討Hystrix的圖形化Dashboard搭建及實作，文章中若有疏漏，也歡迎各位前輩不吝指教，謝謝大家~
參考文獻
尚硅谷Spring Cloud教程
https://github.com/Netflix/Hystrix/wiki/How-To-Use
