浅谈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请求失败的数量，这是题外话了^^

结束语

此次的话题好像不那么前端，但我以为它颇有意思。同时我也在慢慢探索写做的方向。若是你有任何前端或监控相关感兴趣的话题，或对个人建议，欢迎留言告诉我。最后，感谢你的阅读。