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

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

1  顾客系统背景

当当顾客系统主要负责账户的注册、登录、隐私数据维护等功能,历史技术栈为 PHP+SQL Server,是标准的集中式架构,如下图。
《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

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

从需求设计、分库分表规划、逻辑优化、压测再到完全上线等多个环节,当当技术团队用半年的时间完成了基于 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 数据库。
    《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

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

分布式主键生成策略

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

分片(ShardingSphere)

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

由于顾客系统在高并发、低延时的要求,接入端选择了 ShardingSphere-JDBC,它定位为轻量级 Java 框架,在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库,以 jar 包形式提供服务,无需额外部署和依赖,可理解为增强版的 JDBC 驱动,完全兼容 JDBC 和各种 ORM 框架。
《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

  • Sharding

ShardingSphere 支持非常全面的分片算法,包括取模、哈希、范围、时间及自定义等算法,顾客系采用取模分片算法对大表进行拆分。

  • 读写分离

除了 Sharding,同时还启用 ShardingSphere 读写分离功能,充分利用 MHA 集群资源,提升系统吞吐能力。
《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

双写&数据同步

数据同步贯穿了整个重构项目,数据迁移的完整性及数据一致性是重构的关键。

该案例基于 Elastic-Job 同步历史数据,以周期的方式将 SQL Server 的历史数据同步到 MySQL 中。

关于数据库切换方面,在切换过程中会采用备份方案,进行数据库的双写,保证切换前后的数据一致性,过程如下。

第 1 步:实现双写机制

断掉链路 1,打通链路 2、3、4,打通链路 9、10。

第 2 步:切换登录服务

断掉链路 9,10,打通链路 7,断掉链路 5。

第 3 步:切换读服务

打通链路 8,断掉链路 6。

第 4 步:取消双写机制

断掉链路 2,完成切换。
《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

在数据校验方面,通过业务侧和数据库侧两个方面进行验证,均周期性进行检查,在不同时间段采用不同的频率,抽样或全量检查数据的完整性,在数据库侧也会进行 COUNT/SUM 的验证。

顾客系统重构使用了基于 apollo 的灰度发布方式,在新登录方式的处理上,通过配置项逐步放开、小范围陆续割接,确保上线成功率。重构后的系统架构如下图。
《ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍》

4  用户收益

经过重构,当当顾客系统响应速度明显提升,同时也降低了日常运维成本,ShardingSphere 提供的分布式解决方案功不可没。该方案适用于各种高流量的互联网平台服务,也适用于电商平台以及其他以数据处理为主的系统。

  • 性能提升,响应速度提升 20% 以上;

  • 可用性增强,ShardingSphere+MySQL 的方案实现 RTO<30s;

  • 易于维护,业务逻辑以及数据库的可维护性明显提升;

  • 无缝迁移,6 个月内在线完成各模块割接,窗口时间为零。

5  总结

在“ShardingSphere 助力当当 WMS:订单效率提升 30%、节约成本上千万”案例之后,这是第二篇 ShardingSphere 在当当的实践案例。

Apache ShardingSphere 为业务系统提供了强力的支撑。简单与极致,是 ShardingSphere 突出的两个特性,让业务逻辑更简单,让性能更极致。

Apache ShardingSphere 社区已在开源领域耕耘了 7 年的时间。长久的坚持,使社区愈加成熟,已呈开放和多元化的势态。我们诚心欢迎有开源情怀和编码热情的朋友一起参与社区共建,也欢迎您提供优质案例内容分享给社区的朋友们。

如果大家对 Apache ShardingSphere 有任何疑问或建议,欢迎在 GitHub Issue 列表提出,或可前往中文社区交流讨论。

GitHub Issue:https://github.com/apache/shardingsphere/issues

贡献指南:https://shardingsphere.apache.org/community/cn/contribute/

中文社区:https://community.sphere-ex.com/

    原文作者:SphereEx
    原文地址: https://www.cnblogs.com/sphereex/p/16371022.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞