阿帕奇的ShardingSphere 帮助 当当网 重建其拥有3.5亿用户的客户系统，并无缝地从 淘宝网+SQL服务器 技术堆栈无缝过渡到Java+ShardingSphere+堆栈。淘宝网 堆栈。其客户系统的性能、可用性和可维护性都得到了显著提升，这也是ShardingSphere异构迁移的最佳实践。
当当网的客户系统
当当网的客户系统主要负责账户注册、登录和隐私数据维护。其之前的技术栈是基于PHP和SQL Server的，也就是标准的集中式架构，如下图所示。
在重建项目开始之前，客户系统的几个业务模块遇到了多种问题和技术挑战，如逻辑分散、吞吐量低、运维成本高等。
为了改善客户的购物体验，当当网的技术团队决定优化业务逻辑和底层数据架构，以实现客户系统在多个场景下的可用性、可扩展性和全面提升。此次重建还引入了许多技术创新，如跨数据源双写、读写分离、智能网关、灰色发布等。
当当的技术团队在半年内完成了系统重建，从需求设计、分片规划、逻辑优化、压力测试到正式上线。
该项目使用Java重构了十多个模块，通过ShardingSphere & MySQL构建分布式数据库解决方案，并最终完成了异构数据库的在线迁移。该项目拥有以下亮点。
- 用Java语言重构PHP业务代码。
- 用ShardingSphere & MySQL取代SQL Server。
- 完成3.5亿用户的在线数据迁移。
- 通过数据双写方案完成无缝启动。
痛点与挑战
业务痛点
在业务层面，客户系统的一些模块的注册和登录逻辑分散在不同的末端。这导致了高昂的维护成本，而且旧的技术架构在性能提升和高可用性方面受到限制。
- 维护困难：多个平台的注册和登录逻辑分散，业务维护复杂。
- 性能有限：PHP & SQL Server这种集中式技术架构的吞吐量不足。
- 可用性和安全性差。如** 果SQL Server的活动/备用状态发生变化，订阅数据库就会失效，重新配置需要一个时间窗口。由于病毒的存在，运行在Windows服务器上的SQL服务器的安全性很差，在安装了补丁之后，升级需要很长的时间（大于30分钟）。
面临的挑战
- 数据完整性： 客户系统涉及超过3.5亿用户的数据。从SQL Server迁移到MySQL后，有必要确保数据的一致性和完整性。
- API透明度： API对调用者是透明的，以确保调用者不发生变化，并尽量减少接口的变化。
- 无缝切换： 业务系统必须无缝切换，不影响业务。
- 时间紧迫： 系统在 "618（又名JD.com Day）和11.11（又名Singles Day）"（中国的两个网络购物节）前后都会被屏蔽，所以我们需要在有限的时间窗口内将其在两个购物促销活动中切换，然后接受测试，为11.11购物节做准备。
解决方案
整体规划
为了提高客户系统的可维护性、可用性和性能，研发团队重新组织了客户系统的架构。
在应用层，目标是统一所有终端的功能逻辑，提高业务可维护性。
在数据库层，将集中式架构转变为分布式数据库架构，以提高性能和可用性，这正是ShardingSphere & MySQL构建的开源分布式解决方案。
- 应用层。随着当当网整体技术栈的改变，其业务开发语言也从PHP变为Java。
- 中间件。作为成熟的开源数据库中间件，ShardingSphere被用来实现数据分片。
- 数据库。使用了多个MySQL集群来替代SQL Server数据库。
整体架构设计引入了多种方案，如分布式主密钥生成策略、分片管理、数据迁移验证、灰色发布等。
分布式主键生成策略
如果数据库架构要从集中式架构转变为基于中间件的分布式架构，分布式主键生成策略是首先要解决的问题。
在系统重建过程中，我们选择建立两个或多个数据库ID生成服务器。每个服务器都有一个序列表，记录每个表的当前ID。在Sequence表中增加的ID的步长是服务器的数量。起始值是交错的，这样ID的生成就被散列到每个服务器节点。
实施分片(Apache ShardingSphere)
在客户系统重建过程中，通过Apache ShardingSphere完成了数据库分片，同时启用了读/写分片功能。
由于客户系统对高并发、低延迟的要求，访问端选择了ShardingSphere-JDBC，它被定位为轻量级的Java框架，在Java的JDBC层提供额外的服务。
它通过客户端直接连接到数据库，以jar包的形式提供服务，不需要额外的部署和依赖。它可以被看作是JDBC驱动的一个增强版，与JDBC和各种ORM框架完全兼容。
- 分散管理。 ShardingSphere支持一套完整的分片算法，包括模数操作、散列、范围、时间和自定义算法。客户使用modulo分片算法来分割大表。
- 读写拆分： 除Sharding外，还启用ShardingSphere的读/写拆分功能，充分利用MHA集群资源，提高系统吞吐能力。
双重写&数据同步
数据同步贯穿整个重建项目，数据迁移的完整性和一致性对重建工作至关重要。
这个例子基于Elastic-Job同步，定期将SQL Server的历史数据同步到MySQL。在数据库切换过程中，采用备份方案对数据库进行二次写入，以保证数据的一致性。这个过程包括。
第一步：实现双写机制
断开链路1，打通链路2、3、4，然后是9、10。
第2步：切换登录服务
断开链接9,10，打通链接7，然后断开链接5。
第3步：切换读取服务
打通链路8，断开链路6。
第4步：取消双写机制
断开链路2，完成切换。
数据验证在服务端和数据库端都是定期进行的。在不同的时间段采用不同的频率来抽查或全面检查数据的完整性。COUNT/SUM也在数据库侧进行验证。
客户系统重建采用了基于apollo的灰色发布。在新的登录处理过程中，逐步释放配置项，并在小范围内实施顺序切换，以保证启动成功率。重建后的系统架构如下图所示。
优点
重建后，当当网客户系统的响应速度明显提高，日常运维成本也随之降低。
ShardingSphere提供的分布式解决方案在其中发挥了很大作用。该方案适用于各种高流量的互联网平台服务，也适用于电子商务平台和其他数据处理系统。
- 性能提高：响应速度提高20%以上。
- 高可用性：由于ShardingSphere & MySQL的设计，RTO减少到30s以下。
- 易于维护：业务逻辑和数据库的可维护性得到明显改善。
- 无缝迁移：6个月内完成每个模块的在线切换，窗口时间为零。
总结
这是当当网对ShardingSphere的第二次实施，此前我们在""一文中分享过。亚洲电子商务巨头当当网将订单处理速度提高了30%--利用Apache ShardingSphere节省了超过1000万的技术预算".
Apache ShardingSphere为企业系统提供了强有力的支持，因为该项目追求简单和完美，以实现更简单的业务逻辑和最大的性能。
