共计 3231 个字符，预计需要花费 9 分钟才能阅读完成。
京东白条应用 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 分片的比照如下：
| 基于自研框架分片 | 基于 ShardingSphere 分片 | |
|---|---|---|
| 性能 | 高 | 高 |
| 代码耦合度 | 高 | 低 |
| 业务入侵水平 | 高 | 低 |
| 降级难度 | 高 | 低 |
| 扩展性 | 个别 | 良好 |
下一阶段工作，解耦。
显然京东白条数据架构将迎来一个新的阶段，解耦的驱动力能够概括如下 3 方面：
- 聚焦精力：将基于架构的数据库拆分，交给分表组件实现，研发精力需聚焦于业务自身；
- 简化降级：解耦技术架构，简化业务系统升级工作的研发流程；
- 布局将来：为零碎提供良好的扩大能力，从容应对“618”和“11. 11”等流动。
京东白条业务体量微小，是货真价实的金融级高并发、海量数据的业务场景，因而分库分表组件应具备以下特点：
- 产品成熟稳固
- 极致性能体现
- 解决海量数据
- 架构灵便扩大
Apache ShardingSphere 解决方案
ShardingSphere-JDBC 是 Apache ShardingSphere 的第一款产品，它定位为 轻量级 Java 框架 ，在 Java 的 JDBC 层提供的额定服务。它应用客户端直连数据库，以 jar 包模式提供服务，无需额定部署和依赖，可了解为 增强版的 JDBC 驱动，齐全兼容 JDBC 和各种 ORM 框架。
ShardingSphere-JDBC 的以下特点可能很好地满足白条业务场景：
- 产品成熟：经数年打磨产品成熟度高，且社区沉闷；
- 性能良好：微内核、轻量化的设计，性能损耗极小；
- 革新量小：反对原生的 MySQL 协定，研发工作量小；
- 扩大灵便：搭配应用迁徙同步组件轻松实现数据扩大。
经外部大量系统性验证之后，Apache ShardingSphere 成为了京东白条数据分片中间件的首选计划，2018 年底正式开始对接。
产品适配
为能全面撑持白条业务、提供更好的业务体验，Apache ShardingSphere 在京东白条业务落地过程中对产品的性能和性能方面进行了更多的反对和晋升，产品再一次经验典型案例的打磨。
- 降级 SQL 引擎
白条的业务逻辑非常复杂且宏大，多样化场景的需要对 SQL 的兼容水平有着较高要求，Apache ShardingSphere 重构了 SQL 解析模块，并反对了更多的 SQL。
1、路由至单数据节点，SQL 100% 兼容；
2、路由至少数据节点，可全面反对 DML、DDL、DCL、TCL 和局部 DAL。反对分页、去重、排序、分组、聚合、关联查问。
- 分布式主键
Apache ShardingSphere 提供了内置的分布式主键生成器，例如 UUID、SNOWFLAKE 等分布式主键生成器。同时 Apache ShardingSphere 提供了分布式主键生成器的接口，用户可自定义自增主键生成算法来满足非凡场景的需要。
- 业务分片键值注入
对于没有分片条件的 SQL，Apache ShardingSphere 应用 ThreadLocal 治理分片键值，通过编程的形式向 HintManager 中增加分片条件，该分片条件仅在以后线程内失效，实现了 SQL 零侵入。
除了对性能上的加强，Apache ShardingSphere 为满足京东白条业务严苛的性能要求，同时做了多方面调优。
- SQL 解析后果缓存
- JDBC 元数据信息缓存
- Bind 表 & 播送表的应用
- 自动化执行引擎 & 流式归并
经两团队通力合作，京东白条业务与 Apache ShardingSphere 相结合的各项指标满足预期，性能与原生 JDBC 简直统一。
对于对接过程中的问题详情及计划，请通过《Apache ShardingSphere 对接京东白条实战》一文来理解。
业务割接
Apache ShardingSphere 应用定制化 HASH 策略对数据进行分片，无效防止了热点数据问题，拆分后的数据节点数达近万个，整个割接过程大概继续了 4 周左右的工夫。
- DBRep 读取数据，通过 Apache ShardingSphere 将数据同步至指标数据库集群；
- 两套集群并行运行，数据迁徙后再应用自研工具对业务和数据进行校验。
DBRep 是 ShardingSphere-Scaling 产品设计的基石，Scaling 具备的自动化能力为后续的迁徙扩容工作提供了更多的便当。
Apache ShardingSphere 带来的收益
- 简化降级门路
通过架构解耦，业务系统升级所波及技术栈失去无效缩短，研发团队不再须要关注分表设计，精力全副聚焦于业务自身，降级门路失去大幅度优化；
- 节俭研发力量
引入成熟的 Apache ShardingSphere 无需从新开发分表组件，在简化业务降级门路的根底上节俭了大量研发力量；
- 架构灵便扩大
搭配应用 Scaling 同步迁徙组件从容面对“618”和“11.11”等大型流动，零碎灵便扩容。
写在最初
京东白条业务的快速增长驱动着数据架构一直降级，本次架构演进通过引入 Apache ShardingSphere 助力白条架构解耦，简化了系统升级门路，使研发团队只需关注业务自身，同时也实现了数据架构的灵便扩大，在生产金融场景开启了良好的开始。
互联网信用生产模式倒退逐渐多样化，将来 Apache ShardingSphere 将与京东开展更多业务场景的实际和摸索，通过推动金融科技翻新倒退，进一步晋升互联网金融的翻新速度和效率。
ShardingSphere 作为 Apache 基金会下的顶级开源我的项目，在 GitHub 上取得了超 14K Star 的关注，已成为行业内受欢迎的开源我的项目，寰球有超过 170 家企业用户注销应用，笼罩金融、电子商务、云服务、游览、物流、教育、娱乐等多个畛域。
- 欢送更多技术团队约稿投稿，和大家分享应用 ShardingSphere 的教训思考。对案例感兴趣的搭档可分割社区经理（ss_assistant_1）或扫描下方二维码回复“加群”进入技术交换群。
退出交换群
