京东白条的快速发展满足了当前人们日益增长的消费需求。在京东商城上用京东白条来支付，已经成为一大批用户的消费习惯，更是在某种意义上成为了京东对外的『标签』。而作为一家互联网金融消费平台，京东白条的后台技术团队更是不容忽视的存在。而其也正是支撑京东白条自 2014 年初上线伊始，至今服务数亿用户的最终根源所在。正是京东白条技术团队多年的努力，才造就了当前京东白条的『土生土长』，但具有京东白条特色的金融级数据库选型方法论。
当京东白条的金融类业务启动时，现任京东白条研发负责人张栋芳，虽然预料到了其数据体量的大幅度增长，却没有想到这种增长将导致数据库选型方面的一系列变化，以及对数据库未来发展模式的启发。
作为京东科技旗下的杀手级金融消费应用，今天的京东白条已经成长为服务数亿用户、日均产生巨额流量的庞大金融生态。在业务和数据量飞速增长的同时，京东白条后台的研发人员，也在紧张的焦头烂额中....
这一点，完美契合了京东白条后台数据架构的成长过程。
1、技术的保质期：从 MySQL 到 NoSQL 再到 DBRep对于技术人而言，没有永远正确的技术，只有最适合于当下的技术选型。
京东白条业务诞生之初正是互联网金融与消费行业的高速发展期，经历这些年的发展，从草根走向专业，从弱小走向规模，从分散走向统一，从杂乱走向规范。京东白条的发展，正是一步步见证了国内互联网消费金融产业的快速迭代。
同样，京东白条的技术选型历程，也可作为国内互联网消费金融产业发展过程的一个缩影。
从技术架构的角度来看，并没有绝对的好与不好，需要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。只有架构演进的生命周期适时匹配好业务的生命周期，才能发挥最好的效果。
2014～2015Solr + HBase 的方案解决了核心、非核心业务系统对关键数据库的访问问题，Solr 作为被检索字段的索引，HBase 用作全量的数据存储。
通过 Solr 集群分担部分读和写的业务，缓解核心库的压力；
Solr 扩展体验上欠佳，对业务也存在较大的入侵。
2015～2016引入 NoSQL 方案，业务数据以月份进行分表存储在 MongoDB 集群中，阶段性满足了结算处理场景中海量数据导入导出的需求。
查询热点数据效率高，非结构化的存储方式易于修改表结构；
依然面对着扩展差、对业务入侵强的局面，而且耗内存。
2016～2017随着业务快速发展，数据量突破百亿大关，此时 MongoDB 面临着容量和性能的双重考验。京东白条大数据平台通过 DBRep 以 MySQL Slave 的形式采集变动信息并存储到消息中心，最后落盘到 ES 和 HBase 中。
该方案具有较强的数据实时性，扩展性良好；
基于业务框架的数据分片难以降低代码维护成本。
2、为了让你能够更痛快的剁手，他们先『分解』了自己的后台架构网购，贵在手速，但也在于钱包的厚度。京东白条的诞生就是为了解决用户钱包的厚度问题。如今，京东白条也打起了“闪电战”。为了保证用户在消费过程中的体验，后台数据库的稳定性与规律性，就成为了京东白条技术侧亟待考虑和平衡的问题。
为保证业务系统在数据激增情况下始终能保持高效运行，京东白条技术团队在设计初期使用了数据分片数据架构，发挥极致性能的同时也兼顾代码的可控性，采用基于应用框架的数据拆分方案完成了数据拆分工作。
其实说来说去，本质上就是一个问题，即随着产品的升级迭代，早期的解决方案逐渐演变为了阻碍今天前进的绊脚石。通过业务框架实现的数据分片方案导致业务代码复杂度增加、维护成本不断攀升，紧耦合的弊端逐渐显露，应用每次升级都需要投入较多的精力对分片做相应调整，研发人员难以专注于业务本身。
于是，解耦成了京东白条技术突围的唯一关键。在京东白条而言，主要从以下这四个方面开始解耦：
数据架构解耦，降低架构之间的耦合度，确保不会因单独业务线变更而导致多个后端架构的调整；
技术架构解耦，简化业务系统升级工作所带来的复杂研发流程；
业务关系解耦，需要让用户在使用过程中每个动作都不受影响，不另外产生新的学习成本，为系统提供良好的扩展能力，从容应对“618”和“11.11”等平台大促活动；
研发流程解耦，解放后端研发生产力，减少业务代码的复杂度。