京东白条的快速发展满足了当下人们日益增长的消费需求。在京东商城使用京东借条支付已经成为大量用户的消费习惯，某种意义上也成为了京东的“标签”。作为互联网金融消费平台，京东白条的后台技术团队不容忽视。而这也是京东白条自2014年初上线以来服务亿万用户的最终支撑源泉。正是京东白条技术团队多年的辛勤耕耘，才造就了如今京东白条的“土生土长”》具有京东白条特色的金融级数据库选型方法论。京东白条金融业务上线时，虽然京东白条现任研发负责人张东方预计其数据量会大幅增加，但没想到这种增长会导致数据库发生一系列变化选择，以及对数据库的影响。对未来发展模式的启发。作为京东科技旗下的一款杀手级金融消费应用，如今的京东白条已经成长为一个服务亿万用户、每天产生巨大流量的庞大金融生态。在业务和数据量快速增长的同时，京东白条后台的研发人员也处于压力状态。这一点非常符合京东白条后台数据结构的成长过程。1、技术保质期：从MySQL到NoSQL再到DBRep对于技术人员来说，没有永远正确的技术，只有当下最适合的技术选择。京东白条业务起步于互联网金融和消费行业快速发展时期。经过多年的发展，从草根到专业，从小到大，从分散到统一，从混乱到规范。京东白条的发展见证了国内互联网消费金融行业一步步快速迭代。同样，京东白条的技术选型过程也可以作为国内互联网消费金融行业发展历程的一个缩影。从技术架构来看，没有绝对的好坏。需要放在当时的背景下看待，必须考虑业务的时效性价值、团队的规模和能力，以及环境基础设施。只有架构演进的生命周期及时匹配业务的生命周期，才能达到最好的效果。2014-2015年，Solr+HBase解决方案解决了核心和非核心业务系统访问关键数据库的问题。Solr作为检索字段的索引，HBase作为全量数据存储。部分读写业务通过Solr集群共享，缓解核心库压力；Solr扩展体验不好，对业务有较大的侵扰。2015-2016年，引入NoSQL方案，业务数据按月分表存储在MongoDB集群中，分阶段满足结算处理场景海量数据导入导出的需求。查询热点数据效率高，非结构化存储方式容易修改表结构；仍然面临扩展性差、业务入侵性强、内存消耗大的局面。2016-2017年，随着业务的快速发展，数据量突破百亿大关。此时，MongoDB面临着容量和性能的双重考验。京东白条大数据平台通过DBRep将变更信息以MySQLSlave的形式采集并存储在消息中心，最后放入ES和HBase中。该方案数据实时性强，可扩展性好；基于业务框架的数据分片难以降低代码维护成本。2、为了让您购物更愉快，他们首先“分解”了自己的网购后台架构。手速固然重要，但也在于钱包的厚薄。京东白条就是为了解决用户钱包厚度的问题而诞生的。如今，京东白条也发起了一场“闪电战”。为了保证用户在消费过程中的体验，后台数据库的稳定性和规律性成为京东白条技术方需要考虑和权衡的问题。为了保证业务系统在数据激增的情况下始终保持高效运行，京东白条的技术团队在设计初期就采用了数据分片数据架构，在充分发挥极致性能的同时，也兼顾了数据的可控性。代码。子计划完成数据拆分工作。其实本质上是一个问题，就是随着产品的升级迭代，早期的解决方案逐渐演变成阻碍今天进步的绊脚石。通过业务框架实现的数据分片方案导致业务代码复杂度增加，维护成本上升。紧耦合的弊端逐渐显露出来。每次应用升级，都需要投入更多的精力去相应调整sharding，研发人员很难专注于业务本身。因此，脱钩成为京东白条技术突破的唯一关键。就京东白条而言，解耦主要从以下四个方面着手：数据架构的解耦，降低架构之间的耦合度，保证多个后端架构不会因为个别业务线的变化而调整；技术架构解耦，简化业务系统升级带来的复杂研发流程；业务关系解耦要求用户在使用过程中的每一个动作都不会受到影响，也不会产生额外的学习成本，为系统提供了良好的扩展能力，能够从容应对“618”、“11.11”等平台促销；研发流程的解耦，解放了后端研发的生产力，降低了业务代码的复杂度。由于后端数据库与业务的耦合度高，存在整个业务发展放缓的隐患。面对这样的需求，京东白条的技术团队权衡后开始考虑使用成熟的分库分表组件来承担这部分工作，让业务系统升级和架构调整不再繁琐。但京东白条业务量巨大，是名副其实的高并发、海量数据的金融级业务场景。因此，在选择分库分表组件时，应具备以下四个特点：产品成熟稳定。像京东白条这样的金融产品，只有成熟稳定维护的产品才能保证稳定性。使用数据分片进行架构解耦是为了保证稳定性和极致性能。金融场景下的应用对数据响应、实时反馈等性能要求非常高。尤其是在交易等敏感、特殊的场景下，性能上绝对不能马虎；海量数据处理。京东白条需要处理大量的用户数据，尤其是在“618”、“11.11”等重大促销节日期间。面对海量交易数据和请求的涌入，必须能够在短时间内快速处理；结构可灵活扩展。业务灵活性是当前互联网产品的共同特点。对此，京东白条从多方面考虑了自研框架和成熟的分片中间件ShardingSphere的优缺点。性能对比图如下：基于自研框架的Sharding基于ShardingSphere的Sharding性能代码耦合度高，业务侵入性低升级难度高或低可扩展性高或低总体不错最终京东白条选择了ApacheShardingSphere用于金融级分库任务。3、场景趋同，数据库不兼容：ApacheShardingSphere方案京东白条采用ApacheShardingSphere-JDBC方案处理在线应用。ShardingSphere-JDBC是ApacheShardingSphere的第一款产品，定位为轻量级Java框架，在JavaJDBC层提供附加服务。它使用客户端直接连接数据库，以jar包的形式提供服务，无需额外部署和依赖。可以理解为JDBC驱动的增强版，完全兼容JDBC和各种ORM框架。ShardingSphere-JDBC的以下特点可以很好的满足白条的业务场景：成熟的产品：经过几年的打磨，产品高度成熟，社区活跃；性能好：微内核，轻量化设计，性能损失最小；改造量小：支持原生JDBC接口，研发工作量小；灵活扩展：使用迁移同步组件轻松实现数据扩展。imgApacheShardingSphere经过大量内部和系统验证，成为京东白条数据分片中间件的首选方案，并于2018年底正式开始对接。产品适配为了全面支持白条业务，提供更好的业务体验，ApacheShardingSphere在京东白条业务落地过程中，对产品的功能和性能进行了更多的支持和改进。产品又一次经历了典型案例的打磨。升级SQL引擎的业务逻辑非常复杂庞大，各种场景的需求对SQL的兼容性有很高的要求。ApacheShardingSphere重构了SQL解析模块，支持更多的SQL。通过两个团队的共同努力，京东白条业务与ApacheShardingSphere的结合各项指标达到预期，性能与原生JDBC相差无几。img对接过程中出现的问题及解决方法详见文章《Apache ShardingSphere 对接京东白条实战》。业务切入ApacheShardingSphere采用定制的HASH策略对数据进行分片，有效避免热点数据问题。拆分后数据节点数达到近万个。整个割接过程持续了大约4周。DBRep读取数据，通过ApacheShardingSphere将数据同步到目标数据库集群；两套集群并行运行，数据迁移后，使用自研工具验证业务和数据。DBRep是ShardingSphere-Scaling产品设计的基石，Scaling的自动化能力为后续的迁移扩容工作提供了更多便利。只有正确匹配业务的生命周期，才能达到最好的效果。价值收益简化升级路径通过架构的解耦，有效缩短业务系统升级涉及的技术栈，研发团队不再需要关注分表设计，所有精力都放在业务上自身，升级路径大幅优化；节省研发力量，引入成熟的ApacheShardingSphere，无需重新开发分表组件，在简化业务升级路径的基础上，节省了大量的研发工作；架构灵活扩展，使用Scaling同步迁移组件，从容应对“618”、“11.11”等大规模事件，系统可灵活扩展。4、面对新的不稳定的业态，需要相对稳定的标准来应对，如何认识不稳定，平衡这种不稳定。随着数据重要性的提升和终端场景的不断细化，业务线“分枝撒叶”成为常态，市场上数据库产品层出不穷。从某种意义上说，发展多年的京东白条已经不是当年的数据量了。它的金融消费场景已经是一个比较稳定和成熟的场景。京东白条仍然是一个快速增长的巨大互联网头部产品，用户和数据量都远未达到天花板的水平。这也意味着，随着业务数据量的增长，京东白条未来需要经历多次架构转型，并伴有“阵痛期”。而每一次转型，无疑都是一次冒险，对于追求稳定和体验的金融级产品来说，无疑需要深思熟虑。在目前通用的数据架构体系下，整个行业正在经历一种新的不稳定的商业模式。面对这种不稳定的商业模式，京东白条需要一个相对稳定的标准和生态来“对抗”这种不稳定的趋势。基于此，张东方提到了DatabasePlus的概念。2018年，ApacheShardingSphere作者张亮提出了DatabasePlus的概念。当时数据库已经呈现出碎片化的趋势，企业在后台数据库管理层面已经开始产生可观的成本。如果能够在数据库上层重建底层数据统一管理的中间层生态，将大大提高企业和工程师的研发和管理效率。于是，Sharding-JDBC在京东内部正式升级为ShardingSphere，寓意着新生态的建立，在张良的引导下和社区的需求下，逐渐确立了DatabasePlus的发展方向。随着近期ApacheShardingSphere5.0.0正式版的更新，DatabasePlus的概念在ApacheShardingSphere生态系统中正式落地。目前ApacheShardingSphere已经能够通过可插拔的架构在数据库上层构建全新的数据治理生态，比如让传统关系型数据库同时具备水平扩展和数据加密功能，或者在传统关系型数据库的基础上数据库。创建分布式数据库解决方案，更加独立，无需调整底层数据库架构。而这项技术无疑是应对数据库碎片化趋势的最佳解决方案之一。对于未来数据库发展的理解，张东方认为，应该在多元化的数据库上层搭建统一的数据管理平台，数据库能力在中间层分布式和可插拔，追求与数据库之间的高度匹配。将实现功能和业务需求。去除冗余并在需要时进行快速更改的能力，始终确保数据结构的清洁性和特异性。5、事物要回归本质毕竟从市场和用户规模来看，中国拥有世界上最广泛的互联网用户群体，产生的数据量最大，诞生了一系列发展最快的互联网技术企业……然而，与庞大需求不匹配的是，国内数据服务市场始终处于同质化竞争状态，并没有颠覆海外数据库巨头的产品。张东方认为，每个厂商都专注于自己的应用场景，缺乏一个向上看、东张西望的过程。我们一直在谈论新技术，始终追求最高效的业务。然而，对于一些需要实现“跳舞的大象”的金融、证券、制造、零售等领域来说，最新的技术可能并不是最适合他们的。在现有技术的基础上，提供具有增量能力的中间件，可以创建一个适应当前业务场景的技术体系，而不是颠覆它。“事物需要回归本质。”数据治理方法也是如此。我今天是来和大家分享的。谢谢你们。
