Spring Cloud - Hystrix的真情獨白

在這裏插入圖片描述

關於麥洛

Michael Scharhag
麥洛是 Java 開發者和技術愛好者。 對 Java 相關技術特別感興趣,包括 javaee、 Spring系列、 微服務等

文章出處:What Is Hystrix?

一.什麼是 Hystrix?

在分佈式環境中,許多服務依賴項中的一些將不可避免地失敗。 Hystrix 是一個庫,通過添加延遲容忍和容錯邏輯,幫助您控制這些分佈式服務之間的交互。 Hystrix 通過隔離服務之間的訪問點,停止它們之間的級聯故障,並提供回退選項來實現這一點,所有這些都提高了系統的總體彈性。

Hystrix的歷史

Hystrix是從 Netflix API 團隊2011年開始的彈性工程工作中演化而來的。2012年,Hystrix 繼續發展和成熟,Netflix 內部的許多團隊都採用了它。今天,Netflix 每天通過 Hystrix 執行數百億個線程隔離的、數千億個信號量隔離的呼叫。 這導致了正常運行時間和彈性的顯著改善。

二.Hystrix是幹什麼的?

Hystrix 的設計目的如下:

  • 通過第三方客戶端庫從依賴項訪問(通常通過網絡)提供對延遲和故障的保護和控制
  • 停止複雜分佈式系統中的級聯故障
  • 快速而迅速的失敗
  • 如果可能的話,撤退並優雅地降級
  • 啓用接近實時的監視、警報和操作控制

三.Hystrix解決了什麼問題?

複雜分佈式體系結構中的應用程序有許多依賴項,每個依賴項都不可避免地在某個時刻失敗。 如果宿主應用程序沒有與這些外部故障隔離開來,那麼它可能會隨着這些外部故障而被關閉。

例如,對於依賴於30個服務的應用程序,其中每個服務的正常運行時間爲99.99% ,以下是您可以期望的:

99.9930 = 99.7% uptime
0.3% of 1 billion requests = 3,000,000 failures
2+ hours downtime/month even if all dependencies have excellent uptime.

99.993099.7% 正常運行時間0.3% 的10億次請求3,000,000次故障2小時以上停機 / 月,即使所有依賴項都有很好的正常運行時間。

現實通常更糟糕。

即使所有依賴項都運行良好,如果您不對整個系統進行彈性設計,那麼即使是對幾十個服務中的每個服務的0.01% 停機時間的累計影響也可能相當於每個月數小時的停機時間。

當一切正常時,請求流可以是這樣的:

在這裏插入圖片描述

當許多後端系統中的一個變得異常時,它可以阻止整個用戶請求:

在這裏插入圖片描述

在高流量的情況下,單個後端依賴變得異常可能導致所有服務器上的所有資源在幾秒鐘內飽和。

應用程序中通過網絡或進入客戶端庫的每個點都可能導致網絡請求,這是潛在故障的根源。 比故障更糟糕的是,這些應用程序還可能導致服務之間的延遲增加,從而備份隊列、線程和其他系統資源,導致整個系統發生更多級聯故障。

在這裏插入圖片描述
當通過第三方客戶機進行網絡訪問時,這些問題就更加嚴重了——這是一個”黑匣子” ,其中隱藏了實現細節,並且可以隨時更改,而且每個客戶機庫的網絡或資源配置不同,往往難以監控和更改。

更糟糕的是可傳遞依賴關係,這些依賴關係在應用程序沒有顯式調用的情況下執行可能代價高昂或容易出錯的網絡調用。

網絡連接失敗或降級。 服務和服務器失敗或變慢。 新的庫或服務部署會改變行爲或性能特徵。 客戶機庫有 bug。

所有這些都表示需要隔離和管理的故障和延遲,以便單個故障依賴關係不能關閉整個應用程序或系統。

四.Hystrix 是如何實現其目標的?

Hystrix的工作原理是

  • 防止任何單個依賴項用盡所有容器(例如Tomcat)用戶線程。

  • 脫落負載並快速失敗而不是排隊。

  • 在可行的情況下提供回退以保護用戶免於失敗。

  • 使用隔離技術(例如隔板,泳道和斷路器模式)來限制任何一個依賴項的影響。

  • 通過近實時指標,監控和警報優化發現時間

  • 通過Hystrix的大多數方面的配置更改的低延遲傳播和對動態屬性更改的支持來優化恢復時間,這允許您使用低延遲反饋循環進行實時操作修改。

  • 防止整個依賴關係客戶端執行中的故障,而不僅僅是網絡流量。

    Hystrix通過以下方式實現:

  • 將對外部系統(或“依賴項”)的所有調用包含在通常在單獨線程中執行的對象HystrixCommand或HystrixObservableCommand對象中(這是命令模式的示例)。

  • 定時調用的時間超過您定義的閾值。有一個默認的,而是由“屬性”的方式對大多數依賴你自定義設置這些超時,使它們成功率筆99.5略高。

  • 爲每個依賴服務維護一個小的線程池(或信號量); 如果它變滿,將立即拒絕發往該依賴項的請求而不是排隊。

  • 衡量成功,失敗(客戶端引發的異常),超時和線程拒絕。

  • 如果服務的錯誤百分比超過閾值,則手動或自動地使斷路器跳閘以停止對特定服務的所有請求一段時間。

  • 當請求失敗時執行callback邏輯,被拒絕,超時或短路。

  • 近乎實時地監控指標和配置更改。

當您使用 Hystrix 包裝每個基礎依賴項時,如上圖所示的體系結構將變得類似於下圖。 每個依賴都是相互隔離的,當延遲發生時它可以飽和的資源受到限制,並且包含在回退邏輯中,該邏輯決定當依賴中發生任何類型的故障時應該做出什麼響應:

在這裏插入圖片描述

五:結論

制,並且包含在回退邏輯中,該邏輯決定當依賴中發生任何類型的故障時應該做出什麼響應:

[外鏈圖片轉存中…(img-RO5lgsjE-1584629829225)]

五:結論

Netflix 已經官方宣佈不再維護 Hystrix,所以在生產環境,技術選型的時候需要綜合考慮。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章