#618复盘系列# | 解密白条交易架构实践

点击「京东金融技术说」可快速关注

—消费者金融研发部小伙伴们

「摘要」白条业务每年200%+的增长速度对交易系统并发量、稳定性、扩展性以及容灾能力都是特别大的挑战。以今年618为例：

• 计息系统调用量每分钟数百万

• 白条入口级展示调用量每分钟上千万

• 预热系统每分钟调用量上千万

• 营销规则匹配每分钟数亿次

• 高达99.99%的支付成功率... ...

1

如何保证服务的持续可用

对于交易系统而言，支付服务的持续可用是系统设计需要考虑的重中之重，“618”为例，哪怕一分钟的服务故障，损失的不仅是巨额的交易收入，更重要的是用户的体验和对我们产品的态度。下图是白条交易对服务持续可用的实践：

图一

 

1、业务层、数据访问层，异地多活，多机房部署，基于JSF发布服务，通过全局负载均衡，动态分配流量。当某台机器或者某个机房发生故障时，可通过管理平台实时下线故障服务，保证支付请求的正常交付。

 

2、数据库作为整个交易链路强依赖的部分，数据落地的介质，不容有失。白条通过DB+（mysql+nosql+分布式）同城双活的方式实现灾备。

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

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

2

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

1、单体服务故障策略

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

图二： 单体服务故障条件

 

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

♣   并发请求：并发控制。常见并发主要有：访问并发、库并发。访问并发可通过配置niginx防刷、优化性能提高服务器吞吐量、扩容机器全局负载分配流量。库并发很少用数据库事务隔离级别处理，大多时候通过库字段乐观锁防止并发

♣   重复请求：幂等控制。异步化、woker等重试请求通过时间幂等控制重复请求

♣   超量请求：配额控制。根据来源配置限额，防止超量请求

♣   请求积压：请求丢弃。积压请求合理重试，超时未处理归档丢弃，防止不断重试对下游系统压力

♣   处理超时：时间控制。合理设置超时时间，防止单一接口占用所以线程资源，影响整体性能，更甚造成雪崩

♣   处理中断：事务保障。数据库事务+异步消息机制保证最终事务一致性

♣   通信故障：合理重试。

   

2、单体服务优化

♣   白条依赖服务简介

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

如图三所示，白条交易链路依赖接口都在毫秒级，每一个接口都是根据各自的业务特点，多纬度优化的结果，主要包括：

1、  多线程并行计算

2、  存储结构优化

3、  缩短主链路，异步消峰

4、  代码review... ...

♣   预热系统应用案例

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

1、  背景

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

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

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

图四

•    用户下单瞬间，预热系统收集订单、用户、渠道等信息，预热需要的属性

•   Woker定时更新交易风控规则到服务器内存，保证数据一致

•   白条交易风控规则CRUD操作，通过消息更新内存数据

•   支付、试算请求从预热系统取该订单匹配到的交易规则，拦截则返回交易失败；如匹配到限额规则则锁定，消费成功消费限额；消费失败回滚限额。

 

2、白条预热系统设计思路

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

图五

•   事件触发数据初始化、实时更新，保证数据时效性

•   Woker定时同步更新数据，保证数据一致性

•   读写分离，保证服务稳定性，独立部署，方便扩展性

•   多套缓存集群热备，保证服务可靠持续可用

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

 

3

后期规则

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

1、业务层、数据访问层的不断扩容，必定导致数据库连接数不断增加，然后硬件资源是一定的，连接数超过一定的阈值，必然导致整体性能的下降。

2、现阶段数据模型，通过用户id路由，数据散列平均分布在各个数据库，数据库扩容必须迁移数据，扩容成本高。

针对以上两个问题，数据库模型做了如下改造：

图六

♣   路由规则加入时间、机房等元素，水平扩容多组数据库集群，每组集群一主一备，数据访问层按机房或时间纬度部署多组，库负载过高时方便扩容。

♣   每组集群内部，主库数据实时同步到备库，异步同步nosql。

♣   主库发生故障时，通过关闭主库写权限，同时打开从库写权限，自动切换到备库。

 

4

总结

白条业务规模的高速增长，驱动白条系统的迭代升级，虽然经受了数次流量峰值的考验，但革命尚未成功，仍需要我们不断的优化迭代。希望我们白条越做越好，更多的人了解白条、享受白条福利。我们消费者金融研发部也会继续努力，为用户提供更加优质的白条支付体验。

京东金融技术说

   ▼▼▼     

原创·实用·技术·专业

不只一技之长

我有N技在手

你看，我写，共成长！