前言
华润数科城市与公共事业部门下属项目组近期完成了一个地产行业遗留复杂业务系统的微服务化改造，目前项目已经成功上线，系统切换过程中实现了原单体系统在线业务数据分批无缝无损迁移到微服务架构新系统，确保了业务平滑过渡。本文分享我们在此次数据迁移过程中的思考、探索和实践总结，希望能够为有类似需求的朋友们提供一些经验借鉴。
背景
我们本次改造的单体系统承载着核心业务，采用商业开源框架构建，已经运行了 8 年。在这个过程中随着业务发展，开发团队在响应新需求时不断堆砌代码，从而带来了难以避免的代码腐化，加之团队人员大量流动，导致系统的架构、技术文档缺失，最终形成代码逻辑复杂难理解、系统稳定性差，运行效率低，功能扩展困难的局面。
团队曾经尝试采用绞杀者模式将一些非核心业务进行微服务重构，以及采用修缮者模式编写微服务实现一部分新业务需求。然而由于遗留代码臃肿、逻辑实现耦合、功能模块无法复用且缺少测试等多种原因，上述方法针对核心业务代码均不易使用，而且遗留系统在应对日益增加的业务量时已经不堪重负，整体改造迫在眉睫，同时考虑到团队具备丰富的业务和产品专家能够支持总体系统规划，我们最终决定使用系统整体演进的方式对其进行改造。在业务产品专家、架构师和技术负责人设计出服务总体规划蓝图，团队完成微服务拆分和开发、验证后，为保证业务平滑过渡和客户体验，新服务上线投入使用前需要设计完善的数据迁移方案，保证数据的正确性、完整性，下文详细阐述数据迁移方案的设计实施过程。
过程
下图展示了本次数据迁移过程包含的主要环节：
问题挑战
结合遗留系统、业务、团队的现状，我们梳理出本次数据迁移任务过程中主要面临的挑战有以下三个方面：
业务
团队
技术
方案选型
选型评价方法
为应对以上挑战，我们认为迁移方案应该具备以下特点：
而通用 ETL 工具的图形界面、API 等特性的重要程度相对不高。
备选方案对比
经考察，团队有相关经验的开源 / 定制化数据迁移框架 / 工具包括以下几种：
以下是对比表格：
可见开源的 top="3417.6875">方案实施细节
上面讲到我们最终选用>
得益于 top="3712.6875">适配开发部署需要
适配验证测试需要
为了解决这两个问题，我们定制修改了 top="4602.6875">业务需要
为方便进行网点和时间过滤，我们对>
在完成上述定制化后，新系统在第一批灰度发布网点成功上线，迁移涉及到的约 300 万条数据的读取、转换、写入耗时不到 20 分钟，上线后经业务、产品、网点现场工作人员验证，无严重问题，保证了业务的平滑过渡。
其他实践中的关注点
上文详述了我们在本次数据迁移中结合技术和业务实际对数据迁移框架的选型与定制化，实际上在这些工作之外，还有很多需要关注的点：
测试
测试的重要性无论如何强调都不为过，尤其是对于攸关业务正确性和连续性的数据迁移工作。在本项目中，我们为数据迁移搭建了专用的数据库、微服务集群和配套中间件，并将生产数据经脱敏后导入迁移测试环境数据库中，从而最大化模拟线上环境，尽早发现迁移脚本问题，确保迁移后的数据与业务逻辑相匹配，另外迁移后的数据与系统依赖的第三方 SaaS 服务之间的兼容性也需要完整测试。
规避数据冲突
在灰度发布的场景下，没有完成全部网点上线前，新老系统会并行运行一段时间，数据迁移过程中需要识别哪些数据在并行运行期间可能在两套系统上产生数据冲突，导致增量数据迁移时出现问题，并制定方案加以规避。
潜在数据冲突产生的一个重要源头是自动生成的数据主键，举个例子：假设在老系统上，合同编号使用数据库中的自增 id 实现，并且数据迁移执行时，老系统的合同编号值为 10000，若不做任何处理将合同数据平移至新系统且继续采用自增 id 作为合同编号，则数据迁移后新系统的合同编号也为 10000，这样在新老系统并行运行期间，两个系统新产生的合同编号会产生冲突：未进行灰度发布的网点 O 新签合同会使用编号 10001，已经进行了灰度发布的网点 N 新签合同也会使用编号 10001，当网点 O 也切换到新系统时，会发现由于合同 id 冲突而无法迁入新系统的问题。对于这种场景，我们采用了手工设置自增 id 的修复方式，将新系统的自增 id 设为老系统 max(id)*2，本案例中即将新系统的合同编号设为 20000，从而规避新旧系统并行运行期间生成重复数据 id 导致的冲突。
做好失败应对预案
无论计划多么详尽周密，实际执行时都有可能出现意外情况，数据迁移工作也不例外，因此必须提前规划好应对方案。本次数据迁移工作，我们从两方面做了预案：
总结
随着业务发展，传统的单体架构在响应需求变化方面表现欠佳，随着单一系统的代码量增长，系统复杂度很容易指数级增长，叠加技术债堆积、团队人员流动，导致新特性开发变得越来越困难。为此很多组织转向微服务架构寻求解决方案，微服务架构的灵活扩展、部署弹性、敏捷适配和组件自主演进等特性精准解决了上述痛点。然而在微服务拆分改造具体实施时，保证业务稳定是一个值得关注的话题，本文介绍了我们在新旧系统切换过程中，如何设计数据迁移方案解决相关问题挑战从而达成这一目标，希望能够为有类似需求的读者朋友带来一些帮助。
作者简介
王智勇 ，现任华润数科企业数字化中心城市与公共架构总监，拥有多年软件开发行业经验，主要服务于大型客户的定制软件开发项目，专注于系统架构设计，团队能力构建，带领团队开发高质量的产品，为客户交付业务价值。在项目需求分析、技术选型、系统架构设计、持续部署、团队能力提升、开发计划制定和系统构建实施等方面有深入的理解和丰富的实践经验，服务客户包括大型国企，国内头部互联网企业，海外政府项目和海外大型 IT 组织，涉及领域包括金融、物流、地产、教育等。
