静态资源版本回滚
前端经常面临这个问题。在前后端分离的趋势下，前端通常将项目打包，并且将文件放到 CDN 上。
一般来说，静态资源的发布都是“存量发布”。比如腾讯云控制台，是通过 hash 值来控制版本，每次发版时，都是不会改动之前的版本的文件。
当有问题出现，可以快速加载原版本文件，来进行回滚。同时，hash 值保证了每次版本的文件名不一样，防止覆盖。
部署版本回滚
1、小版本：比如 100 台机器，先发 1 台，观察日志，然后逐步发，直到全量。
2、大版本：要先进行灰度发布，让部分用户先体验。在开发 CloudBase 网关的时候，其实就有灰度集群、主集群以及 VIP 集群，新功能先灰度集群（小部分用户体验），再主集群（几乎所有用户使用），最后 VIP 集群（大客户所在）。
3、架构升级：最近搞了集群迁移，那么版本是两边都要发。等到流量全部切到新集群，再下调老集群。
4、失败降级：有兜底的页面或者数据，不能让用户看到白屏，或者得不到结果。
数据版本回滚
有两种思路：全量和增量。这取决于业务数据结构的设计，以及存储成本。
举个例子，在线文档工具一般都提供了历史记录，以及前端也可以通过 Ctrl+z，来回退版本。那么这个可以怎么实现？
对后台，保存增量数据，需要提取不同版本数据之间的公共部分，然后设计算法，实现复杂。所以后台一般采用全量版本机制，及直接存储当前版本的文档数据。
对前端，可以通过将每次操作完后的数据保存在内存堆栈中，然后弹出即可。但这种方法的缺点在于，对于几万字的文档，内存消耗过大，很容易卡死。
前端可以通过 Immutable.js 或者 Immtuable 的其它实现，在内存中保存各个版本的文档。当用户执行 Ctrl+S，或者点击“保存按钮”，再将当前文档数据，传给后台，让后台全量存储当前版本文档。只有在用户主动操作下，才会触发后台存储，用户主动操作频率低，也降低了后端存储压力。