背景
公司在进行技术体系迁移,由原来的.net+sqlserver迁移到现在的java+mysql微服务体系.
这个大工程的实施是按子系统拆分逐步实现的,业务开发完后,通过流量网关切换流量到目标服务.由于服务之间的依赖,在现有运行期间,存在服务互相调用,数据互相同步的场景.这里着重说数据同步,数据迁移的解决方案.
上线方式是通过微服务逐步替换掉线上的.net服务,而原有.net体系内还有数据依赖,停掉.net服务后,数据还要从mysql同步回写到sqlserver.当依赖的服务也被替换下线后,数据同步服务就需要下线,不能依赖业务.为此,我从全量迁移,增量迁移,业务强依赖三个指标展开.ETL加载策略(增量/全量/流式)
场景一.对业务逻辑依赖性强,同步服务发生在单条数据修改时需要同步,方式灵活,对数据自定义要求较高.
解决方案:dts(数据传输服务)
优点:DTS服务是java微服务,主要是通过消费rabbitmq消息通知实现数据同步请求,client端在业务代码中插入consumer代码,所有的数据同步消息都会集中到rabbitmq中,由dts逐步消费,及时服务挂了,rabbitmq也能缓存这些未做任务.
缺点:dts的性能要求较高,在实际生产环境中,经常出现dts服务宕机,尤其是在同步高峰期,dts的流量经常被打满.因为dts消费完消息后,要往各个数据源同步执行CRUD操作.频繁的建立和销毁连接.
场景二.对业务逻辑依赖弱.跨数据源,实时性要求低,快速实现表的全量同步.
解决方案:datax(离线数据全量同步)
优点:适合基础字典表,例如类目,栏目或者被依赖的数据字典表同步,由datax job执行脚本,可以编写复杂的SQL同步语句,程序自定义程度强,较为灵活,支持主流的数据源,跨平台跨语言,其设置的schedule模式后,无需人工干预自动执行,后期服务下线也方便,支持多job执行模式.
- 实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。
缺点:同步实时性不强,基于存量数据的同步.
场景三:对业务逻辑依赖弱,跨数据源,实时性要求高,快速实现表的增量同步
解决方案:alibaba canal(在线数据增量同步)
优点:实时性强,基于mysql的binlog日志流读取,同步到其他数据源,方便业务无关性,通常无需程序员介入.
缺点:实时性要求对性能要求较高,在非集群模式下,单台服务8G内存,10个管道就有点吃不消了.
参考文档