Apache ShardingSphere 在京东白条场景的落地之旅

京东白条使用 Apache ShardingSphere 解决了千亿数据存储和扩容的问题，为大促活动奠定了基础。

2014 年初，“京东白条”作为业内互联网信用支付产品，数据量爆发式的增长，每一次大促备战都是对技术人员的考验，每一次的战略转型驱动着数据架构的成长。

–张栋芳，京东白条研发负责人

京东白条数据架构演进史

自 2014 年 2 月京东白条业务上线起，为满足快速发展的业务和激增的海量数据，白条的数据架构经历了数次演进。

· 2014～2015

Solr + HBase 的方案解决了核心、非核心业务系统对关键数据库的访问问题，Solr 作为被检索字段的索引，HBase 用作全量的数据存储。

· 通过 Solr 集群分担部分读和写的业务，缓解核心库的压力；

· Solr 扩展体验上欠佳，对业务也存在较大的入侵。

· 2015～2016

引入 NoSQL 方案，业务数据以月份进行分表存储在 MongoDB 集群中，阶段性满足了结算处理场景中海量数据导入导出的需求。

· 查询热点数据效率高，非结构化的存储方式易于修改表结构；

· 依然面对着扩展差、对业务入侵强的局面，而且耗内存。

· 2016～2017

随着业务快速发展，数据量突破百亿大关，此时 MongoDB 面临着容量和性能的双重考验。京东白条大数据平台通过 DBRep 以 MySQL Slave 的形式采集变动信息并存储到消息中心，最后落盘到 ES 和 HBase 中。

· 该方案具有较强的数据实时性，扩展性良好；

· 基于业务框架的数据分片难以降低代码维护成本。

白条数据架构的演进间接地反应了互联网消费金融的飞速发展，也说明了每一种解决方案在不同背景下都有不同的保质期。

迫在眉睫的架构解耦

为保证业务系统在数据激增情况下始终能保持高效运行，技术团队在设计初期使用了数据分片数据架构，发挥极致性能的同时也兼顾代码的可控性，采用基于应用框架的数据拆分方案完成了数据拆分工作。

但随着产品升级迭代，早期的解决方案演变成为了眼前的问题，通过业务框架实现的数据分片方案导致业务代码复杂度增加、维护成本不断攀升，紧耦合的弊端原形毕露，应用每次升级都需要投入较多的精力对分片做相应调整，研发人员难以专注于业务本身。

面对如上问题，技术团队经权衡后开始考虑使用成熟的分库分表组件来承担这部分工作，让业务系统升级和架构调整不再复杂。基于自研框架分片和基于 ShardingSphere 分片的对比如下：

Apache ShardingSphere 在京东白条场景的落地之旅

下一阶段工作，解耦。

显然京东白条数据架构将迎来一个新的阶段，解耦的驱动力可以概括如下 3 方面：

· 聚焦精力：将基于架构的数据库拆分，交给分表组件实现，研发精力需聚焦于业务本身；

· 简化升级：解耦技术架构，简化业务系统升级工作的研发流程；

· 规划未来：为系统提供良好的扩展能力，从容应对“618”和“11. 11”等活动。

京东白条业务体量巨大，是名副其实的金融级高并发、海量数据的业务场景，因此分库分表组件应具有以下特点：

1. 产品成熟稳定

2. 极致性能表现

3. 处理海量数据

4. 架构灵活扩展

Apache ShardingSphere 解决方案

ShardingSphere-JDBC 是 Apache ShardingSphere 的第一款产品，它定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

ShardingSphere-JDBC 的以下特点能够很好地满足白条业务场景：

· 产品成熟：经数年打磨产品成熟度高，且社区活跃；

· 性能良好：微内核、轻量化的设计，性能损耗极小；

· 改造量小：支持原生的 MySQL 协议，研发工作量小；

· 扩展灵活：搭配使用迁移同步组件轻松实现数据扩展。

Apache ShardingSphere 在京东白条场景的落地之旅