微服務架構中熔斷和降級是保證服務高可用的一項重要功能點，微服務區別于一體化項目的最大區別也再于熔斷和降級，很多微服務項目的開發人員對熔斷的理解就是當服務不可用的時候，為了讓整體服務可以正常運行，需要讓后續的請求直接返回某個錯誤碼。

微服務中的熔斷是什么？

當電路中的負載過高的時候，“保險絲”就會熔斷。微服務的熔斷就如同保險絲一樣，當服務間的調用出現頻繁的超時，核心服務卻一直在等待這個超時服務的響應結果，后果就是整個系統服務的卡頓、無反應，這對于用戶端是不可接受的。所以熔斷就是某個服務發生不斷的調用響應超時的時候，就屏蔽掉這個服務，短路這個服務，不調用這個服務的具體內容直接返回一個默認值。

微服務中的降級是什么？

應該很多人都知道服務的限流吧，秒殺的時候，為了避免過高的并發壓垮服務，一般系統都會對秒殺的請求做限流處理。這個就是典型的降級處理。

為了保證核心服務的正常運行，會對一些服務、接口、頁面做降級處理，降級處理一般都是人工干預的，可以進行配置的。

熔斷和降級的區別？

相同點

• 都是為了保證服務的可用性，防止系統發生崩潰
• 都導致了系統的某些服務、功能不可用

不同點

• 熔斷是由某個下游服務故障引起的，降級一般從系統的整體負荷去考慮

Hystrix是怎么進行降級熔斷的？

hystrix可以做什么用？

使用斷路器隔離線程和信號量，提供實時的監控、報警。防止出現級聯故障、快速失敗和迅速恢復。

hystrix的隔離機制？

Hystrix是采用信號量/線程的方式進行資源的隔離，通過隔離限制依賴的并發量和阻塞擴散。

Hystrix 在用戶請求和服務之間增加了一個線程池，用戶的請求不會直接訪問服務，而是通過Hystrix分配的線程池中的空閑線程來訪問服務，如果線程池滿了，默認不采用排隊的方式，會直接進行降級處理。而且用戶的請求不會無休止的阻塞，至少都會存在一個執行的返回結果(可以是一個友好的提示)。

信號量模式下，執行業務的線程和請求線程是同一個，不存在線程上下文切換帶來的性能開銷，信號量阻斷并發訪問指的是當前信號量有多少就允許多少線程去訪問執行。

信號量的數量大小可以動態設置，線程池不允許。在使用線程池的時候，通過會通過自定義實現RequestInterceptor的接口來設置線程之間的請求頭一致(比如請求頭上攜帶的token)。

hystrix的熔斷機制

如果某個服務存在大量的調用超時，此時就會對該服務做熔斷處理，后續的所有請求都不在繼續調用這個服務，而是直接返回一個提示，快速失敗。間隔一段時間，如果目標服務情況好轉后再恢復調用。

Circuit Breaker熔斷器，熔斷器是在線程池/信號量之前的組件，用戶請求調用某一服務的時候，先經過熔斷器，假如熔斷器是打開的，則快速失敗，請求不會再進入線程池。

熔斷器相當于線程池之前的一個屏障，每個熔斷器都會記錄當前請求的調用成功、失敗、超時、拒絕的次數。

熔斷器存在三種狀態：

Closed 關閉狀態，調用失敗次數積累到了閾值(或一定比例)則啟動熔斷機制；

Open 打開狀態，這個時候對下游的調用都是內部直接返回錯誤，不走網絡，但設計了一個時鐘選項，默認的時鐘達到了一定時間(這個時間一般設置成平均故障處理時間，也就是MTTR)，到了這個時間，進入半熔斷狀態。

Half-Open 半熔斷狀態，允許定量的服務請求，如果調用都成功(或一定比例)則認為恢復了，關閉熔斷器，否則認為還沒好，又回到熔斷器打開狀態；

熔斷在調用的服務方法前增加注解

服務降級，在Feign組件里面新增一個fallbackFactory方法。

Hystrix流程圖

流程說明：

1、 每次調用的都會創建一個對象HystrixCommand，把依賴調用都封裝到run方法里面。

2、執行execute/queue做同步或者異步調用。判斷熔斷器是否打開，如果打開則直接做降級策略，如果關閉則進行后續步驟。

3、判斷線程池/信號量是否處于滿狀態，如果處于滿狀態則做降級策略，如果不是則調用對象HystrixCommand的run方法，執行業務邏輯。執行超時則降級處理。

4、計算熔斷器狀態，把所有的運行狀態上報熔斷器進行統計。

5、降級策略，拋出異常或者自定義處理方法。

Ribbon

在使用feign調用服務的時候，除了hystrix外還需要結合ribbon一起使用。通常ribbon起到的作用是設置連接時間、超時時間、調用服務的負載均衡等。

ribbon的一些配置：

#以下配置對服務hello-service-provider有效ribbon.eureka.enabled=true#建立連接超時時間，原1000ribbon.ConnectTimeout=60000#請求處理的超時時間，5分鐘ribbon.ReadTimeout=60000#所有操作都重試ribbon.OkToRetryOnAllOperations=true#重試發生，更換節點數最大值ribbon.MaxAutoRetriesNextServer=10#單個節點重試最大值ribbon.MaxAutoRetries=1

Feign組件為什么要用接口調用遠程接口呢？

feign是通過JDK的動態代理來實現的，對接口生成了對應的代理類進行請求處理和響應處理。

　feign＋ribbon使用的是RestTemplate來進行調用的，服務調用的時候IP＋port傳入的是服務名，需要去注冊中心換成真實的IP＋端口。在這個過程中，ribbon提供了一個負載均衡的處理方式LoadBalancerClient。

　其實流程就是：服務啟動的時候會注冊到注冊中心，ribbon會從注冊中心獲取到所有的服務列表和活躍的服務列表，當服務發生變化的時候，ribbon存在一個定時任務去獲取、比對服務列表。

?Feign在默認情況下使用的是JDK原生URLConnection發送HTTP請求，沒有連接池，但是對每個地址會保持一個長連接，即利用HTTP的persistence connection。我們可以用Apache的HTTP Client替換Feign原始的http client，從而獲取連接池、超時時間等與性能息息相關的控制能力。

　　　　 我是凱騰凱，互聯網浪潮下一枚茍且偷生的程序員

總結

以上是生活随笔為你收集整理的c3p0 服务启动获取连接超时_微服务架构中的熔断、降级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。