淺談Retry設計模式及在前端的應用與實現

引子

當一個網頁刷不出來的時候，咱們經常會本能得刷新一下。這就是一個最簡單的 retry （重試）。有時重試一次就加載成功了，有時須要幾回，有時須要隔半個小時再來嘗試，有時再怎麼嘗試也沒有用。在軟件工程的世界裏，發生這樣失敗與重試的場景不只僅是加載網頁，它還能夠是向數據庫讀取數據，向某個微服務請求資源，或是向雲端的某些服務發送計算請求等。尤爲在今天這個紛紛向雲上遷移，走向萬物互聯的時代，這樣的場景正在變得愈來愈多。一個聰明完善的Retry機制可使系統變得更有韌性，並減小冗餘的報錯。在客戶端，它還能夠提升用戶體驗。這篇文章會之前端爲應用背景介紹一些retry相關的知識和我的經驗，它們將涉及：

• 什麼狀況下要 retry：認識並鑑別Transient fault（短暫故障）
• 如何Retry: 一些 retry 設計模式
• Retry 設計模式在客戶端的應用與實現
• 監控：更好地在運行時瞭解你的系統

若是你感興趣，就請繼續往下看吧~

什麼狀況下要 retry: 認識並鑑別Transient fault(短暫故障)

什麼是Transient fault(短暫故障)

Transient fault(短暫故障)，顧名思義，它是一個短暫存在，而且在一段時間後會被修復的故障。這個時間能夠短到幾毫秒也能夠長達幾小時。若是咱們的請求是由於一個這樣的故障而失敗的，那咱們在適當的時候重試就能夠了。在前端應用中，短暫故障每每發生在你向服務端請求資源時。好比你向一個API發送一個AJAX請求，對面返回一個 「5XX」 的響應。

如何鑑別短暫故障

形成請求失敗的緣由有不少。它能夠是由於服務端內部邏輯的錯誤，能夠是由於客戶端發送了一個糟糕的請求，也能夠是由Infrastructure形成的一些短暫故障（好比暫時負載量過大，某個服務器的宕機，或網絡問題等）。而只有在短暫故障的狀況下進行retry纔有意義。那麼客戶端如何鑑別短暫故障呢？最簡單的方法是運用 HTTP 請求的響應碼。根據規範， 400-499 之間是客戶端形成的問題，500-599之間是服務端的故障。（完整響應碼列表請參照 MDN文檔）。顯然，若是返回的錯誤碼是4xx ，咱們就沒有必要重試了。那問題就縮小到了如何在5xx 的故障中鑑別出短暫故障。若是服務端對錯誤響應碼有標準的定義，咱們就能夠經過不一樣的號碼得知錯誤的緣由，從而決定是進行retry仍是作別的處理。這同時也說明服務端開發中標準並清晰的定義錯誤碼和給與錯誤信息的重要性。

如何retry: 一些 retry 設計模式

認識了Transient fault，當請求失敗時咱們能夠有一個基本的處理步驟：

1. 鑑別是否是 transient fault
2. 若是是，啓動retry機制，進行必定次數的retry
3. 當retry達到最大次數尚未成功，報錯並說明緣由：服務端暫時沒法響應。

那麼如何retry ？retry機制能夠各類各樣，咱們應該根據需求的和失敗緣由的不一樣來選擇不一樣的retry機制。下面讓咱們來看一些一些基本的retry設計模式。

簡單的當即retry

當請求失敗，當即retry，是咱們會想到的最直接的方法。它能夠被用於一些不常見的失敗緣由，由於緣由罕見，馬上retry也許就修復了。但當碰到一些常見的失敗緣由如服務端負載太高，不斷的當即retry只會讓服務端更加不堪重負。試想若是有多個客戶端instance在同時發送請求，那越是retry狀況就越糟糕。

有延遲的retry

在遇到上面的失敗緣由，與其當即retry, 倒不如等待一會，也許那時服務端的負載就降下來了。這個 delay（延遲）的時間能夠是一個常量，也能夠是根據必定數學公式變化的變量。好比咱們可使用一些逐次增長delay算法。這樣的算法就好像咱們不斷地去服務端敲敲門，每次沒人開門，咱們就意識到本身太急了，那下次來以前就再多等一會好了，由於再一次的失敗也是在說明狀況尚未獲得緩解。Exponential Backoff (指數後退算法)就是一個這個類型的算法，它以指數的方式來增長delay。打個比方就是：第一次失敗等待1秒，第二次再失敗等待2秒，接下去4秒，8秒...。

上面的例子被普遍使用，但也不必定適應每個場景。咱們能夠根據本身系統的特性和業務的需求，設計更適合更優化的算法。

Circuit Breaker(斷路器)

那若是Transient fault 修復的時間特別長怎麼辦？好比長時間的網絡問題，那就算咱們有再好的retry機制，也免不了是徒勞。咱們只會一次又一次地retry, 失敗，再retry, 直到達到上限。這一來浪費資源，二來或許又會干擾服務端的自我修復。別擔憂，Circuit Breaker (斷路器)的設計模式也許能拯救咱們。它的原意其實就是電路中的開關，你們在中學物理中應該都有接觸過。在電路里一旦開關斷開，電流就別想經過了。那麼在計算機系統中，咱們就能夠想象一旦開關斷開，咱們就不會再發送任何請求了。

Circuit Breaker在retry機制中的應用是一個狀態機，有三種狀態：OPEN,HALF-OPEN, CLOSE。咱們設定一個threshold(閾值)和一個timeout，當retry的次數超過這個threshold時，咱們認爲服務端進入一個較長時間的Trasient fault。那麼咱們就開關斷開，進入OPEN 狀態。這時咱們將再也不向服務端發送任何請求，就像開關斷開了，電流（請求）怎麼也不會從客戶端流向服務端。當過了一段時間到了timeout，咱們就將狀態設爲HALF-OPEN（ 這時電路中不具有的），這時咱們會嘗試把客戶端的請求發往服務端去試探它是否已經恢復。若是是就進入CLOSE狀態，回到咱們正常的機制中，若是不是，就再次進入OPEN 狀態。

這個機制既節約了資源，防止了無休止的無用的嘗試，又保證了在修復後，客戶端能知曉，並恢復的正常的運行。

以上是一些經典的設計模式，它爲咱們設計retry機制提供了範本和思路。在不一樣的應用場景下咱們能夠根據需求靈活地變換。也能夠對上面的機制加以修改，設計出更適合本身的版本。

Retry 設計模式在客戶端的應用與實現

在服務端，Retry 的機制被大量運用，尤爲是在雲端微服務的架構上。不少雲平臺自己就提供了主體（好比服務，節點等）之間的retry機制從而提升整個系統的穩定性。而客戶端，做爲一個獨立於服務端系統以外，運行在用戶手機或電腦上的一個App, 並無辦法享受到平臺的這個功能。這時，就須要咱們本身去爲App加入retry機制, 從而使整個產品更增強壯。

npm 有一個 retry 的包能夠幫助咱們快速加入retry機制，具體如何使用能夠參照 https://www.npmjs.com/package...

其實retry的實現並不複雜，咱們徹底能夠本身寫一個這樣的工具供一個或多個產品使用。這可讓咱們更容易更改其中的算法來適應產品的需求。

下面是我寫的一個簡單的retry小工具，因爲咱們向服務端作請求的函數經常是返回promise的，好比 fetch 函數 。這個工具能夠爲任何一個返回promise的函數注入retry機制。

// 這個函數會爲你的 promiseFunction (一個返回promise的函數) 注入retry的機制。
// 好比 retryPromiseFunctionGenerator(myPromiseFunction, 4, 1000, true, 4000)
// 會返回一個函數，它的用法和功能與 myPromiseFunction 同樣。但若是 Promise reject 了，
// 它就會進行retry, 最多retry 4 次，每次時間間隔指數增長，最初是1秒，隨後2秒，4秒，因爲
// 咱們設定最大delay是4秒，那麼以後就會持續delay4秒，直到達到最大retry次數 4 次。而若是
// enableExponentialBackoff 設爲 false, delay就會是一個常量1秒。
const retryPromiseFunctionGenerator = (
  promiseFunction, // 須要被retry的function
  numRetries = defaultNumRetries, // 最多retry幾回
  retryDelayMs = defaultRetryDelayMs, // 兩次retry間的delay
  enableExponentialBackoff = false, // 是否啓動指數增長delay
  maxRetryDelayMs // 最大delay時間
) => async (...args) => {
  for (
    let numRetriesLeft = numRetries;
    numRetriesLeft >= 0;
    numRetriesLeft -= 1
  ) {
    try {
      return await promiseFunction(...args);
    } catch (error) {
      if (numRetriesLeft === 0 || !isTransientFault(error)) {
        throw error;
      }

      const delay = enableExponentialBackoff
        ? Math.min(
            retryDelayMs * 2 ** (numRetries - numRetriesLeft),
            maxRetryDelayMs || Number.MAX_SAFE_INTEGER
          )
        : retryDelayMs;

      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
};

這個小工具能夠實現上面提到的設計模式中的第二種：有延遲的retry。你能夠方便地調節retry的參數以及是否要應用Exponential Backoff 的算法。你也能夠稍做修改讓計算delay的function自己也做爲一個參數傳進來，從而讓這個工具變得更靈活。

監控：更好地在運行時瞭解你的系統

如今咱們的App擁有了retry機制，在客戶端運行時，它變得更強壯了，一些失敗的服務端請求並不能打到它。但做爲開發者的你必定想知道它在用戶手上retry了幾回，何時retry的，最終失敗了沒有。這些信息不只讓我更好的瞭解用戶的實際體驗，它們也能夠做爲服務端性能的指標之一。實時對這些信息進行監控甚至可讓咱們儘早的發現服務端的故障以減小損失。

客戶端的監控是一個很大的話題，Retry信息的收集只是其中一個應用場景。那如何實現呢？很簡單。咱們能夠在每一次執行retry時發送一條log(日誌)其中包含你想了解的信息。而後運用第三方或公司內部的日誌瀏覽工具去分析這些日誌，從而得到許多有意思的指標。

舉個例子，咱們能夠簡單地監控retry log 的數量，若是忽然激增，那就說明服務端也許出現了一些故障，這時候開發團隊能夠在第一時間作出反應修復故障，以避免對大面積的客戶形成影響。固然這不只僅能夠經過監控retry實現，咱們也能夠監控服務端的http請求失敗的數量，這是題外話了^^

結束語

此次的話題好像不那麼前端，但我以爲它頗有意思。同時我也在慢慢探索寫做的方向。若是你有任何前端或監控相關感興趣的話題，或對個人建議，歡迎留言告訴我。最後，感謝你的閱讀。