阿里云数字新基建系列:云数据库架构

4.4　不同场景下的数据迁移方案 前面讲述了数据迁移的步骤、不同的数据库类型的迁移方式以及各种迁移工具，本节会以一个电商平台的系统架构发展的角度，列举自建数据库上云过程中的几个典型场景，通过前面讲述的内容对这些场景的迁移方案进行讨论和分析。 4.4.1　场景1：一对一迁移 A公司是一家小型电商创业公司，其电商平台涵盖了店铺、商品、订单、搜索、会员管理等模块，前期出于客户体量较低以及成本考虑，公司的技术团队使用图4-16所示的系统架构。 从这个框架中可以看到，该公司使用一台应用服务器进行业务请求的处理，业务系统的各个模块全部运行在该服务器上，并且使用了主备模式的数据库进行数据的存储和查询。该系统架构在业务发展初期已经完全可以满足需求。 假设该阶段公司技术团队为了更加灵活地对资源进行控制，应对突发流量对业务系统的压力，降低IT成本，决定对这套业务系统进行上云操作。 该系统上云分为两部分：应用与数据库。针对应用系统上云，技术团队选择在云上购买一台ECS服务器部署应用程序。重点讨论数据库上云，为了数据库系统的稳定和快速恢复，技术团队选择购买高可用版本的RDS MySQL数据库，由于本地的数据库是主备模式，而云上RDS for MySQL的高可用版本虽然也是主备模式，但是高可用的备节点主要做容灾，无法对外提供服务，所以要满足真正的主备模式，还需要在RDS高可用实例中添加一个只读节点来充当本地数据库架构中的备节点。产品选型之后的数据库架构如图4-17所示。 图4-16　系统架构 图4-17　一对一复制 产品选型完成后，开始对数据库进行迁移。在进行正式迁移之前，技术团队考虑了如下几点要素。 l 迁移工具：由于DTS对MySQL→MySQL的迁移支持非常好，而且支持增量迁移，方便业务切换，迁移工具决定使用DTS。 l 连接方式：考虑到数据安全和传输速率的影响，DTS连接本地数据库的方式使用专线连接。 l 业务影响：由于DTS迁移会对表的数据进行全表扫描，业务高峰期迁移会严重影响业务响应，故把迁移时间安排在了夜间零点之后。而且为了进一步降低对本地数据库主节点的影响，决定开启本地备节点数据库的Binlog，DTS连接本地备节点数据库进行数据迁移。 l 停机时间：由于云上有完整的一套业务系统，业务切换时只需将业务流量切换到云上系统即可，停机时间基本可以忽略。 l 迁移时间规划：本地数据库业务表数量500个，数据大概300GB，借助DTS，结构+全量数据理想情况下可以在3~4个小时内完成，后进行增量数据的持续迁移。 l 迁移策略：为了充分评估云上系统的性能，决定分批次切换现有用户流量到新的系统，并且持续保持本地数据库系统到云上数据库系统的数据同步，直到业务完全切换到云上且稳定运行后断开。如果在理想时间内因未知问题导致没有完成结构+全量的数据迁移，则取消迁移，评估解决实际问题后重新规划时间。 一对一迁移的迁移流程和*终架构如图4-18所示。 图4-18　一对一迁移 这是一对一迁移的典型场景，也是*简单的上云场景，由于业务模块全部在一个服务器中，不需要考虑业务模块上云的先后和调用问题。但是如果遇到多个业务模块耦合性较强的迁移场景，由于无法保证多个业务系统同一时间全部上云，直接这样一刀切就无法实现，这种多业务模块的场景迁移方案我们会在下一节讨论。 4.4.2　场景2：一对多高耦合业务迁移 随着A公司业务的发展以及人员的增多，之前的系统架构显现出了严重的问题，首先是所有的业务模块代码都放在一台主机上运行，且代码之间依赖性强，导致运维开发效率非常低，业务代码放到一台主机上运行，单台应用主机性能有限。其次是所有的请求全部与关系型数据库交互，热点数据容易给数据库造成非常大的压力，读写成为瓶颈。考虑到这两个主要因素，公司技术团队对其系统架构进行了调整。首先把业务进行拆分，独立到各个服务器中进行部署，各个系统之间如果有依赖则远程调用，其次，增加缓存数据库，降低热点请求对数据库压力的影响，如图4-19所示。 图4-19 　原始多服务业务 假设在该阶段，为了实现资源的灵活可扩展，现公司的技术团队讨论决定让这套业务系统上云。 该系统上云分为三个部分。 应用系统：本地业务子系统有多套，各子系统之间存在请求调用。出于某些原因，无法同一时间让这些系统全部上云，决定先让订单子系统以及会员子系统上云。针对应用系统上云，只需在云上购买两台ECS服务器部署订单子系统和会员子系统。上云后由于订单和会员子系统与商品、库存、店铺等子系统存在调用关系，可以通过专线实现调用。 数据库MySQL：为了突破单体数据库的容量瓶颈，技术人员决定将数据库内的对象按照业务子系统进行拆分，将不同子系统的数据库对象迁移到云上的不同RDS实例中，且维持主备模式。针对数据库MySQL上云，购买多台RDS数据库主实例以及对应的只读实例。 数据库Redis：对于本地Redis，云上也有对应的Redis产品，购买云上Redis主从版，云Redis主从版与RDS高可用版架构相同，都是主备架构，备节点不提供服务。 与一对一迁移评估的要素相比，技术团队增加了如下几点要素。 迁移工具：考虑到操作的简便性，Redis→Redis的迁移同样选择用DTS进行。 迁移场景：由于要把本地数据库对象拆分到多个RDS中，迁移拓扑为1∶n迁移，需要使用多个DTS任务分别迁移本地数据库的各个子系统对象到云上的多台RDS数据库中。 一对多迁移的迁移流程和*终的架构如图4-20所示。 高耦合业务数据迁移场景一般发生在源端业务系统有多个，业务之间互相依赖性很强，而且依赖的数据库是同一个的情况。比如源端业务系统有多个，业务系统之间相互调用，如果迁移时做不到多个系统同一时间上云，首先需要考虑云上系统与云下系统的交互问题，其次需要考虑云上系统与云下系统的请求一致性问题，比如订单子系统一致性要求较高时，可以考虑订单子系统的写入和查询请求都通过专线访问本地数据库，然后由数据同步程序同步至云上数据库，如果会员子系统的一致性要求较弱，则可以直接读写云上数据库。 图4-20　一对多迁移 4.4.3　场景3：多对一异构迁移 随着A公司业务的继续高速增长，之前的系统架构再次面临了业务侧的挑战：单体数据库的容量与性能成为瓶颈，不能满足以后的业务需求。为了解决这个问题，公司技术团队决定对数据库进行垂直拆分与水平拆分，首先将单体数据库按业务维度拆分成多个独立的数据库，再对拆分后的数据库按照业务逻辑实体（假设为Y）维度水平拆分为多个独立的数据库，业务系统与拆分的数据库通过分布式数据中间件进行交互，各个独立数据库维持主备模式，如图4-21所示。 图4-21　多业务原始模型 更换到这个架构之后，当前系统可以满足业务相当长一段时间的发展。但是这个架构在进行实时报表分析时，无法满足分析要求，技术团队决定将这些数据迁移到云上OLAP数据库进行实时报表分析。在产品选型方面，由于本地数据库是MySQL数据库，技术团队考虑使用云上的云原生数据仓库MySQL版（简称ADB MySQL）进行实时报表分析。 在迁移评估要素方面，技术团队比之前增加了如下几点。 迁移工具：由于DTS对MySQL→ADB MySQL的迁移支持较完善，且支持增量迁移方便实时数据的同步以及库表映射，所以迁移工具决定使用DTS。 停机时间：报表分析业务是一套允许停机时间的独立业务系统，停机时间可以不作为重点考量的对象。 数据库对象映射：由于ADB MySQL数据库语法、数据库对象、数据类型等并非100%兼容MySQL，迁移时需要涉及一些类型的映射，比如 varchar类型，ADB中的varchar对应MySQL中的char、varchar、text、mediumtext或者longtext。其次，ADB MySQL不支持存储过程、函数等数据库对象，在迁移时也需要避免。*后还需要名称的映射，本地数据库的数据库表做了分库分表，迁移到云上ADB MySQL进行分析后，需要将这些分表的数据整合到ADB MySQL的一个表中。 迁移场景：由于本地数据库是分布式数据库，迁移到云上的一台ADB MySQL属于n∶1迁移，同样需要使用多个[1]DTS任务分别迁移本地分布式数据库的各个分库对象到云上ADB MySQL中进行数据合并（对象映射）。