老系统升级到新系统-灰度发布
背景
灰度发布期间产生的问题
关于老系统业务迁移到新系统，并不是一蹴而就的，因为线上业务出于运行状态，而我们要开发的系统属于替代性质，那么有几个问题需要解决：
1：老系统业务整理问题，新系统需要替换老系统，那么就需要整理整个老系统的业务流程，但是有的业务所对应的负责人可能已经离职，或者某个业务可能已经暂停等等情况，会导致整理过程中遇到很多的问题。
2：新增业务问题，在新系统开发的同时，老系统也在不断的开发新业务，那么就会出现比较尴尬的局面，就是可能某个功能在新系统做完还未上线，老系统又增加了一段业务代码，就问你尴尬不？
3：新老系统并行问题，新系统上线之后，不可能一刀直接将流量都切换到新系统中，因为新系统没有承受过线上数据的洗礼，总是存在各种未知的问题。那么关于新老并行问题，需要设计好解决方案。
4：数据信任问题，针对用户某些数据，比如订单数据、通话记录、阅读记录，在迁移的过程中并没有太大的问题，完全可以进行异步迁移，无论是在用户登录的时候进行异步触发，还是后端定时任务进行迁移都能满足需求，因为它们属于一旦生成，就不会改变的数据，但是针对某些特殊的数据，比如：用户余额、积分，它们在迁移的时候需要注意，因为新系统的不确定性导致我们无法100%信任新系统的正确性，针对新系统数据无法完全信任的问题，也需要设计好解决方案。
灰度发布期间问题的解决方案
3：流量开关，新系统上线之后，需要进行缓慢的引流，从而检验新系统的合格性，流量开关可以很轻松的达到目的。也有的同学做法是切换几个特定的用户（一般是内部用户）进入新系统，然后让他们把整个系统都使用一遍，来检验新系统的合格性。
4：新老双写，流量开关能够控制业务流量的流向，但是针对新系统切换不成功，需要切换回老系统的情况，在新系统触发业务的同时，还需要写入到老系统中，避免用户数据缺失的尴尬。
