ShardingSphere 异构迁移最佳实践：将3.5亿量级的顾客系统 RTO 减少60倍

关注

原创 2022-06-13 15:08:58 329 阅读 AI 写同款· GEO 优化 ›

Apache ShardingSphere 助力当当 3.5 亿用户量级顾客系统重构，由 PHP+SQL Server 技术栈无缝转型为 Java+ShardingSphere+MySQL，性能、可用性及维护性均得到显著提升，是 ShardingSphere 异构迁移最佳实践。

1 顾客系统背景

当当顾客系统主要负责账户的注册、登录、隐私数据维护等功能，历史技术栈为 PHP+SQL Server，是标准的集中式架构，如下图。

重构项目启动前，顾客系统的数个业务模块存在多个棘手的业务问题和技术挑战，如逻辑分散、吞吐量低及运维成本高等问题。为改善顾客的购物体验，当当技术团队决定对业务逻辑和底层数据架构进行优化，实现顾客系统多场景下的可用性、扩展性及综合提升等多个目标。在重构过程也实现了众多技术创新，如跨数据源双写、读写分离、智能网关及灰度发布等技术。

从需求设计、分库分表规划、逻辑优化、压测再到完全上线等多个环节，当当技术团队用半年的时间完成了基于 3.5 亿+用户的系统重构。

使用 Java 语言重构十余个模块，通过 ShardingSphere+ MySQL 构建分布式数据库解决方案，顺利完成异构数据库在线迁移，案例亮点如下。

使用 Java 语言重构 PHP 业务代码；
使用 ShardingSphere+MySQL 替换 SQL Server；
在线完成 3.5 亿用户数据完整迁移；
通过数据双写方案完成无缝上线。

2 痛点&挑战

业务痛点

在业务层面，顾客系统部分模块的注册和登录逻辑分散在各端，维护成本较高，且当时的技术架构对于性能的提升和高可用性存在着很大的局限性。

不易维护：多平台注册和登录逻辑较为分散，业务维护复杂；
性能受限：PHP+SQL Server 集中式技术架构，吞吐量不足；
可用性&安全性差：
- SQL Server 主备状态变化后，订阅库会失效，重新配置需要窗口时间；
- SQL Server 运行在 Windows Server 上，病毒影响导致安全性差，且打补丁后升级启动时间长（>30min）。

挑战

数据完整性

顾客系统拥有 3.5 亿+ 用户数据，在数据迁移过程中，需保证数据从 SQL Server 迁移到 MySQL 后的一致性及完整性；

API 透明

API 对调用方保持透明，确保调用方无改动，最小化变更界面；

无缝切换

需要满足业务系统无缝切换，切换过程对业务无影响；

时间紧迫

“618”和“11.11”促销活动前后会封网，因此需在两大促活动间、有限窗口的时间内完成切换，并紧接着面对“11.11”的验证。

3 解决方案

整体规划

为了改善顾客系统的可维护性、可用性及性能，研发团队重新梳理顾客系统的架构。

在应用层，统一各端的功能逻辑，提升业务可维护性。在数据库层，将集中式架构调整为分布式数据库架构，提升性能及可用性，即 ShardingSphere+MySQL 构建的开源分布式解决方案。

应用层：随当当整体技术栈的变迁，业务开发语言由 PHP 转为 Java；
中间件：使用成熟的开源数据库中间件 ShardingSphere 实现分库分表；
数据库：使用多套 MySQL 集群代替 SQL Server 数据库。

在整体架构设计上，引入了分布式主键生成策略、分片管理、数据迁移校验以及灰度发布等多个方案。

分布式主键生成策略

数据库架构由集中式转型为基于中间件的分布式架构，分布式主键生成策略是首先需要考虑解决问题。在系统重构中，选择建立两台以上的数据库 ID 生成服务器，每台服务器都有一张记录各表当前 ID 的 Sequence 表，Sequence 中 ID 增长的步长是服务器的数量。起始值依次错开，这样相当于把 ID 的生成散列到了每台服务器节点上。

分片（ShardingSphere）

在顾客系统重构中，通过 Apache ShardingSphere 完成数据库 Sharding，同时也启用了读写分离功能。

由于顾客系统在高并发、低延时的要求，接入端选择了 ShardingSphere-JDBC，它定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。