即使 Hystrix 再也不維護，它仍然值得學習！

本文由 yanglbme 首發於 GitHub 技術社區 Doocs，目前 stars 已超 30k。
項目地址：github.com/doocs/advan…

Hystrix 是什麼？

在分佈式系統中，每一個服務均可能會調用不少其餘服務，被調用的那些服務就是依賴服務，有的時候某些依賴服務出現故障也是很正常的。

Hystrix 可讓咱們在分佈式系統中對服務間的調用進行控制，加入一些調用延遲或者依賴故障的容錯機制。

Hystrix 經過將依賴服務進行資源隔離，進而阻止某個依賴服務出現故障時在整個系統全部的依賴服務調用中進行蔓延；同時Hystrix 還提供故障時的 fallback 降級機制。

總而言之，Hystrix 經過這些方法幫助咱們提高分佈式系統的可用性和穩定性。

Hystrix 的歷史

Hystrix 是高可用性保障的一個框架。Netflix（能夠認爲是國外的優酷或者愛奇藝之類的視頻網站）的 API 團隊從 2011 年開始作一些提高系統可用性和穩定性的工做，Hystrix 就是從那時候開始發展出來的。

在 2012 年的時候，Hystrix 就變得比較成熟和穩定了，Netflix 中，除了 API 團隊之外，不少其餘的團隊都開始使用 Hystrix。

時至今日，Netflix 中天天都有數十億次的服務間調用，經過 Hystrix 框架在進行，而 Hystrix 也幫助 Netflix 網站提高了總體的可用性和穩定性。

2018 年 11 月，Hystrix 在其 Github 主頁宣佈，再也不開放新功能，推薦開發者使用其餘仍然活躍的開源項目。維護模式的轉變毫不意味着 Hystrix 再也不有價值。相反，Hystrix 激發了不少偉大的想法和項目，咱們高可用的這一塊知識仍是會針對 Hystrix 進行講解。

Hystrix 的設計原則

• 對依賴服務調用時出現的調用延遲和調用失敗進行控制和容錯保護。
• 在複雜的分佈式系統中，阻止某一個依賴服務的故障在整個系統中蔓延。好比某一個服務故障了，致使其它服務也跟着故障。
• 提供 fail-fast（快速失敗）和快速恢復的支持。
• 提供 fallback 優雅降級的支持。
• 支持近實時的監控、報警以及運維操做。

舉個栗子。

有這樣一個分佈式系統，服務 A 依賴於服務 B，服務 B 依賴於服務 C/D/E。在這樣一個成熟的系統內，好比說最多可能只有 100 個線程資源。正常狀況下，40 個線程併發調用服務 C，各 30 個線程併發調用 D/E。

調用服務 C，只須要 20ms，如今由於服務 C 故障了，好比延遲，或者掛了，此時線程會 hang 住 2s 左右。40 個線程所有被卡住，因爲請求不斷涌入，其它的線程也用來調用服務 C，一樣也會被卡住。這樣致使服務 B 的線程資源被耗盡，沒法接收新的請求，甚至可能由於大量線程不斷的運轉，致使本身宕機。服務 A 也掛。

Hystrix 能夠對其進行資源隔離，好比限制服務 B 只有 40 個線程調用服務 C。當此 40 個線程被 hang 住時，其它 60 個線程依然能正常調用工做。從而確保整個系統不會被拖垮。

Hystrix 更加細節的設計原則

• 阻止任何一個依賴服務耗盡全部的資源，好比 tomcat 中的全部線程資源。
• 避免請求排隊和積壓，採用限流和 fail fast 來控制故障。
• 提供 fallback 降級機制來應對故障。
• 使用資源隔離技術，好比 bulkhead（艙壁隔離技術）、swimlane（泳道技術）、circuit breaker（斷路技術）來限制任何一個依賴服務的故障的影響。
• 經過近實時的統計/監控/報警功能，來提升故障發現的速度。
• 經過近實時的屬性和配置熱修改功能，來提升故障處理和恢復的速度。
• 保護依賴服務調用的全部故障狀況，而不單單只是網絡故障狀況。

---

歡迎關注個人微信公衆號「Doocs開源社區」，原創技術文章第一時間推送。