教程:一塊兒學習Hystrix--Hystrix初識

目錄

•  Hystrix是什麼
• Hystrix用來作什麼
• Hystrix解決什麼問題
• Hystrix設計原則
• Hystrix如何實現目標

Hystrix是什麼

    在分佈式環境下，不免出現許多服務之間調用失敗的場景， Hystrix是一個經過添加延遲容忍和容錯邏輯幫助您控制這些分佈式服務之間交互的庫。 Hystrix經過隔離服務之間的訪問點來實現應用之間連鎖故障（因下游服務失敗，致使上游服務不可用），出現故障提供備選方案來提升應用總體的可用性。

    舉例：搶購活動中，因爲庫存服務超時或者崩掉，能夠經過提示搶購失敗，請稍後重試等預防搶購應用不可用

Hystrix用來作什麼

    Hystrix能夠作一些事情：

1. 經過第三方客戶端庫，爲控制延遲和依賴之間調用失敗提供保護。
2. 在複雜的分佈式系統中阻止連鎖故障
3. 快速故障恢復
4. 在可能的狀況下，作到服務隔離和優雅降級
5. 儘量的實時監控、報警、運維控制

Hystrix解決什麼問題

    複雜的分佈式應用有許多依賴調用，在某一時刻它們之間必然會出現失敗，這就是致使應用總體故障的風險。

     例如，對於一個依賴於30個服務的應用程序，每一個服務的正常運行時間爲99.99%，下面是您能夠預期的結果。

     99.99 的30次方=  99.7% （意味着有0.3%的失敗）

     10億*0.3% = 300萬（10億次請求會有300萬次請求失敗）

      即便每月在很好的正常運行的時間，也會有2個小時的停機。一般狀況會被這個更糟糕。

當全部請求都很正常的狀況下，請求流就會像下圖同樣：

當不少後端系統有一個不穩定時，就會阻塞整個請求，以下圖：

    

在大量請求下，一個後端不理想的依賴都會成爲阻塞整個應用請求的潛在風險

應用中任何一個經過網絡或者客戶端發出的請求都有可能成爲網絡請求失敗的潛在風險，比請求失敗更糟糕的是，應用調用依賴之間的延遲增長，更甚應用中的隊列、線程池、其餘系統資源形成的連鎖故障

    當經過第三方客戶端進行網絡訪問，就是一個不清楚實現細節以及隨時可能發生改變的黑盒執行，對於每一個客戶端，網絡和資源配置都是不同的，因此很難監控和更改。

    更糟糕的是，依賴調用之間，在不被應用顯示調用的狀況下，執行昂貴和容易出錯的網絡調用

    網絡鏈接失敗或者降級、服務與服務之間調用失敗或者延遲，新庫或服務部署改變方式或者性能特性

全部這些失敗和延遲的狀況都須要被隔離或者管理，這樣就不會由於單個依賴的失敗摧毀整個應用和系統。

Hystrix設計原則

1.  防止單個應用耗盡服務器（好比 tomcat）全部可用線程
2. 丟棄重負載、快速失敗代替排隊
3. 爲任何狀況失敗提供保護
4. 使用隔離技術(如隔板、泳道和斷路器模式)來限制任何一個依賴的影響
5. 經過接近實時的度量、監視和警報來優化快速發現故障
6. Hystrix在大部分方面依靠低延遲配置和動態配置優化恢復時間， 容許使用快速返回結果進行實時操做調整
7. 保護整個依賴客戶端執行中的失敗，不只僅是 網絡流量中

Hystrix如何實現目標

• 在HystrixCommand或HystrixObservableCommand對象中封裝全部對外部系統(或「依賴項」)的調用，該對象一般在單獨的線程中執行(這是命令模式的示例)
• Hystrix有一個默認值，若是調用時長超過這個默認值，認定爲超時調用，大部分依賴能夠經過配置自定義這個值，所以他們略高於依賴項的99.5%的性能
• 爲每一個依賴維護一個小的線程池(或信號量);若是它已滿，將當即拒絕爲該依賴指定的請求，而不是排隊。
• 衡量成功、失敗(客戶拋出的異常)、超時和線程拒絕
• 觸發斷路器，在一段時間內中止全部對某個服務的請求，若是服務的錯誤百分比超過閾值，則手動或自動中止
• 當一個請求失敗、被拒絕、超時或短路時，執行備選邏輯
• 近實時的監控度量和配置的變化

    當您使用Hystrix來包裝每一個基礎依賴項時，圖中所示的架構會發生變化，以下圖所示。每一個依賴項都是相互隔離的，當延遲發生時，它可能會被限制在資源中，而且在熔斷器中覆蓋，當任何類型的故障發生在依賴項中時，它決定了要作出什麼響應