系统随着业务的发展,系统技术选型和层级划分都会进行或大或小的调整,在系统调整过程中,沉淀下来的数据需要得到良好的梳理和传承,对于非流水的属性类数据,需要随着系统的重构重新迁移、组合,但是在线的系统不允许大规模的停服来配合迁移,这个时候需要一套热迁移或者准热迁移的方案,下面我们来讨论下。
查了下类似的经验和方案,主要分一下几类:
1、完全停服,全量部署至新服务、迁移至新数据源(单写) 推荐指数 ☆☆☆
优点:逻辑简单、操作成本较低
缺点:停服影响用户体验,且不具备回滚方案,如上线后遇到问题风险较大
2、部分功能降级,停止写操作,迁移至新数据源(单写) 推荐指数 ☆☆
优点:对用户影响减小
缺点:需具备配合服务降级相关的流量控制能力,不具备回滚方案
3、停服部署、在原服务的基础上增加双写功能、数据源也采用双写 推荐指数 ☆☆☆☆
优点:可通过开关控制双写、具备回滚方案
缺点:操作成本较高、对接过程中的迭代需要同步支持、需要停服
4、不停服,增加缓冲层(MQ),数据迁移过程中增量数据写入缓存,在数据迁移完成、缓冲层数据消费完成后,打开开关开始双写数据库 推荐指数 ☆☆☆☆☆
优点:对用户无感,有回滚方案
缺点:操作成本高、方案操作节点、引入组件较多、研发和测试流程需要严格把控
针对五星方案操作流程图:
几个需要关注的点:
1、业务系统数据是否有中间态,双写上线时的在途数据兼容
2、数据迁移前业务系统数据是否需要前置对账,切割存量、轻装前行
3、双写工具是否能通用?