系统重构新旧流量平滑迁移方案

系统重构新旧流量平滑迁移方案

引用

CSDN

1.

https://blog.csdn.net/CSDN_SAVIOR/article/details/141201666

在系统重构过程中，如何实现新旧流量的平滑迁移是一个关键问题。本文详细介绍了针对B端交易系统的流量迁移方案，包括同步收单、增量数据核对、切流放量、订单同步等多个环节的具体实施步骤和技术要点。

背景

旧交易系统由于长时间运行和多次团队轮转，技术和代码腐化严重，对新业务的支持能力较差。因此，决定在旧系统基础上进行重构，以提升技术和业务的扩展性。作为交易系统，稳定性是首要考虑因素，因此，如何实现前置流量从旧系统平滑迁移至新系统成为当前的主要任务。

系统定位：B端交易系统
系统角色：分销商、平台主体、系统商

问题点

1. 系统的稳定性：如果新系统交易链路出现异常怎么办？容错性？可监控？可灰度？可回滚？
2. 订单一致性：新旧数据如何处理？是否需要迁移？留痕？冷库备份？

技术方案

同步收单

目的

同步收单主要考虑两点：

1. 为了后续流量平滑迁移做准备
2. 检查交易履约链路能力

关注点

同时需要注意的点：

1. 新系统上线同步收单之前，一定要经过严格的QA测试，尽可能规避线上的一些问题
2. 关于新交易系统依赖的域内服务和域外服务一定要保证幂等性

• 支付：避免一笔订单重复支付（如果支付平台服务能力支持幂等性，自己针对业务逻辑处理好就可以，比如，发现已经支付过了，等同于支付成功处理）
• 扣库存：避免一笔订单重复扣库存
• as so on
• 针对上述这些外部服务能力，可以做开关（配置中心）把控，正式切流之后将开关放开。

3. 考虑到新旧架构订单号不一样，所以在履约能力处须mock掉订单号，以分销商ID和分销商订单号作为唯一标识（直连服务需提供元数据能力，即给你传一个元数据，需要给我原封不动传递回来）

基本能力

增量数据核对

1. 同步收单之后，务必要做好监控措施，针对交易履约能力的问题点及时发现和处理。
2. 针对已经收单的增量订单，做好数据核对，可以及时发现系统问题。

• 量级不大，在本地库表写个定时任务写代码（连接双库客户端）比对就可以。
• 量级大，将双份数据同步到离线数仓，写sql比对也可以
• 如果考虑到实时性，可以在从库做sql比对

3. 旁路验证策略：在旧系统每个交易节点读取数据的时候，发送一个旁路验证事件，去查一遍新库，做一下数据比对，如果不一样，及时告警，及时处理。

切流放量

方案

切流之前务必将一些开关和mock的接口放开。经过同步收单后，系统收单能力基本趋向正常，这时候要逐步切流。

切流阶段：

1. 5%：主要针对各个交易环节，成单率作为核心监控点，一周时间为期限
2. 20%：主要观察业务指标和系统水位，一周为期限。
3. 50%：此时，流量已经达到一半，要对系统整体稳定性做出考量，该扩容就扩容，该限流就限流。
4. 100%：持续观察业务指标和系统水位，一周为期限。

设计

流量比率由【直连网关系统】统一由调度策略组件配置分发。履约回调之时，通过新旧订单标识将流量召回，也由直连网关统一调度。

订单同步

此时，订单数据存在两份，一个是旧系统的订单，还有一个是新系统的订单。针对于订单数据是否需要同步的问题就要从业务的维度去做考量。

我们交易系统定位是B端交易，所以暂不涉及订单的实时查询，直接将新旧数据库同步到买家库和卖家库即可，当前，进行订单数据双写的时候我们新系统的增量数据是脏数据，在同步到买家库和卖家库之前清除脏数据即可。如果是C端订单，用户可能需要实时的查看订单列表，此时，我们的方案就有一点问题。

1. 首先我们的订单号要保持一致，不能在同步双写的时候，写入两个系统的订单号不一致，这样后期订单数据同步的时候，数据就混乱了（当然也可以通过其他方式去避免，比如选取不同的唯一标识）；
2. 其次，在切流之前要将旧系统的存量数据同步到新系统的数据库中（这里要注意分库分表策略）；
3. 进而，进行存量数据核对；

系统下线

当新系统完成切流之后，需要观察一星期以上，方可将旧系统下线，主要是考虑到新系统的稳定性，可随时将流量切回旧系统。