分散式系統關注點——99%的人都能看懂的「熔斷」以及最佳實踐

huorongbj發表於2018-11-19
分散式

如果這是第二次看到我的文章，歡迎點選文末連結關注我的公眾號喲~

本文長度為3319字，建議閱讀9分鐘。


當我們工作所在的系統處於分散式系統初期的時候，往往這時候每個服務都只部署了一個節點。

那麼在這樣的背景下，如果某個服務A需要釋出一個新版本，往往會對正在執行的其它依賴服務A的程式產生影響。甚至，一旦服務A的啟動預熱過程耗時過長，問題會更嚴重，大量請求會阻塞，產生級聯影響，導致整個系統卡慢。

舉個誇張的例子來形容：一幢樓的下水管是從最高樓直通到最低樓的，這個時候如果你家樓下的管道口堵住了，那麼所有樓上的汙水就會倒灌到你家。如果這導致你家的管道口也堵住了，之後又會倒灌到樓上一層，以此類推。

然而實際生活中一旦你發現了這個問題，必然會想辦法先避免影響到自己家，然後跑到樓下讓他們趕緊疏通管道。此時，避免影響自己家的辦法就可被稱之為「熔斷」。


一、熔斷是什麼

熔斷本質上是一個過載保護機制。這一概念來源於電子工程中的斷路器，可能你曾經被這個東西的“跳閘”保護過。

▲圖片來源於網路，版權歸原作者所有


在網際網路系統中的熔斷機制是指：當下遊服務因訪問壓力過大而響應變慢或失敗，上游服務為了保護自己以及系統整體的可用性，可以暫時切斷對下游服務的呼叫。

做熔斷的思路大體上就是：一箇中心思想，分四步走。


二、熔斷怎麼做

首先，需秉持的一箇中心思想是：量力而行。因為軟體和人不同，沒有奇蹟會發生，什麼樣的效能撐多少流量是固定的。這是根本。


然後，這四步走分別是：

  1. 定義一個識別是否處於“不可用”狀態的策略

  2. 切斷聯絡

  3. 定義一個識別是否處於“可用”狀態的策略，並嘗試探測

  4. 重新恢復正常


定義一個識別是否處於“不正常”狀態的策略

相信軟體開發經驗豐富的你也知道，識別一個系統是否正常，無非是兩個點。

  • 是不是能調通

  • 如果能調通，耗時是不是超過預期的長


但是，由於分散式系統被建立在一個並不是100%可靠的網路上，所以上述的情況總有發生，因此我們不能將偶發的瞬時異常等同於系統“不可用”（避免以偏概全）。由此我們需要引入一個「時間視窗」的概念，這個時間視窗用來“放寬”判定“不可用”的區間，也意味著多給了系統幾次證明自己“可用”機會。但是，如果系統還是在這個時間視窗內達到了你定義“不可用”標準，那麼我們就要“斷臂求生”了。

這個標準可以有兩種方式來指定。

  • 閾值。比如，在10秒內出現100次“無法連線”或者出現100次大於5秒的請求。

  • 百分比。比如，在10秒內有30%請求“無法連線”或者30%的請求大於5秒。

最終會形成這樣這樣的一段程式碼。

全域性變數 errorcount = 0; //有個獨立的執行緒每隔10秒（時間視窗）重置為0。
全域性變數 isOpenCircuitBreaker = false;

//do some thing...

if(success){
    return success;
}
else{
    errorcount++;
    if(errorcount == 不可用閾值){
        isOpenCircuitBreaker = true;
    }
}複製程式碼


切斷聯絡

切斷聯絡要儘可能的“果斷”，既然已經認定了對方“不可用”，那麼索性就預設“失敗”，避免做無用功，也順帶能緩解對方的壓力。


分散式系統中的程式間呼叫，一般都會通過一些RPC框架進行。

那麼，這個時候作為客戶端一方，在自己程式內通過代理髮起呼叫之前就可以直接返回失敗，不走網路。

這就是常說的「fail fast」機制。就是在前面提到的程式碼段之前增加下面的這段程式碼。

if(isOpenCircuitBreaker == true){
    return fail;
}

//do some thing...複製程式碼


定義一個識別是否處於“可用”狀態的策略，並嘗試探測

切斷聯絡後，功能的完整性必然會受影響，所以還是需要儘快恢復回來，以提供完整的服務能力。這事肯定不能人為去幹預，及時性必然會受到影響。那麼如何能夠自動的識別依賴系統是否“可用”呢？這也需要你來定義一個策略。


一般來說這個策略與識別“不可用”的策略類似，只是這裡是一個反向指標。

  • 閾值。比如，在10秒內出現100次“呼叫成功”並且耗時都小於1秒。

  • 百分比。比如，在10秒內有95%請求“呼叫成功”並且98%的請求小於1秒。

同樣包含「時間視窗」、「閾值」以及「百分比」。


稍微不同的地方在於，大多數情況下，一個系統“不可用”的狀態往往會持續一段時間，不會那麼快就恢復過來。所以我們不需要像第一步中識別“不可用”那樣，無時無刻的記錄請求狀況，而只需要在每隔一段時間之後去進行探測即可。所以，這裡多了一個「間隔時間」的概念。這個間隔幅度可以是固定的，比如30秒。也可以是動態增加的，通過線性增長或者指數增長等方式。


這個用程式碼表述大致是這樣。

全域性變數 successCount = 0; 
//有個獨立的執行緒每隔10秒（時間視窗）重置為0。
//並且將下面的isHalfOpen設為false。

全域性變數 isHalfOpen = true;
//有個獨立的執行緒每隔30秒（間隔時間）重置為true。

//do some thing...
if(success){
    if(isHalfOpen){
        successCount ++;
        if(successCount = 可用閾值){
            isOpenCircuitBreaker = false;
        }
    }
    
    return success;
}
else{
    errorcount++;
    if(errorcount == 不可用閾值){
        isOpenCircuitBreaker = true;
    }
}複製程式碼


另外，嘗試探測本質上是一個“試錯”，要控制下“試錯成本”。所以我們不可能拿100%的流量去驗證，一般會有以下兩種方式：

  1. 放行一定比例的流量去驗證。

  2. 如果在整個通訊框架都是統一的情況下，還可以統一給每個系統增加一個專門用於驗證程式健康狀態檢測的獨立介面。這個介面額外可以多返回一些系統負載資訊用於判斷健康狀態，如CPU、I/O的情況等。


重新恢復正常

一旦通過了衡量是否“可用”的驗證，整個系統就恢復到了“正常”狀態，此時需要重新開啟識別“不可用”的策略。就這樣，系統會形成一個迴圈。

這就是一個完整的熔斷機制的面貌。瞭解了這些核心思想，用什麼框架去實施就變得不是那麼重要了，因為大部分都是換湯不換藥。


上面聊到的這些可以說是主幹部分，還有一些最佳實踐可以讓你在實施熔斷的時候拿捏的更到位。


三、做熔斷的最佳實踐

什麼場景最適合做熔斷

一個事物在不同的場景裡會發揮出不同的效果。以下是我能想到最適合熔斷髮揮更大優勢的幾個場景：

  • 所依賴的系統本身是一個共享系統，當前客戶端只是其中的一個客戶端。這是因為，如果其它客戶端進行胡亂呼叫也會影響到你的呼叫。

  • 所以依賴的系統被部署在一個共享環境中（資源未做隔離），並不獨佔使用。比如，和某個高負荷的資料庫在同一臺伺服器上。

  • 所依賴的系統是一個經常會迭代更新的服務。這點也意味著，越“敏捷”的系統越需要“熔斷”。

  • 當前所在的系統流量大小是不確定的。比如，一個電商網站的流量波動會很大，你能抗住突增的流量不代表所依賴的後端系統也能抗住。這點也反映出了我們在軟體設計中帶著“面向懷疑”的心態的重要性。


做熔斷時還要注意的一些地方

與所有事物一樣，熔斷也不是一個完美的事物，我們特別需要注意2個問題。


首先，如果所依賴的系統是多副本或者做了分割槽的，那麼要注意其中個別節點的異常並不等於所有節點都存在異常，所以需要區別對待。


其次，熔斷往往應作為最後的選擇，我們應優先使用一些「降級」或者「限流」方案。因為“部分勝於無”，雖然無法提供完整的服務，但儘可能的降低影響是要持續去努力的。比如，拋棄非核心業務、給出友好提示等等，這部分內容我們會在後續的文章中展開。


四、總結

本文主要聊了熔斷的作用以及做法，並且總結了一些我自己的最佳實踐。


上面的這些程式碼示例中也可以看到，熔斷程式碼所在的位置要麼在實際方法之前，要麼在實際方法之後。它非常適合AOP程式設計思想的發揮，所以我們平常用到的熔斷框架都會基於AOP去做。


熔斷只是一個保護殼，在周圍出現異常的時候保全自身。但是從長遠來看平時定期做好壓力測試才能更好的防範於未然，降低觸發熔斷的次數。如果清楚的知道每個系統有幾斤幾兩，在這個基礎上再把「限流」和「降級」做好，這基本就將“高壓”下觸發熔斷的概率降到最低了。



Question：

你覺得還有什麼時候需要熔斷呢？歡迎給我留言交流哦。



相關文章：


▶ 關於作者：張帆（Zachary，個人微訊號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。

微信公眾號（首發）：跨界架構師。<-- 點選後閱讀熱門文章

定期發表原創內容：架構設計丨分散式系統丨產品丨運營丨一些深度思考。


相關文章