Apache ShardingSphere 助力当当 3.5 亿用户量级顾客系统重构，由 PHP+SQL Server 技术栈无缝转型为 Java+ShardingSphere+MySQL，性能、可用性及维护性均得到显著提升，是 ShardingSphere 异构迁移最佳实践。
1 顾客系统背景
当当顾客系统主要负责账户的注册、登录、隐私数据维护等功能，历史技术栈为 PHP+SQL Server，是标准的集中式架构，如下图。
在重构工程开始之前，客户系统的几个业务模块都存在很多棘手的业务问题和技术挑战，如分布式逻辑、低吞吐量和高运维成本。为了提升客户的购物体验，当当技术团队决定对业务逻辑和底层数据架构进行优化，以达到客户系统在多场景下的易用性、可扩展性和全面提升的目标。在重构过程中，还实现了跨数据源双写、读写分离、智能网关、灰度发布等多项技术创新。
[En]
Before the start of the reconfiguration project, there are many thorny business problems and technical challenges in several business modules of the customer system, such as distributed logic, low throughput and high operation and maintenance costs. In order to improve the customer’s shopping experience, the Dangdang technical team decided to optimize the business logic and underlying data architecture to achieve the goals of usability, scalability and comprehensive improvement of the customer system in multiple scenarios. In the process of reconstruction, many technological innovations have also been realized, such as double writing across data sources, separation of read and write, intelligent gateway and grayscale publishing.
从需求设计、子库和子表规划、逻辑优化、压力测试到完成上线等环节，半年时间当当技术团队完成了基于3.5亿+用户的系统重构。
[En]
From requirements design, sub-library and sub-table planning, logic optimization, stress testing to complete online and other links, Dangdang technical team completed the system reconfiguration based on 350 million + users in half a year.
使用 Java 语言重构十余个模块，通过 ShardingSphere+ MySQL 构建分布式数据库解决方案，顺利完成异构数据库在线迁移，案例亮点如下。
- 使用 Java 语言重构 PHP 业务代码；
- 使用 ShardingSphere+MySQL 替换 SQL Server；
- 在线完成 3.5 亿用户数据完整迁移；
- 通过数据双写解决方案无缝上线
[En]
seamlessly go online through the data double-write solution.*
2 痛点&挑战
业务痛点
在业务层面，客户系统的一些模块的注册和登录逻辑分散在每一端，维护成本高，当时的技术架构对性能和高可用性的提升有很大限制。
[En]
At the business level, the registration and login logic of some modules of the customer system are scattered in each end, the maintenance cost is high, and the technical architecture at that time has great limitations for the improvement of performance and high availability.
- 不易维护：多平台注册和登录逻辑较为分散，业务维护复杂；
- 性能受限：PHP+SQL Server 集中式技术架构，吞吐量不足；
- 可用性&安全性差：
- SQL Server 主备状态变化后，订阅库会失效，重新配置需要窗口时间；
- SQL Server 运行在 Windows Server 上，病毒影响导致安全性差，且打补丁后升级启动时间长（>30min）。
挑战
- *数据完整性
顾客系统拥有 3.5 亿+ 用户数据，在数据迁移过程中，需保证数据从 SQL Server 迁移到 MySQL 后的一致性及完整性；
- *API 透明
API 对调用方保持透明，确保调用方无改动，最小化变更界面；
- *无缝切换
要满足业务系统的无缝切换，切换过程对业务没有影响。
[En]
It is necessary to meet the seamless switching of the business system, and the switching process has no impact on the business.
- *时间紧迫
“618”和”11.11″促销活动前后会封网，因此需在两大促活动间、有限窗口的时间内完成切换，并紧接着面对”11.11″的验证。
3 解决方案
整体规划
为了提高客户系统的可维护性、可用性和性能，研发团队对客户系统的架构进行了重新梳理。
[En]
In order to improve the maintainability, availability and performance of the customer system, the R & D team re-combs the architecture of the customer system.
在应用层，统一各端的功能逻辑，提升业务可维护性。在数据库层，将集中式架构调整为分布式数据库架构，提升性能及可用性，即 ShardingSphere+MySQL 构建的开源分布式解决方案。
- 应用层：随当当整体技术栈的变迁，业务开发语言由 PHP 转为 Java；
- 中间件：使用成熟的开源数据库中间件 ShardingSphere 实现分库分表；
- 数据库：使用多套 MySQL 集群代替 SQL Server 数据库。
在总体架构设计中，介绍了分布式主密钥生成策略、分片管理、数据迁移与验证、灰色释放等方案。
[En]
In the overall architecture design, many schemes are introduced, such as distributed primary key generation strategy, fragment management, data migration and verification, gray release and so on.
分布式主键生成策略
数据库架构由集中式转型为基于中间件的分布式架构，分布式主键生成策略是首先需要考虑解决问题。在系统重构中，选择建立两台以上的数据库 ID 生成服务器，每台服务器都有一张记录各表当前 ID 的 Sequence 表，Sequence 中 ID 增长的步长是服务器的数量。起始值依次错开，这样相当于把 ID 的生成散列到了每台服务器节点上。
分片（ShardingSphere）
在顾客系统重构中，通过 Apache ShardingSphere 完成数据库 Sharding，同时也启用了读写分离功能。
由于顾客系统在高并发、低延时的要求，接入端选择了 ShardingSphere-JDBC，它定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
- Sharding
ShardingSphere 支持非常全面的分片算法，包括取模、哈希、范围、时间及自定义等算法，顾客系采用取模分片算法对大表进行拆分。
- 读写分离
除了 Sharding，同时还启用 ShardingSphere 读写分离功能，充分利用 MHA 集群资源，提升系统吞吐能力。
双写&数据同步
数据同步贯穿于整个重构项目，数据迁移的完整性和一致性是重构的关键。
[En]
Data synchronization runs through the whole refactoring project, and the integrity and consistency of data migration are the key to refactoring.
该案例基于 Elastic-Job 同步历史数据，以周期的方式将 SQL Server 的历史数据同步到 MySQL 中。
在数据库切换方面，切换过程中将采用备份方案，对数据库进行双写操作，确保切换前后数据的一致性。其过程如下。
[En]
With regard to database switching, a backup scheme will be adopted in the switching process to double write the database to ensure data consistency before and after switching. The process is as follows.
第 1 步：实现双写机制
断掉链路 1，打通链路 2、3、4，打通链路 9、10。
第 2 步：切换登录服务
断掉链路 9，10，打通链路 7，断掉链路 5。
第 3 步：切换读服务
打通链路 8，断掉链路 6。
第 4 步：取消双写机制
断掉链路 2，完成切换。
在数据校验方面，通过业务侧和数据库侧两个方面进行验证，均周期性进行检查，在不同时间段采用不同的频率，抽样或全量检查数据的完整性，在数据库侧也会进行 COUNT/SUM 的验证。
顾客系统重构使用了基于 apollo 的灰度发布方式，在新登录方式的处理上，通过配置项逐步放开、小范围陆续割接，确保上线成功率。重构后的系统架构如下图。
4 用户收益
经过重构，当当顾客系统响应速度明显提升，同时也降低了日常运维成本，ShardingSphere 提供的分布式解决方案功不可没。该方案适用于各种高流量的互联网平台服务，也适用于电商平台以及其他以数据处理为主的系统。
- 性能提升，响应速度提升 20% 以上；
- 可用性增强，ShardingSphere+MySQL 的方案实现 RTO
- 易于维护，业务逻辑和数据库可维护性显著提升
[En]
easy to maintain, business logic and database maintainability are significantly improved*
- 无缝迁移，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/
Original: https://www.cnblogs.com/sphereex/p/16371022.html
Author: SphereEx
Title: ShardingSphere 异构迁移最佳实践：将3.5亿量级的顾客系统 RTO 减少60倍
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/505292/
转载文章受原作者版权保护。转载请注明原作者出处！