原文地址 : 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)用 包裝在
HystrixCommand或HystrixObservableCommand對象中 (通常在單獨(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) .
