1. Hystrix 簡介

原文地址 : https://github.com/Netflix/Hystrix/wiki
如果存在翻譯錯誤的地方 , 請留言告知 , 我會及時勘誤 , 多謝

1. Hystrix 是什么 ?
2. Hystrix 是為什么準(zhǔn)備的 ?
3. Hystrix 解決了什么問題 ?
4. Hystrix 的基礎(chǔ)設(shè)計原則是什么 ?
5. Hystrix 如何實(shí)現(xiàn)它的目標(biāo) ?

Hystrix 是什么 ?

在分布式環(huán)境中 , 無法避免的會出現(xiàn)所依賴的服務(wù)失敗的情況 ,
而Hytrix 可以通過添加 延遲容錯故障容錯 來幫助你控制這些分布式服務(wù)中的交互 .
Hystrix 通過 隔離 服務(wù)之間的訪問點(diǎn) ,阻止它們之間的 級聯(lián)故障 , 提供 后備選項 , 來提高系統(tǒng)的整體彈性 , 從而實(shí)現(xiàn)了這一點(diǎn) .

Hystrix 的歷史

Hystrix 是 Netflix API 團(tuán)隊 , 在 2011 年 ~ 2012 年之間 , 在實(shí)現(xiàn)彈性計算工程的時候演化出來的 .
Hystrix 不斷的發(fā)展和成熟 , Netflix 里的很多團(tuán)隊都采用了它 .
在Netflix , 每天通過Hystrix執(zhí)行數(shù)百億的線程隔離和數(shù)千億的信號量隔離呼叫 . 這使得 系統(tǒng)正常運(yùn)行的時間 和 彈性得到了顯著的改善 .

下面的這些鏈接 提供了更多關(guān)于Hystrix的內(nèi)容 以及 它試圖解決的挑戰(zhàn) :

“Making Netflix API More Resilient”
“Fault Tolerance in a High Volume, Distributed System”
“Performance and Fault Tolerance for the Netflix API”
“Application Resilience in a Service-oriented Architecture”
“Application Resilience Engineering & Operations at Netflix”

Hystrix 是為什么準(zhǔn)備的 ?

Hystrix 是為以下這些情況而設(shè)計的 :

  • 通過控制延遲和故障來為,需要使用第三方客戶端訪問(通常通過網(wǎng)絡(luò))的依賴,提供保護(hù).
  • 在復(fù)雜的分布式系統(tǒng)中 , 阻止級聯(lián)的故障
  • 故障快速恢復(fù)
  • 回退 并且在可能的情況下優(yōu)雅降級
  • 啟動接近實(shí)時的監(jiān)控 , 警報 和 操作控制

Hystrix 解決了什么問題 ?

處于復(fù)雜分布式架構(gòu)中的應(yīng)用程序可能擁有數(shù)十個依賴關(guān)系 , 在某些時候 , 每個依賴關(guān)系都不可避免的會出現(xiàn)故障 . 如果主機(jī)應(yīng)用沒有和這些外部的故障隔離 , 則可能會和外部依賴一起出現(xiàn)故障 .

例如 , 某個應(yīng)用依賴于30個服務(wù)應(yīng)用 , 每個依賴具有99.99%的正常運(yùn)行時間, 你可以預(yù)期 :

99.99 ^ 30 = 99.7%的正常運(yùn)行時間
10億個請求中的0.3%= 3,000,000個失敗
2小時停機(jī)/月,即使所有依賴都有很好的正常運(yùn)行時間

而現(xiàn)實(shí)通常更糟糕 .

如果你不設(shè)計整個系統(tǒng)的恢復(fù)能力 , 即使所有的依賴表現(xiàn)良好 , 即使 0.01%的停機(jī)時間 , 對于每個服務(wù)的整體也可能等于每個月的停機(jī)時間 .

當(dāng)一切正常的時候 , 請求流可以像下面這樣 :

當(dāng)其中一個后臺系統(tǒng)不可用的時候, 它可以阻塞全部用戶的請求

在大流量到來的時候 , 單個后端依賴的不可用 , 可能會導(dǎo)致所有的資源在所有的服務(wù)器上飽和 .

應(yīng)用中 , 跨網(wǎng)絡(luò)訪問或者客戶端庫中可能導(dǎo)致網(wǎng)絡(luò)請求的每一個點(diǎn)都是潛在的故障的根源 . 更糟糕的是 , 這些應(yīng)用也可能導(dǎo)致服務(wù)之間的延遲增加 , 阻塞 隊列, 線程 , 和其他的系統(tǒng)資源 , 從而引起更多的級聯(lián)故障.

當(dāng)通過第三方客戶端進(jìn)行網(wǎng)絡(luò)訪問的時候 , 這些問題會被加劇 , -- 這是一個"黑箱" , 它的實(shí)現(xiàn)細(xì)節(jié)是被隱藏并隨時可以更改 , 網(wǎng)絡(luò)或者資源配置對于每個客戶端都是不同的 , 通常難以監(jiān)控和改變 .

甚至更糟糕的是 , 相關(guān)的依賴 在執(zhí)行 潛在的 , 昂貴的 , 或者是易出錯的網(wǎng)絡(luò)請求時 , 并不是應(yīng)用顯示調(diào)用的 .

網(wǎng)絡(luò)連接失敗或降級 . 服務(wù)或者服務(wù)器 故障 或者變得緩慢時 . 新的庫或者服務(wù)部署改變了行為或者是性能特征時 . 客戶端庫存在BUG時 .

所有這些故障和延遲都需要被隔離和管理起來 , 以便單個依賴出現(xiàn)的故障不能影響整個應(yīng)用或系統(tǒng) .

Hystrix 的基礎(chǔ)設(shè)計原則是什么 ?

  • 預(yù)防任何單個依賴耗光所有容器(比如 tomcat)中的用戶線程 .
  • 減輕負(fù)載 并 快速失敗 而不是排隊 .
  • 在可行的情況下提供回退以保護(hù)用戶免受故障影響 .
  • 使用隔離技術(shù)(類似隔板 , 泳道 和斷路器模式) 來限制任何一個依賴的影響 .
  • 通過近乎于實(shí)時的指標(biāo) , 監(jiān)控 和 警報 來優(yōu)化發(fā)現(xiàn)問題的時間 .
  • 通過配置來優(yōu)化恢復(fù)時間 , Hystrix大多數(shù)屬性都允許動態(tài)變更 , 從而允許您實(shí)時操作修改.
  • 保護(hù)整個依賴客戶端中執(zhí)行時出現(xiàn)的故障 , 而不僅僅是在網(wǎng)絡(luò)流量中 .

Hystrix 如何實(shí)現(xiàn)它的目標(biāo) ?

  • 將所有對外部系統(tǒng)(或"依賴關(guān)系")的調(diào)用 包裝在 HystrixCommandHystrixObservableCommand 對象中 (通常在單獨(dú)的線程中)(這是命令模式的示例) .
  • 超時調(diào)用的時間長于您所定義的法制 , 這里有一個默認(rèn)值 , 但是的對于大多數(shù)依賴 , 您可以通過"屬性"定制這些超時 , 以使它們略高于每個依賴99.5%的性能
  • 為每個依賴維護(hù)一個線程池(或信號量) , 如果它滿了那么依賴關(guān)系的請求將立刻被拒絕而不是排隊 .
  • 如果服務(wù)出錯的百分比超過閥值 , 則斷路器可以在一段時間內(nèi) , 手動或者自動停止對指定服務(wù)的所有請求 .
  • 當(dāng)請求失敗時執(zhí)行回退邏輯 , 包括 請求被拒絕 , 超時 , 或短路 .
  • 近實(shí)時的指標(biāo)監(jiān)控和配置修改 .

當(dāng)你使用Hystrix包裝每一個底層依賴的時候 , 上面描述的體系架構(gòu)如下圖所示 . 每個依賴都是相互隔離的 , 當(dāng)延遲發(fā)生并且資源飽和的時候 , 它可以被回退邏輯覆蓋 , 回退邏輯決定了在依賴關(guān)系中發(fā)生任何類型的故障時將作出什么響應(yīng) .

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容