新老系统过渡方案

我们谈了很多微服务改造的点，但已有项目转微服务势必会遇到一个棘手的问题：新系统怎么替换老系统？下面我就讨论下几种主流方案。

一次性替换方案

这是最简单干脆的方案，如果可行必然是首选。 实现上一般分两步，如下图：

先确定重构开始的时间点及这个点下老版本的功能（重构前的功能），接下来新版本的功能开发会对标这个功能列表进行，同期老版本会限制性接入一些重要或紧急的需求，完成重构前的功能开发及测试后再花些时间把重构后的增量功能补全，注意这个时期老版本还是可能会有需求接入，但人力会向新版本倾斜，在实现新版本功能完全覆盖老版本并测试通过后重构才算完成，新版本上线，老版本下线。

逐步替换方案

一次性替换固然简单，但这意味着过长的研发周期，并且在这个周期内要限制老系统的新增需求，这多半是业务方无法接受的。所以我们更常见的方案是按模块或组件逐步替换。它的难点在于要处理新老系统并存的问题，解决的方案有以下几种：先剥离非核心业务，逐步演进 这一方案的前提是要求老系统可拆分成一个个功能、数据相对独立的模块，实际操作上局限性比较大。我们更常见的情况是老系统设计不合理，无法拆分，重构时连带着数据结构都要变更，这时可以采用 新系统逐步迭代开发，发布一个功能后关闭老系统对应的接口 但这带来的问题是数据不一致。拿车贷通举个例子，在原版本中用户申请的步骤过于复杂，重构时可以做一定的减法，在数据存储也可以更简单，那么我们在新系统中发布新的申请功能，使用新的数据库及数据结构，老版本中禁用对应的接口，但新系统不包含审核功能，审核只能在老系统中进行，审核的信息要依赖申请数据，怎么办？这时有两个方法：

• 数据同步 使用数据库日志（比如MySQL的binlog，Mongo的optlog）双向同步新老系统的数据，这对业务没有侵入性，只要开发独立的同步程序即可，但它的问题在于无法同步诸如Redis的缓存数据，也无法处理各类MQ数据

• 数据适配 为新系统或老系统开发数据适配层，在操作自己系统的数据时同步更新另外系统的数据，这对业务侵入性很高，开发成本很大，视为不得以的方法

以上是系统过渡的几个方案，分别针对不同场景，在生产中其实我们还会考虑试运行这一阶段，新系统总归会存在一定的问题，试运行就是让风险可控最常用的手段，这一阶段新老系统可以并存，一般会根据一定的数据划分方式做灰度发布。比如我们经常会以用户维度圈出一部分内测用户（比如自己公司的员工）路由到新版本。