一.迁移背景
老系统使用商业化软件,同时包含模块较多,架构无法支撑,维护成本高等考虑,需要根据业务模块拆分多个系统,新系统支持水平扩缩容 ,rcp框架等,新系统基本上包含常用的技术栈(wildfly、mysql、mycat、redis、ehcache、mq、kafka、zookeeper、hive、spark、rpc、多活等)。老系统使用的db2,需要迁移50亿+数据。
数据迁移包括两步:1.全量数据迁移;2.增量数据迁移
迁移:db2->mysql
二.系统及数据迁移难点
- 数据库分库分表规则、表字段及结构变化。
- 系统拆分包含了所有业务梳理及部分业务流程调整、bug修复等,导致新系统和老系统的数据可能不一致,但是都是正确的,数据对比等困难。
- 增量迁移期间会有新业务需求,新老系统同步开发,增加工作量和迁移难度。
系统的拆分和数据迁移,尽量要避免逻辑模型和业务调整。
三.全量数据迁移
全量数据迁移,使用spark+hive相关技术完成。
- 使用spark程序将原系统相关数据全部抽取到hive库中,分表的数据会汇总到hive库中的一张表里,便于数据处理
- 原始数据需要根据规则进行过滤,重复的、无效的、一些脏数据放入“无效数据表中”;符合规则的有效的数据放入“有效数据表”;逻辑复杂的与目标库无法直接映射的需要拆分的则放入“转换后的数据表”。最后通过任务统一灌入到目标库。
- 问题会员数据修复:删除这部分会员数据,重新从原始库中抽出会员的数据经过转换后写入目标库。
- 为确保写入的数据是完整的没有遗漏的,还会把mysql中的数据反抽到hive后和原始数据对比与分析。
四.增量数据迁移
全量数据迁移后还要进行增量数据迁移,因为线上数据是在不停的变化的,业务不能停止。通过抽数的方法是没办法追平的,使用接口增量同步的方式,该数据同步基本上覆盖新系统提供的所有rpc接口,能验证新系统的RPC接口服务正确性。
- 全量抽数开始前记录增删改接口交易报文到“增量数据待处理记录表”中,老系统中任何引起数据变化的操作都需要被记录。
- 全量数据灌入新系统mysql后启动“增量数据处理job”,通过调用新系统接口,让报文在系统中按照新系统逻辑执行。新系统中除RPC接口外还需要额外开发一些特殊的接口用于追增量数据。监控待处理表中的处理情况,分析问题并修复。
- 待增量数据处理完后,将新老系统中的数据抽取到hive中进行对比分析,验证新系统中数据是否有错,业务逻辑是否有问题。需要经过多轮对比并修复。数据差异较大,问题较大时需要全部重新迁移。
五.系统灰度切换
为保证灰度切换顺利进行,能够平滑的切换到新系统。需要全面考虑接口的切换顺序与会员灰度范围。灰度号段和接口逐渐放开。
- 配置公司内部会员id灰度至新系统,全员分场景验证。
- 开启部分实时性要求低的查询类接口灰度配置,配置少量会员。
- 开启增删改类接口灰度,配置少量会员,逐步扩大灰度接口及会员范围
- 最后请求全部路由至新系统,老系统充当前置路由系统,开始推动外围切换新系统