前言

对前端开发来说，如何保障用户访问的前端页面正常展示是我们需要关心的事情。影响页面是否正确展示主要依赖静态资源（css/html/js）数据和接口请求数据是否可靠。
前端开发都知道，其中最容易出问题的页面数据是接口请求的数据。因此，端侧的容灾重点也是对接口数据的容灾方案。具体介绍可查看《端侧如何做容灾》文章。

容灾的基本流程

当接口请求失败的时候返回容灾的数据，保证前端页面的正常交互以及展示。

我们将，容灾整体逻辑封装成一个前端npm工具，开发同学使用的时候能实现简单的调用；同时也提供了可视化的后台，对容灾的数据进行管理与分析。

开发使用接入流程

总体上，我们的方案在接入和使用的成本上是非常低的，但是容灾数据的备份还是依赖开发同学主动操作。

手动备份数据的问题

一个接口（api+版本+参数）对应一条备份数据，如果是有限数量的接口，手动备份是可行的。但是对于类似商品详情数据接口，一个api，千变万化的入参，对应着千万级别的数据这类数据。这种情况，如果去手动备份数据就太废开发了。那么，是否有一个自动生成备份数据的方案呢？

对端侧来说要做自动容灾，要考虑清楚

•如何判断哪些请求数据需要自动备份？

•如何保障备份数据的准确性？

•如何管控哪些接口需要自动备份？

等一系列问题。

方案

做这个自动备份方案时，遇到最大的问题就是，如何触发自动备份数据。无非就是以下几种方法：

•遍历在线的接口数据，然后生成备份数据

• 问题：1、线上接口数据过于庞大，定期定时去监控线上接口，资源开销过大

•端侧发起请求同时，也发起数据备份请求逻辑进行数据备份

• 问题：1、需将数据备份的逻辑在C端暴露，有安全性问题
  2、无法感知接口是否存在备份数据，每次都需要去请求备份生成接口。

•当请求容灾数据发现未备份的时候，再去生成备份数据

• 问题：只有异常发生的时候才会触发备份，第一次异常是兜不住的。

• 优点：资源开销小，安全稳定，没有多余的接口请求。

对比优点来说，只牺牲一次的异常兜底失败这个缺点完全是可以接受的。所以我们就采用了这个方案去实现

自动容灾基本流程

在这个基本流程上，为了保障自动容灾数据的准确性和可控性，还做了很多优化

一、通过可视化平台对需要自动容灾的接口进行管理
配置的白名单的接口就是自动生成容灾数据的目标接口