文章目录加载中

回滚机制

# 静态资源版本回滚

前端经常面临这个问题。在前后端分离的趋势下,前端通常将项目打包,并且将文件放到 CDN 上。

一般来说,静态资源的发布都是“存量发布”。比如腾讯云控制台,是通过 hash 值来控制版本,每次发版时,都是不会改动之前的版本的文件。

当有问题出现,可以快速加载原版本文件,来进行回滚。同时,hash 值保证了每次版本的文件名不一样,防止覆盖。

# 部署版本回滚

1、小版本:比如 100 台机器,先发 1 台,观察日志,然后逐步发,直到全量。

2、大版本:要先进行灰度发布,让部分用户先体验。在开发 CloudBase 网关的时候,其实就有灰度集群、主集群以及 VIP 集群,新功能先灰度集群(小部分用户体验),再主集群(几乎所有用户使用),最后 VIP 集群(大客户所在)。

3、架构升级:最近搞了集群迁移,那么版本是两边都要发。等到流量全部切到新集群,再下调老集群。

4、失败降级:有兜底的页面或者数据,不能让用户看到白屏,或者得不到结果。

# 数据版本回滚

有两种思路:全量和增量。这取决于业务数据结构的设计,以及存储成本。

举个例子,在线文档工具一般都提供了历史记录,以及前端也可以通过 Ctrl+z,来回退版本。那么这个可以怎么实现?

对后台,保存增量数据,需要提取不同版本数据之间的公共部分,然后设计算法,实现复杂。所以一般采用全量版本机制,及直接存储当前版本的文档数据。

对前端,可以通过将每次操作完后的数据保存在内存堆栈中,然后弹出即可。但这种方法的缺点在于,对于几万字的文档,内存消耗过大,很容易卡死。

前端可以通过 Immutable.js 或者 Immtuable 的其它实现,在内存中保存各个版本的文档。当用户执行 Ctrl+S,或者点击“保存按钮”,再将当前文档数据,传给后台,让后台全量存储当前版本文档。只有在用户主动操作下,才会触发后台存储,用户主动操作频率低,也降低了后端存储压力。

本文来自心谭博客:xin-tan.com,经常更新web和算法的文章笔记,前往github查看目录归纳:github.com/dongyuanxin/blog