因后台数据库与业务之间的耦合度过高，为整个业务的发展埋下了增速放缓的隐患。面对如上诉求，京东白条技术团队经权衡后开始考虑使用成熟的分库分表组件来承担这部分工作，让业务系统升级和架构调整不再复杂。 但京东白条业务体量巨大，是名副其实的金融级高并发、海量数据的业务场景，因此在选择分库分表组件时应具备以下 4 个特点：
产品成熟稳定。只有成熟且稳定维护的产品，才能够给京东白条这样一款体量的金融产品予以稳定性的保证。使用数据分片来进行架构解耦，本身就是为了确保稳定性；
极致性能表现。金融场景下的应用，对于数据响应、实时反馈等性能的要求非常高。尤其在交易这种敏感且特殊的场景下，对于性能的表现，一点也不能马虎；
处理海量数据。京东白条需要处理海量的用户数据，尤其在“618”、“11.11”等大促节日下，面对蜂拥而至海量交易数据与请求，要能够在短时间内快速处理；
架构灵活扩展。业务灵活多变是当前互联网产品的共性。
对此，京东白条从多个方面考虑自研框架与成熟分库分表中间件 ShardingSphere 优劣性，性能对比图如下：
基于自研框架分片 基于 ShardingSphere 分片性能 高 高
代码耦合度 高 低
业务入侵程度 高 低
升级难度 高 低
扩展性 一般 良好
最终，京东白条选择采用 Apache ShardingSphere 来进行金融级别的数据库分片任务。
3、场景趋于融合，但数据库却无法相容：Apache ShardingSphere 解决方案京东白条采用 Apache ShardingSphere-JDBC 解决方案处理在线应用。ShardingSphere-JDBC 是 Apache ShardingSphere 的第一款产品，它定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
ShardingSphere-JDBC 的以下特点能够很好地满足白条业务场景：
产品成熟：经数年打磨产品成熟度高，且社区活跃；
性能良好：微内核、轻量化的设计，性能损耗极小；
改造量小：支持原生的 JDBC 接口，研发工作量小；
扩展灵活：搭配使用迁移同步组件轻松实现数据扩展。
经内部大量系统性验证之后，Apache ShardingSphere 成为了京东白条数据分片中间件的首选方案，2018 年底正式开始对接。
产品适配为全面支撑白条业务、提供更好的业务体验，Apache ShardingSphere 在京东白条业务落地过程中对产品的功能和性能方面进行了更多的支持和提升，产品再一次经历典型案例的打磨。
升级 SQL 引擎
白条的业务逻辑非常复杂且庞大，多样化场景的需求对 SQL 的兼容程度有着较高要求，Apache ShardingSphere 重构了 SQL 解析模块，并支持了更多的 SQL。经两团队通力合作，京东白条业务与 Apache ShardingSphere 相结合的各项指标满足预期，性能与原生 JDBC 几乎一致。
关于对接过程中的问题详情及方案，请通过《Apache ShardingSphere 对接京东白条实战》一文来了解。
业务割接Apache ShardingSphere 使用定制化 HASH 策略对数据进行分片，有效避免了热点数据问题，拆分后的数据节点数达近万个，整个割接过程大约持续了 4 周左右的时间。
DBRep 读取数据，通过 Apache ShardingSphere 将数据同步至目标数据库集群；
两套集群并行运行，数据迁移后再使用自研工具对业务和数据进行校验。
DBRep 是 ShardingSphere-Scaling 产品设计的基石，Scaling 具备的自动化能力为后续的迁移扩容工作提供了更多的便利。
配好业务的生命周期，才能发挥最好的效果。
价值收益简化升级路径