使用微服務的好處多多，但也衍生出了各式各樣的問題，這樣就需要採取各種手段去完善微服務架構的思想，那為啥需要使用Hystrix斷路器呢？
以前的單體應用架構業務之間的調用都是在一個項目中確切的說是在一臺機器上面，而微服務各個業務之間的調用需要跨機器和跨網絡，這就出現了更多不可控因素，比如網絡突然出現異常，會出現連接超時，如果請求不多還好，請求多的話每個過來都超時都會創建大量的線程佔用服務器資源，甚至導致系統癱瘓，如果微服務之間調用鏈太多可能造成雪崩，理論上來說網絡都是穩定的，但是現實中誰也說不清，說不定被老鼠把網線咬了呢，等各種因素，對於這些太多的不可控因素，大佬們就提出了斷路器來避免這種雪崩的現象。
斷路器的思想和電路中的保險絲差不多，如果過載就會熔斷，微服務中的斷路器比保險絲的功能更加強大，可以實現線程隔離，信號量控制，線程數量控制，出現問題中斷，而且還可以在跳閘後嘗試請求，意思就是有1000個併發進來，如果在5秒內有20個請求出現問題了，那麼剩下的980個請求就會被攔截掉不讓其在去請求目標微服務，防止創建更多的線程，這就是線程隔離，如果過一段時間之後，斷路器會放行一兩個請求看看那個微服務好了沒，如果好了，就會持續的放開，這也是斷路器智能機制的一種體現，當然hystrix還有更多強大的功能，等待我們的挖掘。
使用斷路器的功能也很簡單
1、在個人中心微服務中添加斷路器依賴
org.springframework.cloud spring-cloud-starter-netflix-hystrix
2、修改UserCenterController類，添加斷路器註解
@DefaultProperties(defaultFallback = "fallback") 這個是默認回退註解 execution.isolation.thread.timeoutInMilliseconds 此屬性設置調用者觀察超時並離開命令執行的時間（以毫秒為單位） coreSize 此屬性設置核心線程池大小 maxQueueSize 此屬性設置實現的最大隊列大小 keepAliveTimeMinutes 此屬性設置保持活動時間，以分鐘為單位 queueSizeRejectionThreshold 此屬性設置隊列大小拒絕閾值 metrics.rollingStats.numBuckets 度量統計屬性 metrics.rollingStats.timeInMilliseconds 此屬性設置統計滾動窗口的持續時間（以毫秒為單位） 更多屬性在hystrix github上有更加詳細的說明，這裡只是簡單的介紹一下
3、修改用戶微服務加一個休眠時間或者錯誤代碼測試斷路器功能
為了測試可以在需要調用的微服務中寫一段錯誤代碼或者休眠來測試斷路器的功能
4、在UserCenterApplication啟動類添加啟用斷路器註解
5、啟動所有微服務，測試斷路器是否起作用了
6、在postman中調用被加了斷路器功能的接口
可以看到輸出了錯誤，說明斷路器起作用了，更多其他的測試可以自己玩一玩
7、文章源碼地址
關注+轉發後私信我源碼地址，感謝支持
加了斷路器後就可以有效防止因為網絡或者其他不可控因素出現大量請求堆積而造成系統資源佔用率過高問題，對於斷路器參數閾值的設置可以自己根據併發量調控，斷路器也是防止整個服務群出現雪崩的有效手段。
關鍵字: 超時 artifactId 調用
