关于系统升级迁移的一些经验

由于工作关系经常会碰到定制化系统版本更新，这种更新本身又是因为业务的快速迭代产生所以每次都会碰到数据迁移和系统并行，再次写点笔记


基本有几种

第一种是新旧系统数据结构和业务相同的情况下，这种并行相对简单，主要根据业务的需求进行不同的方案选择，由于用户和业务的需要进行数据交互，这时候可以采用直接手工sql的方式转移，或者在新老之间做一个中间件来操作数据，个人比较推荐第二种虽然要开发但是容易记录变动轨迹。

第二种是新的数据结构和业务流程与老的不同了，这里的不同指的是根本业务并没有改变，但是数据结构及逻辑已经变化，尤其是还涉及到使用的数据库都不同了，比如从pg迁移到mysql等这种情况，这时候就会非常麻烦，由于数据结构的不同导致了需要在转换过程中进行对目标数据结构的字段含义转义，如何做这个对应关系要根据你的实际情况自己进行分析，最好在设计新系统的架构时候就考虑到这个问题。

一般系统过渡方案主要采用两种
一种是一刀切，就是从选定的时间节点切入把所有的业务迁移到新系统连带历史数据都迁移过去。这种操作风险很高，但是一劳永逸。

另一种就是并行。这种时候一般会在选定时间节点启动新的系统进入业务，新业务数据都进入新的系统，老的系统不在做业务数据增长慢慢消耗停运，这种情况下就会有一部分公用信息，比如用户信息，操作员信息，账户信息等非业务数据，这种数据可以根据切入点进行增长的判断通过人工或者开发中间件的形式来进行数据增量一般是老的往新的增，老的尽量控制不在增长业务数据就好了，对于业务数据在并行期间需要转移的情况下需要在设计之初考虑到一些业务信息的绝对不重复性，比如用户的id号之类的关键字段避免在互相转移过程中还要进行数据排重的操作。


本来是回复人家的问题，结果写多了。索性迁移到博客来吧