用 Hystrix 構建高可用服務架構
參考 Hystrix Home。
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（斷路技術）來限制任何一個依賴服務的故障的影響。 - 通過近實時的統計/監控/報警功能，來提高故障發現的速度。
- 通過近實時的屬性和配置熱修改功能，來提高故障處理和恢復的速度。
- 保護依賴服務調用的所有故障情況，而不僅僅只是網絡故障情況。