服務降級 vs 服務熔斷

From: http://www.cnblogs.com/rjzheng/p/10340176.html

什麼是服務熔斷?

    當下遊服務不可用或者響應緩慢， 則阻止進一步調用目標服務， 而是直接返回，快速釋放資源， 直到目標服務恢復，再繼續調用它。

    熔斷是一個框架級的處理， 基本的處理方式：斷路器模式。。。。

    熔斷器的狀態： Closed Open Half-Open。

    若是失敗比例達到閾值，則開始熔斷器 Closed -> Open
    打開的時候， 有個reset timeout, 若是到了這個時間， 狀態會變爲Half-Open。 Closed -> Half-Open 
    處於Half-Open狀態時， 會嘗試將一部分請求調用下游服務， 若是能夠成功調用下游服務， 則關閉熔斷器 Half-Open -> Closed; 若是仍然不能成功調用，則繼續開啓熔斷器 Half-Open -> Open

    在Hystrix 中， 配置：
    // 滑動窗口， 即 調用次數
    circuitBreaker.requestVolumeThreshold=20
    // 多長時間後，開始進入半開啓狀態
    circuitBreaker.sleepWindowInMilliseconds=5000
    // 服務調用錯誤率
    circuitBreaker.errorThresholdPercent=50%

    上述配置的意思是每20個請求中， 調用失敗次數超過50%，就開啓熔斷器。過了5秒以後， 嘗試調用目標服務， 根據結果判斷熔斷器開始或者關閉。

什麼是服務降級？

    先說2個場景：

        下游服務因爲某種緣由響應過慢，下游服務主動停掉一些不過重要的業務， 釋放服務資源， 增長響應速度。
        下游服務因爲某種緣由不可用， 上游主動調用本地一些降級邏輯， 避免卡頓， 迅速將結果返回給用戶。

    這樣2個場景並沒以爲和熔斷有啥區別， 做者說能夠理解爲：服務降級有不少方式，好比限流降級、開關降級、熔斷降級；而服務熔斷只不過是服務降級的一種方式

    好比， 上游代碼：

    try{
        // 調用下游服務
        xxRpc.helloWorld();
    } catch(Exception e){
        // 由於熔斷， 而拋出異常
        doSomething();
    }

    下游的helloWorld服務由於熔斷而調用不一樣(拋出異常)。此時上游服務會進入catch代碼塊， 那麼doSomething執行的邏輯就是降級邏輯。

    服務降級更多的屬於業務級別的降級。在配置中心更改開關， 決定哪些服務降級。至於配置變更後， 應用怎樣監控配置變化， 應該用到Rxjava之類的了。

    在應用中， 添加用於降級使用的開關，也能夠叫作埋點。。。。

    那麼埋點的形式是啥呢？

        簡化執行流程：本身梳理核心流程和非核心流程，而後在非核心流程上加開關， 一旦發現系統扛不住， 經過開關關掉那些非核心流程。

        關閉次要功能： 同簡化流程

        下降一致性： 發現都是核心流程，沒法簡化流程， 那隻能下降一致性， 也就是將核心流程的同步改成異步， 強一致性改成最終一致性。

        上面3個都是手動降級， 怎麼實現自動降級？？通常降級場景能夠預見，好比某某活動。有突發事件、流量異常也會有監控郵件通知， 提供咱們手動降級。

        固然，這並不表明不能自動降級。。。。

        自動降級思路：先設置預警閾值；監控是否達到閾值，若是達到閾值， 則更改配置中心的配置(啓動開關降級)；配置中心監測到配置的變化， 則會推送這些變化到相應的微服務(PS: 配置中心具備熱刷新功能)。