客户端多分身本地数据交替升级解决方案 - 绝对干货全网难找

背景

开发客户端时，为了应对不同客户的不同需求，大杂烩的客户端往往使得代码非常凌乱，补丁代码越堆越多，但是这并不能让产品的付费转化提高，每个用户都有自己的需求偏重，同时也更在意自己的需求的体验和稳定性，不断地增加更多功能，会使得系统过于庞大，同时还降低了系统的稳定，互相影响是难免的。

但如果抽离不同功能形成新的版本，就会出现分裂，渐渐地就会出现底层数据结构的分裂，一旦分开就有走得快的，走得慢的，慢的和快的就会产生结构的不同，为了应对这种结构的自然变化，以及使用者的不可控（对方可能一直用着旧版本），这就造成了版本管理的痛苦性，所以需要一种机制来保证同应用不同分身的（抖音，抖音火山版，抖音...）在单一设备上本地数据结构的共享和升级问题。

为何需要这东西？

1. 因为客户端产品都是涉及本地数据库的调度，比如迅雷的下载不可能说频繁请求服务端吧，不信你在 B 电脑登录迅雷，之前 A 电脑下载的内容就没有了，如果想在 B 电脑上也有，只能走服务器同步，但是如果想在 A 电脑上多存一个下载文件的字段，就需要本地数据库的升级，这就是该问题产生的根本。

2. 如果是一个简单的客户端产品（没必要是客户端），客户端产品主要就是利用电脑本地的机制，实现长时间运行，比如定时提醒，操控系统级东西，比如打印机，摄像头等外设，定时监控，链接本地数据库服务器，redis，读写本地文件，进行本地化处理等，如果你没有以上需求，那就开发网页就搞定了。

方案解决的点

连续性升级原则用来解决单应用的数据升级导致的断层问题，客户端多分身交替升级解决方案要解决的是同应用不同分身的数据结构共存共用的问题，维度上又提高了一层

多分身升级 3D 立体示意图

立体图细节讲解

1. 每个分身都有自己独立的版本，这样可以方便区分每个分身的进展情况，而且也容易维护自身的代码逻辑，包括接口的独立性，JS 的版本控制等；

2. 每个分身的主结构都依赖于主线版本的数据结构，自身版本号会依赖于一个主线版本号

3. 所有的数据结构的升级都发生于主线版本的升级逻辑中

4. 分身升级只需要将自己对应的主线版本号丢给主线升级逻辑，去升级即可

5. 主线升级逻辑，控制着升级过程，不关心哪个分身过来造成的升级，只关心送过来的主线版本是否已升级过

设计的好处

1. 可以随意卸载任何一个分身，安装任意版本的分身，不会出现系统异常，因为每个分身依赖的主线版本都是固定的，而主线版本又都是增量开发，所以不会出现问题

2. 可以在此基础上，满足各种类型的分身，瘦身软件，进行独立迭代升级，不会互相影响，灵活度更高，账号体系统一

设计的风险

1. 未来多个团队分别迭代多个版本时，主线升级差异会逐渐拉大，每个团队发布版本前总要先看一看，主线版本跑到哪里了，是否已有版本已经满足了自己的需要，不满足就会进行累加，也是一个体力活

2. 如果某一个版本长期不更新，那么一旦要更新，需要看完所有的主线更新的基础上，再累加自己的更新逻辑，这个过程也够呛，所以尽量多版本之间减少长时间不更新的版本