对前端开发来说,如何保障用户访问的前端页面正常展示是我们需要关心的事情。影响页面是否正确展示主要依赖静态资源(css/html/js)数据和接口请求数据是否可靠。
前端开发都知道,其中最容易出问题的页面数据是接口请求的数据。因此,端侧的容灾重点也是对接口数据的容灾方案。具体介绍可查看《端侧如何做容灾》文章。
当接口请求失败的时候返回容灾的数据,保证前端页面的正常交互以及展示。
我们将,容灾整体逻辑封装成一个前端npm工具,开发同学使用的时候能实现简单的调用;同时也提供了可视化的后台,对容灾的数据进行管理与分析。
总体上,我们的方案在接入和使用的成本上是非常低的,但是容灾数据的备份还是依赖开发同学主动操作。
一个接口(api+版本+参数)对应一条备份数据,如果是有限数量的接口,手动备份是可行的。但是对于类似商品详情数据接口,一个api,千变万化的入参,对应着千万级别的数据这类数据。这种情况,如果去手动备份数据就太废开发了。那么,是否有一个自动生成备份数据的方案呢?
对端侧来说要做自动容灾,要考虑清楚
•如何判断哪些请求数据需要自动备份?
•如何保障备份数据的准确性?
•如何管控哪些接口需要自动备份?
等一系列问题。
做这个自动备份方案时,遇到最大的问题就是,如何触发自动备份数据。无非就是以下几种方法:
•遍历在线的接口数据,然后生成备份数据
问题:1、线上接口数据过于庞大,定期定时去监控线上接口,资源开销过大
•端侧发起请求同时,也发起数据备份请求逻辑进行数据备份
问题:1、需将数据备份的逻辑在C端暴露,有安全性问题
2、无法感知接口是否存在备份数据,每次都需要去请求备份生成接口。
•当请求容灾数据发现未备份的时候,再去生成备份数据
问题:只有异常发生的时候才会触发备份,第一次异常是兜不住的。
优点:资源开销小,安全稳定,没有多余的接口请求。
对比优点来说,只牺牲一次的异常兜底失败这个缺点完全是可以接受的。所以我们就采用了这个方案去实现
在这个基本流程上,为了保障自动容灾数据的准确性和可控性,还做了很多优化
一、通过可视化平台对需要自动容灾的接口进行管理
配置的白名单的接口就是自动生成容灾数据的目标接口