背景

旧交易系统存活时间比较久，随着组织架构的不断调整，旧交易新系统在各个团队轮转，技术和代码腐化严重，针对于新业务支持能力很差。

经过内部慎重决策，在旧交易系统基础上，针对技术和业务上进行重构，期望新架构在技术和业务上有一个良好的扩展性。

作为交易系统最为重要的就是稳定性，所以，如何让前置流量从旧系统平滑迁移至新系统，成为了我们现在主要解决的问题。

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

架构图

问题点

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

技术方案

同步收单

目的

同步收单主要考虑两点：

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

关注点

同时需要注意的点：

1. 新系统上线同步收单之前，一定要经过严格的QA测试，尽可能规避线上的一些问题
2. 关于新交易系统依赖的域内服务和域外服务一定要保证幂等性
   1. 支付：避免一笔订单重复支付（如果支付平台服务能力支持幂等性，自己针对业务逻辑处理好就可以，比如，发现已经支付过了，等同于支付成功处理）
   2. 扣库存：避免一笔订单重复扣库存
   3. as so on
   4. 针对上述这些外部服务能力，可以做开关（配置中心）把控，正式切流之后将开关放开。
3. 考虑到新旧架构订单号不一样，所以在履约能力处须mock掉订单号，以分销商ID和分销商订单号作为唯一标识（直连服务需提供元数据能力，即给你传一个元数据，需要给我原封不动传递回来）

域能力

增量数据核对

1. 同步收单之后，务必要做好监控措施，针对交易履约能力的问题点及时发现和处理。

2. 针对已经收单的增量订单，做好数据核对，可以及时发现系统问题。

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

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

切流放量

方案

切流之前务必将一些开关和mock的接口放开。

经过同步收单后，系统收单能力基本趋向正常，这时候要逐步切流。
切流阶段：

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

设计

流量比率由【直连网关系统】统一由调度策略组件配置分发。

履约回调之时，通过新旧订单标识将流量召回，也由直连网关统一调度。

订单同步

此时，订单数据存在两份，一个是旧系统的订单，还有一个是新系统的订单。

针对于订单数据是否需要同步的问题就要从业务的维度去做考量。

我们交易系统定位是B端交易，所以暂不涉及订单的实时查询，直接将新旧数据库同步到买家库和卖家库即可，当前，进行订单数据双写的时候我们新系统的增量数据是脏数据，在同步到买家库和卖家库之前清除脏数据即可。

如果是C端订单，用户可能需要实时的查看订单列表，此时，我们的方案就有一点问题。

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

系统下线

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