严选交易数据源独立切换实践

1. 前言

严选在前期发展过程中，为了快速交付需求，绝大部分系统采用的都是单体架构，主站商城也不例外。

随着业务复杂度的不断攀升，才逐步开始进行业务拆分，由各个业务团队(商城、渠道以及仓配等等)在各自业务域内推动服务化改造，所在的主站商城业务团队随之相继孵化出交易中心、促销中心以及用户中心等等业务中心。

但是各业务中心DB资源共用的局面一直未得到改善，导致各业务中心数据持续处于裸奔状态，业务系统稳定性也大打折扣。

交易作为其中的一员，在经历了20-21年平台化改造的基础之后，通过业务抽象使得交易中心的平台化能力更加的内聚和稳定，故而我们决定乘胜追击进行交易DB资源独立拆解。

本文主要介绍了在当下的业务背景下存在挑战以及面对挑战的应对之法，最后详细介绍了基础保障工作的落地和核心独立流程的组织串联。

2. 业务背景

严选业务发展初期，为了支撑业务的快速发展，采用集中式架构和开发模式，上图所示为严选交易的架构演进路线，在早期，交易不仅仅业务耦合在商城中，且商城业务之间共享DDB集群。

截止到21年，交易借助业务抽象、架构分层以及标准化的思想逐步向中台化架构方向演进，但是订单操作等核心业务依然保留在交易前台业务中，导致需求迭代成本居高不下，代码严重腐化。同时商城中各业务的DDB资源利用率各不相同，出现能力过剩和瓶颈凸显两极分化的局面，亟需各业务进行边界治理。

边界治理的核心难点之一就是如何做好稳定性保障，因为涉及到能力迁移以及内外部依赖改造，如何确保改造范围的完整性、准确性以及平滑性，这与系统的稳定性息息相关。

以交易能力迁移为例，核心交易能力累计20+，能力依赖接口1000+，涉及30+表，因此在基于交易核心能力高度频繁使用的前提下，采取了先完成交易能力收归，再进行交易DB独立的执行策略， 在22年初完成了全量交易能力的迁移，基于这个背景条件之下，故而开展交易DB独立迁移工作。

3. 面临的挑战

在基于交易DB和商城DB共享的背景之下，需要达成交易DB独立于商城DB的核心目标，而目标的达成涉及交易DB迁移独立问题，结合交易业务场景的特殊性，交易DB作为核心业务的强依赖方，任何变动行为都有可能触达线上用户感知，故而这对我们提出了极大的挑战，确保对用户的影响最小，避免由于迁移独立引发一系列连带负面影响（诸如: 资损、客诉等问题产生），主要表现为3个方面，交易前用户无法进行交易行为、交易中用户交易行为被阻塞中断、交易后交易数据前后不一致。可以简单概括总结为对数据一致性和平滑迁移的保障:

• 数据一致性保障

• 数据不丢失：无论是切换到目标数据库或者回切回源数据库，要确保没有数据丢失；
• 不产生脏数据：需要保障同一笔订单数据在新数据库和老数据库之间保持一致。

• 平滑迁移保障
• 数据源切换平滑：在进行新老数据库切换过程中保证尽可能平滑切换；
• 业务切换平滑：需要确保在切换到新数据库的过程中受影响用户范围以及业务场景最少。

3.1 挑战：数据一致性保障

在数据一致性保障方面，主要是从两个方面入手，分别是数据迁移工具和业务切换方案的选择来确保，通过数据迁移工具来达成源数据库和目标数据库之间的数据同步，确保没有数据丢失现象产生，以及业务切换方案的制定，防止迁移过程中脏数据的引入。

3.1.1 迁移工具

3.1.1.1 杭研NDC

数据同步总体分为离线和实时两类，业内常见的离线数据同步方案有三种: Sqoop、DataX以及Kettle，实时数据同步主要有Canal、Otter以及杭研自研的NDC。而我们的业务场景决定了需要采用实时同步方案，在最终方案方案选型上采用了NDC（Netease Data Canal）。它是网易自研的一套集数据迁移、数据订阅、数据实时同步、数据校验于一体的数据传输服务。在支持 0 -> 1 全量数据迁移的同时，也可以很好的支持从1 ->1.1 增量同步，更为重要的是可以更好的支持DDB（目前NDC同步功能的源端可支持MySQL、DDB、Oracle三种类型，同步功能的目标端端可支持MySQL、DDB、Oracle， 交易业务全量使用DDB作为存储依赖）。

3.1.1.2 架构简介

架构上NDC大致可以分为源端系统、NDC集群和目标端系统三部分。NDC拉取源端系统的全量或增量数据，经过转化和过滤写入目标系统之中。架构图如下：

3.1.1.3 注意事项

NDC的回放的流程大致可以理解为与源端建立连接，拉取源端binlog，解析binlog，并对目标端进行相应dml操作，但是需要注意的是整个回放的过程中是不具备原子性的。所以在进行镜像库切换的过程中，会偶发出现数据不全的现象。

建议：需要使用方结合业务场景对数据的完整性和实时性的要求Case by Case分析，如果要求很高，可以在主库切换之前再做镜像库切换。

3.1.2 业务切换

业务平滑切换常见的落地方案主要有三类，分别是停写、不停写、双写，不同的方案各有优劣，虽然双写在业务上对用户层面上的感知是最小的，但是改造成本以及迁移周期也会随之增加，在结合严选商城C端现有业务流量特性（夜间流量相对偏低）以及成本等各项综合因素考量之下，最终方案选型上采用了数据库停写方案。

通过停写方案，可以确保在同一个时刻，只会有一个交易数据源可以提供写入，避免了多数据源写入导致的数据同步引发的数据覆盖，从而导致的脏数据的产生。

3.2 挑战:平滑迁移保障

平滑迁移保障主要从数据源动态切换和账号精准管控两方面入手：

• 通过数据源动态切换确保在切换过程中DB配置可以实时生效，不用重启就可以达到切换到目标数据源的效果；
• 针对账号精准管控，通过在源数据库中进行一系列账号重新分配、授权、回收等措施确保实际切换到目标数据库过程中不会产生遗漏。

3.2.1 数据源动态切换

3.2.1.1 严选Pandora

在进行数据源切换过程中，需要显式支持数据源的动态切换，业内也有很多比较成熟的动态切换数据源的方案总结（dynamic-datasource-spring-boot-starter、基于Springboot的AbstractRoutingDataSource等等），大致原理是通过配置多数据源从而达到动态切换的效果。最终还是选择了严选自研的中间件Pandora，相比较于业内的常见的方案，它在支持数据源的动态切换，无需重启的基础能力下，还支持数据源配置动态下发生效，前后数据源数据Diff（和数据源切换结合使用效果更佳）等功能特性。

3.2.2 账号精准管控

在迁移过程需要保障在切换到新交易数据源后不会存在有表遗漏等场景的出现，避免二次回切，因为本身在切换的过程中我们采用的方案是需要停写的，在生产环境这无疑会增加对线上用户的有损感知（即便是在流量低峰期），因此需要尽可能保障切换过程不会出现遗漏。

3.2.2.1 业务监控

如何高质量保障没有遗漏场景的产生，即现有对交易DB的所有写操作都已经全量收拢完成，不存在有遗漏的写操作，这是我们需要重点关注和解决的。

• 阶段一：DB层监控

• 初期寄希望于DDB自身，希望可以做到指定表的ip进行访问监控，但是很遗憾无法支持转而考虑使用消费Binlog的方式进行解析，但是整个主站的Binlog过于庞大。

• 阶段二：Proxy层监控
• 既然DB层监控不行，转而考虑代理层，APM中维护了服务于表的链路关系，可以显式的支持部分表集合和服务是否存在访问关系，但是随之而来的问题则是，这种关联关系无法详细区分读写，需要额外成本支持。但是通过此类方式可以确定交易表存在直连关系的服务是明确。
• 阶段三：Application层监控
• 既然圈定了服务范围，具体读写请求区分可以直接代码DAO拦截解析识别，辅之监控报警可以有效帮助识别是否还存在非预期场景。

总结解决方案：APM表查询 + AOP拦截

3.2.2.2 专号专用

在迁移过程需要保障在切换到新交易数据源后不会存在有表遗漏等场景的出现，避免二次回切，因为本身在切换的过程中是停写的，在生产环境这无疑会增加对线上用户的有损感知，因此需要尽可能保障切换过程不会出现遗漏，在实施策略上，主要通过隔离账号与权限隔离来保障， 确保专号专用：

• 账号隔离

• 通过对现有账号yanxuan进行拷贝相同权限账号yanxuan_new

• 权限隔离
• 针对yanxuan账号Exclude交易表集合
• 针对yanxuan_new 限定只允许访问交易表集合

3.2.2.3 质量回归

除此之外可以通过现有沉淀的自动化回归测试，帮助我们发现，在账号切换环节 or 权限回收环节验证现有流程的正确性，防止遗漏场景产生， 但是随之而来的问题则是，现有沉淀的自动化测试用例并没有100%覆盖，如果单纯依靠人工代码检查，则面临排查周期长，耗费精力，还有可能存在遗漏等问题。

代码变更分析SDK：目前SDK应用于集团各部门精准测试领域，由集团各BU测试团队来维护共建以及开源化，主要支持版本变更分析和指定方法分析：

• 版本变更分析

• 可以针对工程内（包括依赖的工程）两个不同分支或版本之间差异化代码进行Diff计算，得出变更的类和变更的方法。同时通过静态代码调用链路分析，计算出这些变更方法所影响的最上层Controller接口（或Service/Compont/RPC方法）。

• 指定方法分析
• 可以针对工程内（包括依赖的工程）指定类的指定方法，通过静态代码调用链路分析，计算出这些变更方法所影响的最上层Controller接口（或Service/Compont/RPC方法）。

通过借助代码变更分析SDK-指定方法分析可以完美契合我们的诉求，大致实现原理如下图所示：

下图所示是在天矶平台（基于精准SDK平台化产物）进行样例分析的DEMO，通过指定项目、指定类名、指定方法的方式帮助我们有效构建了依赖链路：

4 必备保障工作

4.1 数据源动态切换改造

涉及迁移的业务方需要显式接入Pandora用于数据库配置的动态下发。除了Pandora接入之外，由于我们的应用中只有交易切换了新交易DB，必然还会保留有部分业务对主站DB的访问。因此整体的改造设计思路是进行数据源拷贝 + 数据源动态切换识别来实现的，具体实现思路可以参照下图：

DataSourceA是系统默认数据源（主站DB），DataSourceB是对DataSourceA的拷贝，在进行主站DB切换之前，DataSourceA和DataSourceB都用于对主站DB的访问。当通过Pandora切换到交易DB后，DataSourceA的连接从源数据库（主站DB）切换到了目标数据库（交易DB），但是由于系统默认的是数据源是DataSourceA，针对非交易业务DB资源的访问需要通过DataSourceB才可以获取，因此需要显式识别切换。

4.2 事务中切换数据源

由于涉及迁移工程的项目都使用了Spring+MyBatis用于访问操作数据源，基于交易DB独立必然性的条件基础之下，必然涉及到事务中切换数据源的问题。

我们知道如果开启Spring事务，则先有Spring的Transaction，然后Mybatis创建SqlSession时，会创建SpringManagedTransaction并加入SqlSession中，通过查看源码可知SpringManagedTransaction中的Connection会从TheadLocal中获取（@Transaction会创建的Connection并放入ThreadLocal，ThreadLocal是以DataSource生成的actualKey为key值和ConnectionHolder作为value值封装成的Map）。

因此想要支持事务中切换数据源，必须改写SqlSessionTemplate，复写getSqlSession方法，根据需要切换的key（对应具体数据源），重新构造SqlSession。如果SqlSession包含的数据源是开启事务的数据源就会取Spring已经创建的，否则就会重新创建。

4.3 大数据平台切换

根据数据集成平台Datahub现有功能支持，如果主站库（源数据库）表直接切换到订单库（目标数据库）且使用订单库现有数仓表命名规则，则需要把迁移过的rdb表名全部更改名称，工作量巨大且存在较大风险。

考虑到目标库（历史已经存在，但是核心的交易表相关数据依然存留在主站库中）现有数仓表仅被1个下游任务依赖，采用单独配置订单库binlog Kafka topic、rdb表名适配被迁移的主站表命名的方式进行切换，基本可以做到被迁移表相关离线数仓任务不需要感知影响，最大限度减少下游影响。

5 独立流程编排

独立流程是通过开发人为操作指令来实施的，因此在实施过程中如何确保不出错，高效完成独立需要重点关注的。需要所有参与人员明确整体的独立思路、敲定详细的独立步骤（约束行为），以及通过反复的独立演练帮助我们发现问题，以此来不断优化完善我们的独立流程。

5.1 独立思路

整体迁移思路是针对交易表写权限已经回收完成（依赖交易能力全量收拢完成）背景之下开展，整体流程上大致可以分为两个阶段：镜像库切换阶段和主库切换阶段。

• 镜像库切换

• 流程上可以先行主库切换，有助于发现问题；
• 因为引入了NDC，相比较于常规的镜像库复制流程，链路被放大，延迟略有提升。

• 主库切换
• 在完成主库切换之后，需要断开源数据库与目标数据库之间的NDC同步任务，同期创建反向同步任务，防止回切造成数据丢失。

5.2 独立流程

大致迁移流程如图所示，主要包括迁移阶段、回滚阶段、以及收尾阶段。

5.3 验证演练

由于交易DB切换涉及服务众多（累计13个核心服务），因此在生产环境切换之前，需要在测试环境进行反复演练，即正向（源数据库->目标数据库）和逆向（目标数据库-> 源数据库）流程全量切换演练。通过切换演练有助于完善现有的切换剧本，细化人员分配安排，以及明确业务影响观察指标。

在测试环境交易DB的迁移的过程中，依托前置完善后的用例场景全量回归不仅仅可以帮助发现迁移过程是否有遗漏，还可以对原有的交易能力收拢进行二次查漏补缺，确保万无一失。

在切换过程中可以借助NDC的数据比对校验能力，帮助我们测出源端与目标端不一致的数据，保证数据同步功能的正确性。

6 总结

针对严选交易DB如何进行数据源独立以及在数据源切换整体流程的解决方案以及实施迁移的过程中遇到的一些问题解决思路作为经验分享给大家，希望对后续业务团队在进行相关工作开展有所帮助。