不要告诉别人（#618复盘系列# | 解密白条交易架构实践）

题图为消费者金融研发部的小伙伴们。

【摘要】白条业务每年200%+的增长速度对交易系统并发量、稳定性、扩展性以及容灾能力都是特别大的挑战。以今年京东“618”期间为例：计息系统调用量每分钟数百万；白条入口级展示调用量每分钟上千万；预热系统每分钟调用量上千万；营销规则匹配每分钟数亿次；高达99.99%的支付成功率……本文将从三方面简要阐述我们是如何优化白条交易架构，使其经受住了618的考验。

一、如何保证服务的持续可用

对于交易系统而言，支付服务的持续可用是系统设计需要考虑的重中之重。

以“618”为例，哪怕一分钟的服务故障，损失的不仅是巨额的交易收入，更重要的是用户的体验和对产品的态度。

图1：白条交易对服务持续可用的实践

1. 业务层、数据访问层，异地多活，多机房部署，基于JSF发布服务，通过全局负载均衡，动态分配流量。当某台机器或者某个机房发生故障时，可通过管理平台实时下线故障服务，保证支付请求的正常交付。
2. 数据库作为整个交易链路强依赖的部分，数据落地的介质，不容有失。白条通过DB+（mysql+nosql+分布式）同城双活的方式实现灾备。

白条核心数据库依赖金融自研的mysql集群，如图1所示，数据库集群A包含24个数据库，数据散列分布其中，而集群A、B同属生产级的机房，数据实时同步，当集群A发生故障时，可自动切换到灾备数据库集群B，保证数据正常落地，服务正常交付。

另外，热点数据的CRUD操作，都会通过消息的方式同步到nosql数据库，对于“618” “双十一”等特殊时期，查询量骤增，此时对于关系型数据库而言，性能的消耗主要源于查询，为了减小mysql的性能消耗，适情况将高并发的热点数据查询切到nosql，进而保证mysql集群性能。

二、单体服务的故障策略及性能优化

单体服务故障策略

随着白条业务的发展，业务线的增多，为了避免业务杂乱互相影响以及方便部署、独立扩容，每条业务线都被拆成了独立的单体服务。但是每个单体服务都存在多个不确定的故障条件，如何确保服务的正确交付是我们面临的问题。

图2： 单体服务故障条件

如图2所示，服务的每一环节都可能会出现故障，那如何保证稳定、正确的响应呢？这就需要我们对每一个故障准备正确的应对策略：

• 并发请求：并发控制。常见并发主要有：访问并发、库并发。访问并发可通过配置niginx防刷、优化性能提高服务器吞吐量、扩容机器全局负载分配流量。库并发很少用数据库事务隔离级别处理，大多时候通过库字段乐观锁防止并发
• 重复请求：幂等控制。异步化、woker等重试请求通过时间幂等控制重复请求
• 超量请求：配额控制。根据来源配置限额，防止超量请求
• 请求积压：请求丢弃。积压请求合理重试，超时未处理归档丢弃，防止不断重试对下游系统压力
• 处理超时：时间控制。合理设置超时时间，防止单一接口占用所以线程资源，影响整体性能，更甚造成雪崩
• 处理中断：事务保障。数据库事务+异步消息机制保证最终事务一致性
• 通信故障：合理重试。

单体服务优化

• 白条依赖服务简介

众所周知，白条是一款信贷产品。业绩的增长并不仅仅是交易额越来越高，还包括对风险识别控制、降低乃至零损失。所以每一笔白条交易需要经过账户、计息、营销、天盾、白条交易风控规则等多个复杂的计算过程过滤，任何一个步骤都可能会影响整体的支付体验，只有尽可能优化每一个单体服务的响应时间，才能满足整体的性能要求。

图3： 白条交易依赖核心接口tp99

如图3所示，白条交易链路依赖接口都在毫秒级，每一个接口都是根据各自的业务特点，多纬度优化的结果，主要包括：多线程并行计算、存储结构优化、缩短主链路，异步消峰、代码review等。

• 预热系统应用案例

除却以上大家熟知的优化方案外，还有一系统起到至关重要的作用，就是白条的预热系统。下面以白条交易风控规则为例，来看预热系统在实际场景中的应用：

背景

除了通过天盾的保障外，白条业务系统也有一套独立的对风险的控制规则。每一次试算、支付请求都要从多纬度计算风险，例如订单各种属性、用户日月季年限额限次、以及各种黑白名单等等。

最开始，交易规则的判断依赖商城订单查询接口，从商城订单中心取订单信息，再从业务系统取账户、规则等信息，所有步骤都是实时同步进行的。

这种计算方式，强依赖商城订单查询服务，其抖动、限流等都可能会影响白条支付成功率。而随着风控规则越来越多，实时计算也已经越来越不能满足我们对性能要求。针对上述问题做了如下优化：

• 用户下单瞬间，预热系统收集订单、用户、渠道等信息，预热需要的属性
• Woker定时更新交易风控规则到服务器内存，保证数据一致
• 白条交易风控规则CRUD操作，通过消息更新内存数据
• 支付、试算请求从预热系统取该订单匹配到的交易规则，拦截则返回交易失败；如匹配到限额规则则锁定，消费成功消费限额；消费失败回滚限额。

白条预热系统设计思路

首先我们先看一下预热系统的通用架构，也是解决高性能、高并发的常用方法论。

• 事件触发数据初始化、实时更新，保证数据时效性
• Woker定时同步更新数据，保证数据一致性
• 读写分离，保证服务稳定性，独立部署，方便扩展性
• 多套缓存集群热备，保证服务可靠持续可用

除白条交易风控规则外，账户、优惠券匹配、购物车优惠文案、账务等多个业务根据各自的业务特点的优化，也都不同程度的用到预热的思想，篇幅问题就不一一赘述。

三、后期规则

随着业务规模的快速增长，对性能的要求越来越高，现在的数据库模型存在以下两个问题：

1. 业务层、数据访问层的不断扩容，必定导致数据库连接数不断增加，然后硬件资源是一定的，连接数超过一定的阈值，必然导致整体性能的下降。
2. 现阶段数据模型，通过用户id路由，数据散列平均分布在各个数据库，数据库扩容必须迁移数据，扩容成本高。
3. 路由规则加入时间、机房等元素，水平扩容多组数据库集群，每组集群一主一备，数据访问层按机房或时间纬度部署多组，库负载过高时方便扩容
4. 每组集群内部，主库数据实时同步到备库，异步同步nosql
5. 主库发生故障时，通过关闭主库写权限，同时打开从库写权限，自动切换到备库

针对1和2两个问题，数据库模型做了如下改造：

四、总结

白条业务规模的高速增长，驱动了白条系统的迭代升级。虽然经受了数次流量峰值的考验，但革命尚未成功，仍需要我们不断的优化迭代。

希望我们白条越做越好，让更多的人了解白条、享受白条福利。我们大白、小白也会继续努力，为用户提供更加优质的支付体验。

本文作者：京东金融白条业务研发组 郭泽渊

本文链接：https://www.yangzhibaike.com/post/9656.html

声明：本站文章来自网络，版权归原作者所有！