hystrix要解決的分散式系統可用性問題以及其設計原則

1 導讀

高可用性這個topic，然後咱們會用幾講的時間來講解一下如何用hystrix，來構建高可用的服務的架構

咱們會用一個真實的項目背景，作為業務場景，來帶出來在這個特定的業務場景下，可能會產生哪些各種各樣的可用性的一些問題

針對這些問題，我們用hystrix的解決方案和原理是什麼

帶著大家，純手工將所有的服務的高可用架構的代碼，全部純手工自己敲出來

形成高可用服務架構的項目實戰的一個教程

2 Hystrix是什麼

在分散式系統中，每個服務都可能會調用很多其他服務，被調用的那些服務就是依賴服務，有的時候某些依賴服務出現故障也是很常見的。

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

Hystrix通過將依賴服務進行資源隔離，進而避免某個依賴服務出現故障的時候，在整個系統所有的依賴服務調用中蔓延，同時Hystrix還提供故障時的fallback降級機制

總而言之，Hystrix通過這些方法幫助我們提升分散式系統的可用性和穩定性

什麼是分散式系統以及其中的故障和hystrix

3 Hystrix的歷史

hystrix，一種高可用保障的框架，類似於spring(ioc，mvc)，mybatis，activiti，lucene，框架，預先封裝好的為了解決某個特定領域的特定問題的一套代碼庫

框架，用了框架之後，來解決這個領域的特定的問題，就可以大大減少我們的工作量，提升我們的工作質量和工作效率，框架,hystrix，就是高可用性保障的一個框架

Netflix(可以認為是國外的優酷或者愛奇藝之類的視頻網站)，API團隊從2011年開始做一些提升系統可用性和穩定性的工作，Hystrix就是從那時候開始發展出來的。

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

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

2018 年 11 月，Hystrix 在其 Github 主頁宣布，不再開放新功能，推薦開發者使用其他仍然活躍的開源項目。維護模式的轉變絕不意味著 Hystrix 不再有價值。相反，Hystrix 激發了很多偉大的想法和項目，其思想仍值得我們深入學習!

4 Hystrix的設計原則

對依賴服務調用時出現的調用延遲和調用失敗進行控制和容錯保護

在複雜的分散式系統中，阻止某一個依賴服務的故障在整個系統中蔓延，服務A-服務B-服務C，服務C故障了，服務B也故障了，服務A故障了，整套分散式系統全部故障，整體宕機

提供fail-fast(快速失敗)和快速恢復的支持

提供fallback優雅降級的支持

支持近實時的監控、報警以及運維操作5 Hystrix要解決的問題在複雜的分散式系統架構中，每個服務都有很多的依賴服務，而每個依賴服務都可能會故障 如果服務沒有和自己的依賴服務進行隔離，那麼可能某一個依賴服務的故障就會拖垮當前這個服務

舉例來說

某個服務有30個依賴服務，每個依賴服務的可用性非常高，已經達到了99.99%的高可用性

那麼該服務的可用性就是99.99%的30次方，也就是99.7%的可用性

99.7%的可用性就意味著3%的請求可能會失敗，因為3%的時間內系統可能出現了故障不可用了

對於1億次訪問來說，3%的請求失敗，也就意味著300萬次請求會失敗，也意味著每個月有2個小時的時間系統是不可用的

在真實生產環境中，可能更加糟糕

上面也就是說，即使你每個依賴服務都是99.99%高可用性，但是一旦你有幾十個依賴服務，還是會導致你每個月都有幾個小時是不可用的

畫圖分析說，當某一個依賴服務出現了調用延遲或者調用失敗時，為什麼會拖垮當前這個服務?以及在分散式系統中，故障是如何快速蔓延的?

依賴服務的故障導致服務被拖垮以及故障的蔓延示意圖

6 Hystrix的更加細節的設計原則

阻止任何一個依賴服務耗盡所有的資源，比如tomcat中的所有線程資源

避免請求排隊和積壓，採用限流和fail fast來控制故障

提供fallback降級機制來應對故障

使用資源隔離技術，比如bulkhead(艙壁隔離技術)，swimlane(泳道技術)，circuit? breaker(短路技術)，來限制任何一個依賴服務的故障的影響

通過近實時的統計/監控/報警功能，來提高故障發現的速度

通過近實時的屬性和配置熱修改功能，來提高故障處理和恢復的速度

保護依賴服務調用的所有故障情況，而不僅僅只是網路故障情況

調用這個依賴服務的時候，client調用包有bug，阻塞，等等，依賴服務的各種各樣的調用的故障，都可以處理

7 Hystrix如何實現它的目標

通過HystrixCommand或者HystrixObservableCommand來封裝對外部依賴的訪問請求，這個訪問請求一般會運行在獨立的線程中，資源隔離

對於超出我們設定閾值的服務調用，直接進行超時，不允許其耗費過長時間阻塞住。這個超時時間默認是99.5%的訪問時間，但是一般我們可以自己設置一下

為每一個依賴服務維護一個獨立的線程池，或者是semaphore，當線程池已滿時，直接拒絕對這個服務的調用

對依賴服務的調用的成功次數，失敗次數，拒絕次數，超時次數，進行統計

如果對一個依賴服務的調用失敗次數超過了一定的閾值，自動進行熔斷，在一定時間內對該服務的調用直接降級，一段時間後再自動嘗試恢復

當一個服務調用出現失敗，被拒絕，超時，短路等異常情況時，自動調用fallback降級機制

對屬性和配置的修改提供近實時的支持

畫圖分析，對依賴進行資源隔離後，如何避免依賴服務調用延遲或失敗導致當前服務的故障

資源隔離如何保護依賴服務的故障不要拖垮整個系統

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！