解密白条交易架构实践

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 总结

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