老系统升级到新系统-灰度发布

背景

作者所在的公司随着业务发展，老系统越发显得无力支撑业务发展，同时伴随着各种问题不断的浮现，所以新系统的构建被提上了日程；
关于为什么升级，已经在另一篇博客中进行阐述，如果有兴趣的同学可以一起来吐槽老系统升级到新系统
那么由新系统替代老系统的过程中被叫做灰度发布，它主要解决的是新老系统切换期间产生的各类问题，那么灰度发布期间会产生那些问题了？以下是作者在灰度发布期间遇到的坑和总结的经验，系统对后来的同学能有所帮助。

灰度发布期间产生的问题

关于老系统业务迁移到新系统，并不是一蹴而就的，因为线上业务出于运行状态，而我们要开发的系统属于替代性质，那么有几个问题需要解决：

1：老系统业务整理问题，新系统需要替换老系统，那么就需要整理整个老系统的业务流程，但是有的业务所对应的负责人可能已经离职，或者某个业务可能已经暂停等等情况，会导致整理过程中遇到很多的问题。

2：新增业务问题，在新系统开发的同时，老系统也在不断的开发新业务，那么就会出现比较尴尬的局面，就是可能某个功能在新系统做完还未上线，老系统又增加了一段业务代码，就问你尴尬不？

3：新老系统并行问题，新系统上线之后，不可能一刀直接将流量都切换到新系统中，因为新系统没有承受过线上数据的洗礼，总是存在各种未知的问题。那么关于新老并行问题，需要设计好解决方案。

4：数据信任问题，针对用户某些数据，比如订单数据、通话记录、阅读记录，在迁移的过程中并没有太大的问题，完全可以进行异步迁移，无论是在用户登录的时候进行异步触发，还是后端定时任务进行迁移都能满足需求，因为它们属于一旦生成，就不会改变的数据，但是针对某些特殊的数据，比如：用户余额、积分，它们在迁移的时候需要注意，因为新系统的不确定性导致我们无法100%信任新系统的正确性，针对新系统数据无法完全信任的问题，也需要设计好解决方案。

灰度发布期间问题的解决方案

既然发现了问题，那么就要解决问题，针对灰度发布遇到的问题，作者实行了以下的解决方案：

1：小颗粒度+多迭代，一次性迁移整个业务并不现实，遇到的问题多如牛毛，而每次只关注一部分内容，那么迁移的过程就会变得简单（解决老系统业务整理问题），比如第一次只迁移用户相关内容，包括C、B、S端的用户，用户体系将在新系统中构建完整，那么无论新老系统，都可以以新系统的用户体系为准，通过这种方式，既可以实现快速迁移的目标，同时也可以更加专注其中一部分业务的迁移，避免大而不全的尴尬。

2：新业务评估，针对发布期间会出现的新业务，会评估使用新老系统实现的风险，如果新系统能够胜任开发任务，那么将以新系统为准，这样就避免了老系统接收更多的业务开发，据作者统计，90%以上的新业务，新系统都是能够胜任开发的，而针对一些特殊业务，只能在老系统中进行开发，也会因为小颗粒度迁移，从而减少影响。

3：流量开关，新系统上线之后，需要进行缓慢的引流，从而检验新系统的合格性，流量开关可以很轻松的达到目的。也有的同学做法是切换几个特定的用户（一般是内部用户）进入新系统，然后让他们把整个系统都使用一遍，来检验新系统的合格性。

4：新老双写，流量开关能够控制业务流量的流向，但是针对新系统切换不成功，需要切换回老系统的情况，在新系统触发业务的同时，还需要写入到老系统中，避免用户数据缺失的尴尬。

5：双业务触发，针对数据信任问题，作者进行了业务织入的形式，将新系统业务织入了老系统中，在老系统发生业务的时候，进行了双业务触发，即业务在老系统发生的同时，也会在新系统发生，并且比对他们的执行结果，通过长时间的业务并行，并且评估新系统的执行情况，便能判断新系统的否合格，针对合格的业务，只需要在老系统中进行代码切换，即可达到新老业务切换的目的。

总结

作者设计的灰度发布方案是以小颗粒度，多次迭代的方式进行迁移，并且针对并行产生的问题，增加了流量开关和双业务触发检查的方案，但是同样存在缺点，那就是开发的任务变得异常繁重，同一段业务代码，可能会针对不同的业务迁移而修改，如果哪位同学有更好的解决方案，能不能分享一下了，谢谢！