解密白条交易架构实践

阅读数:1 2020 年 3 月 22 日 21:06

解密白条交易架构实践

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

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

评论

发布