javascript
Spring Cloud构建微服务架构:服务容错保护(Hystrix断路器)
斷路器
斷路器模式源于Martin Fowler的Circuit Breaker一文。“斷路器”本身是一種開關裝置,用于在電路上保護線路過載,當線路中有電器發(fā)生短路時,“斷路器”能夠及時的切斷故障電路,防止發(fā)生過載、發(fā)熱、甚至起火等嚴重后果。
在分布式架構中,斷路器模式的作用也是類似的,當某個服務單元發(fā)生故障(類似用電器發(fā)生短路)之后,通過斷路器的故障監(jiān)控(類似熔斷保險絲),直接切斷原來的主邏輯調用。但是,在Hystrix中的斷路器除了切斷主邏輯的功能之外,還有更復雜的邏輯,下面我們來看看它更為深層次的處理邏輯。
以在《Spring Cloud構建微服務架構:服務容錯保護(Hystrix服務降級)》一文中實現(xiàn)的服務降級例子為示例,我們來說說斷路器的工作原理。當我們把服務提供者eureka-client中加入了模擬的時間延遲之后,在服務消費端的服務降級邏輯因為hystrix命令調用依賴服務超時,觸發(fā)了降級邏輯,但是即使這樣,受限于Hystrix超時時間的問題,我們的調用依然很有可能產生堆積。
這個時候斷路器就會發(fā)揮作用,那么斷路器是在什么情況下開始起作用呢?這里涉及到斷路器的三個重要參數(shù):快照時間窗、請求總數(shù)下限、錯誤百分比下限。這個參數(shù)的作用分別是:
- 快照時間窗:斷路器確定是否打開需要統(tǒng)計一些請求和錯誤數(shù)據(jù),而統(tǒng)計的時間范圍就是快照時間窗,默認為最近的10秒。
- 請求總數(shù)下限:在快照時間窗內,必須滿足請求總數(shù)下限才有資格根據(jù)熔斷。默認為20,意味著在10秒內,如果該hystrix命令的調用此時不足20次,即時所有的請求都超時或其他原因失敗,斷路器都不會打開。
- 錯誤百分比下限:當請求總數(shù)在快照時間窗內超過了下限,比如發(fā)生了30次調用,如果在這30次調用中,有16次發(fā)生了超時異常,也就是超過50%的錯誤百分比,在默認設定50%下限情況下,這時候就會將斷路器打開。
那么當斷路器打開之后會發(fā)生什么呢?我們先來說說斷路器未打開之前,對于之前那個示例的情況就是每個請求都會在當hystrix超時之后返回fallback,每個請求時間延遲就是近似hystrix的超時時間,如果設置為5秒,那么每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發(fā)現(xiàn)請求總數(shù)超過20,并且錯誤百分比超過50%,這個時候熔斷器打開。打開之后,再有請求調用的時候,將不會調用主邏輯,而是直接調用降級邏輯,這個時候就不會等待5秒之后才返回fallback。通過斷路器,實現(xiàn)了自動地發(fā)現(xiàn)錯誤并將降級邏輯切換為主邏輯,減少響應延遲的效果。
在斷路器打開之后,處理邏輯并沒有結束,我們的降級邏輯已經被成了主邏輯,那么原來的主邏輯要如何恢復呢?對于這一問題,hystrix也為我們實現(xiàn)了自動恢復功能。當斷路器打開,對主邏輯進行熔斷之后,hystrix會啟動一個休眠時間窗,在這個時間窗內,降級邏輯是臨時的成為主邏輯,當休眠時間窗到期,斷路器將進入半開狀態(tài),釋放一次請求到原來的主邏輯上,如果此次請求正常返回,那么斷路器將繼續(xù)閉合,主邏輯恢復,如果這次請求依然有問題,斷路器繼續(xù)進入打開狀態(tài),休眠時間窗重新計時。
通過上面的一系列機制,hystrix的斷路器實現(xiàn)了對依賴資源故障的端口、對降級策略的自動切換以及對主邏輯的自動恢復機制。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護,同時對于一些具備降級邏輯的業(yè)務需求可以實現(xiàn)自動化的切換與恢復,相比于設置開關由監(jiān)控和運維來進行切換的傳統(tǒng)實現(xiàn)方式顯得更為智能和高效。Spring Cloud大型企業(yè)分布式微服務云架構源碼請加企鵝求求:一七九一七四三三八零
轉載于:https://www.cnblogs.com/sunnysunny/p/10552654.html
總結
以上是生活随笔為你收集整理的Spring Cloud构建微服务架构:服务容错保护(Hystrix断路器)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: [2019.1.14]BZOJ2005
- 下一篇: ElasticSearch 2.2 升级