從不可描述的服務雪崩到初探Hystrix

什麼是服務雪崩？什麼是服務保護？服務保護的措施有哪些？熔斷怎麼作？限流怎麼作？服務隔離怎麼作？降級怎麼作？

真實案例

舉一個本身遇到的真實的例子。 接口A依賴了服務B，接口A的部署狀況是有兩個機房部署，服務B的部署狀況也是兩個機房部署。用戶請求接口失敗會重試，部署架構圖以下：

說明：服務部署用到的是Linux+Nginx+PHP技術棧。

當時遇到的狀況是服務B所在的機房掛了，致使接口A調用服務B超時，超時返回以後nginx重試到A的另外一個節點，繼續調用服務B，A的全部節點都失敗後，返回給客戶端失敗結果，客戶端進行重試，因而再進行一次剛剛的步驟，這些超時的請求佔用了PHP的進程沒有釋放，同時用戶側體驗感知到緩慢，因而不斷刷新重試，致使流量暴漲，PHP的進程池被耗盡了，因而接口A就沒法訪問了，其餘依賴接口A的功能也沒法使用，致使整個站點雪崩。

這是典型的服務沒有進行隔離致使功能雪崩的例子，那麼問題來了，若是要對此次的故障進行改進，爲接口和服務之間加入一層服務保護，那麼要怎麼作呢？

業界比較常見的服務保護主要有如下這些：

一、限流

當發現服務失敗數量達到某個閾值，拒絕訪問，限制更多流量的到來，防止過多失敗的請求將資源耗盡。

二、服務隔離

將不一樣類型的接口隔離部署，單個類型接口的失敗甚至進程池被耗盡不會影響其餘接口的正常訪問，好比在資訊平臺中，若是發佈和閱讀的接口分開部署了，那麼即便發佈功能失效，閱讀功能還能繼續使用。

三、熔斷

從接口請求鏈接就拒絕訪問，相似家裏用的保險絲，使用的電器總和超過了電壓就熔斷保險絲，整個電路短了，保護整個區域的電路防止更多的損失。

四、降級

對於簡單的展現功能，若是有失敗的請求，返回默認值。對於整個站點或客戶端，若是服務器負載太高，將其餘非核心業務中止，以讓出更多資源給其餘服務使用。

以上是筆者所知道服務出現雪崩的狀況以及保護服務的措施，在Java領域中，業界用得比較多的是Hystrix，那麼就來看看它是怎麼實現上面這些措施。

Hystrix是什麼？

Hystrix是一個經過增長延遲容錯和容錯邏輯來控制分佈式服務之間交互的一個庫。Hystrix經過線程隔離，防止錯誤級聯傳遞，致使服務雪崩，從而提升服務穩定性。

Hystrix的主要目標

一、經過隔離第三方客戶端庫訪問依賴關係，防止和控制延遲和故障；

二、防止複雜分佈式系統的級聯失敗；

三、快速響應失敗並迅速恢復；

四、提供回滾以及友好降級；

五、實現近實時監控，告警和操做控制

Hystrix設計原則

一、防止單個依賴耗盡了服務容器的用戶線程

二、下降負載以及快速失敗，而不是排隊

三、當能夠阻止服務的失敗時提供回退策略

四、使用隔離技術減小任意依賴的影響

五、經過近實時指標、監控和告警優化發現時間

六、在Hystrix的大多數方面，經過配置更改的低延遲和對動態屬性更改的支持，使得能夠在低延遲的狀況下進行實時修改操做，從而優化恢復時間

七、防止整個依賴關係客戶端執行中的故障，而不只僅是網絡流量

Hystrix如何作到上面的目標

一、全部外部的調用都封裝到HystrixCommand或HystrixObservableCommand對象，這些對象一般在單獨的線程下執行。

二、超時調用的時間，超過定義的閾值。有一個默認值，可是對於大多數的依賴，你能夠自定義該屬性使得略高於每一個依賴測量的99.5%的性能。

三、爲每個依賴項維護一個線程池（或者信號），若是依賴項的線程池滿了，新的依賴請求不會繼續排隊等待，而是立刻被拒絕訪問。

四、計算成功、失敗、超時和線程拒絕的數量。

五、若是依賴服務的失敗百分比超過閾值，則手動或自動啓動斷路器，在一段時間內中止對指定服務的全部請求。

六、爲請求失敗、被拒絕、超時或短路狀況提供回退邏輯。

七、近乎實時地監控指標和配置更改。

一段代碼demo

講完這麼多，仍是看看代碼更實在，從Hystrix官網上截取了一段代碼以下：

public class Order {

    private final int orderId;
    private UserAccount user;

    public Order(int orderId) {
        this.orderId = orderId;

        user = new GetUserAccountCommand(new HttpCookie("mockKey", "mockValueFromHttpRequest")).execute();
    }

}
複製代碼

更多代碼內容：github.com/Netflix/Hys…

上面就是Hystrix使用的實例，在實際代碼中，就是new一個Command，而後調用execute方法獲取結果，那麼這一個過程當中Hystrix作了什麼呢？

Hystrix的工做流程

上面這個圖是從Hystrix的官方文檔中找到的，能看懂這個文檔幾乎就能看懂Hystrix是怎麼執行的了。經過圖中的順序來解讀Hystrix的執行流程。

一、初始化，有兩種方式初始化一個Hystrix命令，經過new HystrixCommand或者new HystrixObservableCommand建立，使用服務實例和請求服務須要的參數來構造一個Hystrix命令。

二、成功建立Hystrix後，有四種方法執行實際的命令並獲得返回結果。這裏Hystrix還使用了響應式編程來設計，這個主題比較大，一時半會解釋不出，以後再深刻探索。

對於使用HystrixCommand建立命令的實例，執行execute或者queue；而對於使用HystrixObservableCommand建立命令的實例，執行observe或者toObservable方法，能夠請求服務而後獲得執行結果。這四個方法的特性是：

execute - 會阻塞，而後返回依賴服務的結果
queue - 返回一個Future，而後能夠經過get方法得到以來服務的結果。
observe - 訂閱包含依賴服務響應結果的訂閱器，當有結果時返回一個訂閱器。
toObservable - 返回一個訂閱器，當訂閱它時，會知曉Hystrix命令並返回結果。
複製代碼

execute的源碼以下：

public R execute() {
    try {
        return queue().get();
    } catch (Exception e) {
        throw Exceptions.sneakyThrow(decomposeException(e));
    }
}

public Future<R> queue() {
    /*
     * The Future returned by Observable.toBlocking().toFuture() does not implement the
     * interruption of the execution thread when the "mayInterrupt" flag of Future.cancel(boolean) is set to true;
     * thus, to comply with the contract of Future, we must wrap around it.
     */
    final Future<R> delegate = toObservable().toBlocking().toFuture();
    // 其餘定義
}
複製代碼

從源碼看到，execute方法會調用queue().get()方法，queue()會調用toObservable().toBlocking().toFuture()，說明每個Hystrix命令最終都回到Observable對象的實現，即便是爲了返回一個簡單的值。

三、判斷Hystrix是否啓用緩存且對應請求有緩存值，則返回緩存的結果。

四、若是3沒有緩存，Hystrix會檢查它的熔斷器，若是此時熔斷器開啓了，那麼Hystrix不會執行命令，直接返回降級結果。

五、若是信號或者線程池拒絕請求，返回降級結果。

六、Hystrix經過調用HystrixCommand.run()或者HystrixObservableCommand.construct()方法來觸發調用外部服務的操做，若是超時或者失敗，返回降級結果。 若是run或者construct方法超過了命令定義的超時值，線程會拋出TimeoutException，此時Hystrix捕捉到異常，就會忽略run或construct方法的返回值，進入fallback。

注意：沒有任何方式能夠阻止延遲的線程中止工做，在JVM中，Hystrix能夠作到最好的就是拋出一個InterruptedException，若是Hystrix封裝的服務沒有捕獲InterruptedException，Hystrix線程池中的線程會繼續它的工做。
複製代碼

七、無論請求如何進行：成功、失敗、超時、熔斷，Hystrix都會上報健康狀態到熔斷器，記錄服務狀態，用於判斷是否啓動／半啓動熔斷器。

八、fallback，進行降級操做，會觸發回退操做的條件： construct或者run方法拋出異常 熔斷器開啓 線程池以及隊列或者信號容量不足 Hystrix命令超時

對於每個Hystrix命令，都須要覆蓋getFallback方法，在fallback函數中實現降級的方案，若是須要在fallback中使用網絡調用，那麼須要經過另外一個HystrixCommand或者HystrixObservableCommand。在HystrixCommand中是實現getFallback方法，在HystrixObservableCommand中，是實現sumeWithFallback方法。

若是沒有實現fallback方法，或者fallback方法拋出了異常，Hystrix仍是會返回一個Observerable，可是不會返回內容並經過一個onError通知來立刻終止。經過onError通知，發生異常的會被返回Hystrix的調用者。儘可能不要寫出可能會拋出異常的fallback實現。

九、若是一切正常，那麼Hystrix會發送成功的結果到Observable，程序再去獲取。

總結

以上就是Hystrix的執行流程，由於最近想了解在PHP中如何實現服務熔斷，因而在學習Java中作的比較好的Hystrix是怎麼實現的。接下來會繼續深刻學習Hystrix的熔斷器實現，下次再分享Hystrix熔斷器的實現原理。

瞭解一個庫的執行流程，除了有助於開發時排查遇到的較棘手的問題，還能夠學習一個庫的設計理念，從這些庫中吸取一些框架設計優勢，以後若是須要實現相關功能時，就能夠做爲參考。

原創文章，文筆有限，才疏學淺，文中如有不正之處，萬望告知。

若是本文對你有幫助，請點個贊吧，謝謝^_^

更多精彩內容，請關注我的公衆號。