共计 4806 个字符，预计需要花费 13 分钟才能阅读完成。
京东白条的疾速倒退满足了以后人们日益增长的生产需要。在京东商城上用京东白条来领取，曾经成为一大批用户的生产习惯，更是在某种意义上成为了京东对外的『标签』。而作为一家互联网金融生产平台，京东白条的后盾技术团队更是不容忽视的存在。而其也正是撑持京东白条自 2014 年初上线伊始，至今服务数亿用户的最终本源所在。正是京东白条技术团队多年的致力，才造就了以后京东白条的『土生土长』，但具备京东白条特色的金融级数据库选型方法论。
当京东白条的金融类业务启动时，现任京东白条研发负责人张栋芳，尽管预料到了其数据体量的大幅度增长，却没有想到这种增长将导致数据库选型方面的一系列变动，以及对数据库将来倒退模式的启发。
作为京东科技旗下的杀手级金融生产利用，明天的京东白条曾经成长为服务数亿用户、日均产生巨额流量的宏大金融生态。在业务和数据量飞速增长的同时，京东白条后盾的研发人员，也在缓和的焦头烂额中 ….
这一点，完满符合了京东白条后盾数据架构的成长过程。
1、技术的保质期：从 MySQL 到 NoSQL 再到 DBRep
对于技术人而言，没有永远正确的技术，只有最适宜于当下的技术选型。
京东白条业务诞生之初正是互联网金融与生产行业的高速发展期，经验这些年的倒退，从草根走向业余，从强大走向规模，从扩散走向对立，从芜杂走向标准。京东白条的倒退，正是一步步见证了国内互联网生产金融产业的疾速迭代。
同样，京东白条的技术选型历程，也可作为国内互联网生产金融产业倒退过程的一个缩影。
从技术架构的角度来看，并没有相对的好与不好，须要放在彼时的背景下来看，要思考业务的时效价值、团队的规模和能力、环境基础设施等等方面。只有架构演进的生命周期适时匹配好业务的生命周期，能力施展最好的成果。
2014～2015
Solr + HBase 的计划解决了外围、非核心业务系统对要害数据库的拜访问题，Solr 作为被检索字段的索引，HBase 用作全量的数据存储。
- 通过 Solr 集群分担局部读和写的业务，缓解外围库的压力；
- Solr 扩大体验上欠佳，对业务也存在较大的入侵。
2015～2016
引入 NoSQL 计划，业务数据以月份进行分表存储在 MongoDB 集群中，阶段性满足了结算解决场景中海量数据导入导出的需要。
- 查问热点数据效率高，非结构化的存储形式易于批改表构造；
- 仍然面对着扩大差、对业务入侵强的场面，而且耗内存。
2016～2017
随着业务疾速倒退，数据量冲破百亿大关，此时 MongoDB 面临着容量和性能的双重考验。京东白条大数据平台通过 DBRep 以 MySQL Slave 的模式采集变动信息并存储到音讯核心，最初落盘到 ES 和 HBase 中。
- 该计划具备较强的数据实时性，扩展性良好；
- 基于业务框架的数据分片难以升高代码保护老本。
2、为了让你可能更畅快的剁手，他们先『合成』了本人的后盾架构
网购，贵在手速，但也在于钱包的厚度。京东白条的诞生就是为了解决用户钱包的厚度问题。现在，京东白条也打起了“闪电战”。为了保障用户在生产过程中的体验，后盾数据库的稳定性与规律性，就成为了京东白条技术侧亟待思考和均衡的问题。
为保障业务零碎在数据激增状况下始终能放弃高效运行，京东白条技术团队在设计初期应用了数据分片数据架构，施展极致性能的同时也兼顾代码的可控性，采纳基于利用框架的数据拆分计划实现了数据拆分工作。
其实说来说去，实质上就是一个问题，即随着产品的降级迭代，晚期的解决方案逐步演变为了妨碍明天后退的绊脚石。通过业务框架实现的数据分片计划导致业务代码复杂度减少、保护老本一直攀升，紧耦合的弊病逐步露出，利用每次降级都须要投入较多的精力对分片做相应调整，研发人员难以专一于业务自身。
于是，解耦成了京东白条技术解围的惟一要害。在京东白条而言，次要从以下这四个方面开始解耦：
- 数据架构解耦，升高架构之间的耦合度，确保不会因独自业务线变更而导致多个后端架构的调整；
- 技术架构解耦，简化业务系统升级工作所带来的简单研发流程；
- 业务关系解耦，须要让用户在应用过程中每个动作都不受影响，不另外产生新的学习老本，为零碎提供良好的扩大能力，从容应对“618”和“11.11”等平台大促流动；
- 研发流程解耦，解放后端研发生产力，缩小业务代码的复杂度。
因后盾数据库与业务之间的耦合度过高，为整个业务的倒退埋下了增速放缓的隐患。面对如上诉求，京东白条技术团队经衡量后开始思考应用成熟的分库分表组件来承当这部分工作，让业务系统升级和架构调整不再简单。
但京东白条业务体量微小，是货真价实的金融级高并发、海量数据的业务场景，因而在抉择分库分表组件时应具备以下 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 具备的自动化能力为后续的迁徙扩容工作提供了更多的便当。
配好业务的生命周期，能力施展最好的成果。
价值收益
- 简化降级门路
通过架构解耦，业务系统升级所波及技术栈失去无效缩短，研发团队不再须要关注分表设计，精力全副聚焦于业务自身，降级门路失去大幅度优化；
- 节俭研发力量
引入成熟的 Apache ShardingSphere 无需从新开发分表组件，在简化业务降级门路的根底上节俭了大量研发力量；
- 架构灵便扩大
搭配应用 Scaling 同步迁徙组件从容面对“618”和“11.11”等大型流动，零碎灵便扩容。
4、面对新的不稳固业态，须要绝对稳固的规范来应答
如何了解不稳固，并均衡这种不稳固。
随着数据的重要性日益凸显，以及终端场景畛域的继续细化，业务线『开枝散叶』已是常态，市场上的数据库产品层出不穷。某种意义上，倒退了许多年的京东白条，早已不再是当年的数据体量，其金融生产场景曾经是一个绝对稳固和成熟的场景而言，京东白条依然是一个疾速成长的互联网巨量头部产品，用户和数据体量还远没有达到靠近天花板级别。
这也意味着，随着业务数据量的增长，将来京东白条还须要经验屡次具备『阵痛期』的架构转型。而每一次转型，无疑都是一次冒险，这对于谋求稳固和体验的金融级产品而言，无疑是须要慎重考虑的。
而在现阶段通用的数据架构体系下，整个行业都在经验一种新的不稳固业态。面对这种不稳固的业态，京东白条须要一种绝对稳固的规范和生态，来『反抗』这种不稳固的趋势。基于此，张栋芳提到了 Database Plus 的概念。
2018 年，Apache ShardingSphere 作者张亮就曾提出过 Database Plus 的概念。彼时数据库曾经呈现出碎片化的趋势，企业在后端数据库治理层面，曾经开始产生不小的老本。如果可能在数据库下层从新建设起具备对立治理底层数据的中间层生态，对于企业以及工程师而言，都会极大进步研发与治理的效率。
所以，Sharding-JDBC 在京东外部，正式降级为 ShardingSphere， 寓意打造一个新的生态，并在张亮和社区需要的疏导下，逐渐确立起了 Database Plus 的倒退方向。随同着近日 Apache ShardingSphere 5.0.0 正式版的更新，Database Plus 理念已正式在 Apache ShardingSphere 生态中失去践行。
目前，Apache ShardingSphere 通过可插拔架构，已可能在数据库下层构建起一套全新的数据治理生态，如让传统关系型数据库同时具备程度扩大和数据加密的性能，或在传统关系型数据库的根底上独自打造分布式数据库解决方案等，而无需调整底层数据库架构。
而这种技术，无疑是应答数据库碎片化趋势的最好计划之一。 而对于将来数据库倒退的了解，张栋芳认为，在多样化的数据库下层，构建起对立的数据管理平台，将数据库能力散布在中间层并实现可插拔化，谋求性能与业务诉求的高度匹配，筛去冗余的能力，并可能在须要时进行疾速变动，始终保证数据架构的整洁、专一。
5、事物终归须要回归到它的实质
从市场和用户规模来看，中国有着寰球最宽泛的互联网用户群体，产生着最大的数据体量，诞生了一系列成长最疾速的互联网科技公司 …. 然而与宏大需要所不匹配的是，国内数据服务市场却始终处于同质化竞争之下，没能有颠覆海内数据库巨头的产品呈现。
张栋芳认为，各家厂商专一于各自的利用场景之下，短少一个低头环顾四周的过程。咱们始终在谈新技术，始终在谋求业务的最高效化。但对于一些须要实现“大象起舞”的金融、证券、制作、批发等畛域而言，最新的技术不肯定是最适宜他们的，在现有技术根底上，提供增量能力的中间件，打造适配于当下业务场景的技术体系，而不是颠覆。
“ 事物须要回归它的实质。”对于数据治理形式而言，同样如此。
欢送增加社区经理微信（ss_assistant_1）进入微信交换群，与泛滥 ShardingSphere 爱好者一起交换
