一.迁移背景

老系统使用商业化软件，同时包含模块较多，架构无法支撑，维护成本高等考虑，需要根据业务模块拆分多个系统，新系统支持水平扩缩容 ，rcp框架等，新系统基本上包含常用的技术栈（wildfly、mysql、mycat、redis、ehcache、mq、kafka、zookeeper、hive、spark、rpc、多活等）。老系统使用的db2，需要迁移50亿+数据。

数据迁移包括两步：1.全量数据迁移；2.增量数据迁移

迁移：db2->mysql

二.系统及数据迁移难点

1. 数据库分库分表规则、表字段及结构变化。
2. 系统拆分包含了所有业务梳理及部分业务流程调整、bug修复等，导致新系统和老系统的数据可能不一致，但是都是正确的，数据对比等困难。
3. 增量迁移期间会有新业务需求，新老系统同步开发，增加工作量和迁移难度。

系统的拆分和数据迁移，尽量要避免逻辑模型和业务调整。

三.全量数据迁移

全量数据迁移，使用spark+hive相关技术完成。

1. 使用spark程序将原系统相关数据全部抽取到hive库中，分表的数据会汇总到hive库中的一张表里，便于数据处理
2. 原始数据需要根据规则进行过滤，重复的、无效的、一些脏数据放入“无效数据表中”；符合规则的有效的数据放入“有效数据表”;逻辑复杂的与目标库无法直接映射的需要拆分的则放入“转换后的数据表”。最后通过任务统一灌入到目标库。
3. 问题会员数据修复：删除这部分会员数据，重新从原始库中抽出会员的数据经过转换后写入目标库。
4. 为确保写入的数据是完整的没有遗漏的，还会把mysql中的数据反抽到hive后和原始数据对比与分析。

四.增量数据迁移

全量数据迁移后还要进行增量数据迁移，因为线上数据是在不停的变化的，业务不能停止。通过抽数的方法是没办法追平的，使用接口增量同步的方式，该数据同步基本上覆盖新系统提供的所有rpc接口，能验证新系统的RPC接口服务正确性。

1. 全量抽数开始前记录增删改接口交易报文到“增量数据待处理记录表”中，老系统中任何引起数据变化的操作都需要被记录。
2. 全量数据灌入新系统mysql后启动“增量数据处理job”，通过调用新系统接口，让报文在系统中按照新系统逻辑执行。新系统中除RPC接口外还需要额外开发一些特殊的接口用于追增量数据。监控待处理表中的处理情况，分析问题并修复。
3. 待增量数据处理完后，将新老系统中的数据抽取到hive中进行对比分析，验证新系统中数据是否有错，业务逻辑是否有问题。需要经过多轮对比并修复。数据差异较大，问题较大时需要全部重新迁移。

五.系统灰度切换

为保证灰度切换顺利进行，能够平滑的切换到新系统。需要全面考虑接口的切换顺序与会员灰度范围。灰度号段和接口逐渐放开。

1. 配置公司内部会员id灰度至新系统，全员分场景验证。
2. 开启部分实时性要求低的查询类接口灰度配置，配置少量会员。
3. 开启增删改类接口灰度，配置少量会员，逐步扩大灰度接口及会员范围
4. 最后请求全部路由至新系统，老系统充当前置路由系统，开始推动外围切换新系统

一.迁移背景老系统使用商业化软件，同时包含模块较多，架构无法支撑，维护成本高等考虑，需要根据业务模块拆分多个系统，新系统支持水平扩缩容 ，rcp框架等，新系统基本上包含常用的技术栈（wildfly、mysql、mycat、redis、ehcache、mq、kafka、zookeeper、hive、spark、rpc、多活等）。老系统使用的db2，需要迁移50亿+数据。数据迁移包括两步：1... 继承。所谓的继承，类似于面向对象中的继承，即新 系统 要完全兼容旧 系统 的 业务 功能。 3、高技术低 业务 价值 集成。因为技术含量高，修改未必能改得更好，而低价值则表明没必要更改，所以结果就是不改，集成了事。 4、高技术高 业务 价值 改造。因为 业务 价值高，值得一改；高技术，但也许 数据 模型跟新 系统 不合，功能... Harbor高可用部署 Harbor是一个用于存储Docker镜像的企业级Registry服务。 官方是通过docker-compose方式部署harbor的。接下来通过docker-compose和主从复制的方式部署高可用的harbor，对于harbor没有太高访问需求的情况下该方式比较合适。 主机说明：