#618复盘系列# | 天盾风控3.0系统剖析及618总结

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

---天盾引擎开发的小伙伴们

「摘要」2年多时间，天盾风控系统从无到有，从支持少数场景，到支持京东200多个业务全场景订单业务，及金融各主要业务，线上策略的数量从几十条发展到上万条。为了满足京东业务发展及高性能的服务需求，天盾风控也在不断升级优化。

天盾风控系统简介

天盾是保障京东商城及金融主要业务安全运行的风控系统，已接入业务场景达200多个，主要接入场景类型如下：

• 授信安全

• 支付业务

• 营销系统

•  账户安全

•  支持各种验证方式

 

1、天盾风控系统架构

接入的业务系统调用天盾时，天盾实时获取指标，指标通过指标加工系统生成，系统根据指标实时计算风险结果，返回上游系统。

2、天盾内部系统：

• 设备指纹

针对京东PC及H5页面采集设备信息报送天盾。

• 食蚁兽系统

食蚁兽系统是风控实时统计平台，适用于各种流式计算，可进行高密集，多维度，可伸缩，配置灵活的复杂计算的统一平台。

• 天盾引擎

天盾风控实时计算引擎，实时收集计算指标，并根据指标执行规则和模型，生成实时风险结果返回上游系统 。

 

天盾系统历史版本

1、天盾1.0系统

前身为京东白条风控，2015年初上线，主要覆盖10+种业务场景。使用Groovy 语言，原子规则，规则包，试用设备指纹。

☀  规则决策关系

原子规则：原子规则是最小粒度的规则单位，是基本指标计算。

规则包(决策)：不同原子规则的组合，根据规则包(决策)的命中情况返回上游结果。

 

☀  内部结构

上游系统调用天盾引擎后，引擎获取该业务的规则包，并解析规则，并行运行原子规则，最终获取结果返回收银台。

2、天盾2.0系统

☀  2.0系统特点：

• 规则改用java语言，2015年底试运行，2016年初上线

• 加入维度概念，所有规则都被放在固定的维度中，所有决策围绕维度进行配置

• 接入京东金融多种支付方式；多种不同订单业务；近200个业务场景

• 全场景使用设备指纹

• 加入食蚁兽

• 入模型，模型与规则并行

• 密码支付，指纹支付，无密支付，短信支付

 

☀  规则决策关系

2.0系统添加了维度的概念，规则脚本是原子规则的组合，通过维度与得分来表示一个规则脚本。

决策是维度得分的组合，其实就是脚本的组合，根据决策的命中结果返回上游系统。

☀  天盾2.0内部结构

 3、天盾2.0系统存在问题

• 维度问题：系统中的维度未起到实质性作用，无谓消耗了系统运行时间并增加了配置复杂度

• 原子规则配置混乱：针对重复性原子规则，不同场景参数要重新配置，参数配置问题查找困难，原子规则重用配置性比较差

• 随着规则的不断增多，系统运行时间不断增加，难以达到业务的需求，急需设计新系统，提高系统的性能，降低系统响应时间

 

• 2.0系统性能问题

随着规则的不断增加，主要交易场景性能已经无法满足业务需求

• 往年大促前的准备工作

和业务方一起梳理规则，主要方法如下：

  

为应对大促的到来，保证系统的响应时间，需减少一半以上规则。带来问题主要是规则的覆盖度更粗，影响的范围更大，增高了加验率和拦截率，误命中或漏命中的概率更大。

 

天盾3.0系统

 

1、天盾3.0系统

• 针对原有天盾2.0系统配置复杂，规则数量迅速增加导致的系统性能过慢的问题，制作天盾3.0系统，解决性能问题和易用性问题

• 2017年1月开始开发，3月底试运行，4月下旬正式上线

2、设计前思考及实现

思考： 如何构建快捷高效的系统？

• 流程上是否可简化？

• 系统内部组件关系设计是否合理？

• 可否减少系统内部的无谓损耗？

• 系统是否简单易用？

从以上几点考虑着手设计实现天盾3.0系统

 

☀  天盾2.0系统流程上是否可以简化？

针对原子规则的获取可以提前计算并预热保存，针对获取决策结果可在单个原子规则执行完毕后提前获取，下图为3.0系统简化流程后的新流程：

☀  系统内部组件关系设计是否合理？

2.0系统内部组件关系

在天盾2.0系统中，维度和维度得分未起到实质作用，只是增加了配置和运行复杂度，在3.0系统中去除了维度，重新定义原子规则，规则脚本，与决策的配置关系，下图为天盾3.0决策配置关系

使用脚本id代替维度及维度得分，决策只支持”与”的逻辑关系，上图中根据优先级获得的原子规则为4,5,1,2,3。 

另外从执行完所有原子规则后生成决策结果，变为根据原子规则结果实时生成决策结果。若原子规则1,2,3,4,5的取值如下图，则生成决策结果如下

根据决策优先级，决策2命中返回结果。

☀  可否减少系统内部的无谓消耗？

在2.0系统中，上面几个原子规则会并行执行，并对jsfA,hbaseA,redisA,jsfB重复调用多次，产生了无谓消耗，在3.0系统中，保证对重复性的查询只查一次

另外在3.0系统中，根据规则查询数据的情况，对简单内存计算同步执行，减少多线程执行的消耗，上图中ruleE没有查询远程数据，因此只会同步执行

☀  系统是否简单易用？

系统实现对客户要具有良好的使用体验和较小的学习成本。

 

3、3.0系统上线后的实际性能情况

同场景同策略条件下天盾3.0性能比2.0提升近200ms，如下：

升级前天盾2.0主要场景性能

升级后天盾3.0主要场景性能

 

天盾3.0系统618大促

1、618大促前准备工作

☀  迁移天盾最主要场景到天盾3.0系统

天盾3.0上线后系统性能有显著的提升，为保证天盾最主要业务的性能，在已接入的200多个业务场景中，选择最重要的业务场景策略迁移至天盾3.0系统。

☀  对迁移场景后的天盾3.0进行压测

• 对单一业务压测：

对天盾系统中调用量最高，规则数量及复杂度最高的场景分别进行压测：

• 对以上业务进行同时组合压测：

以上压测均按最大策略数量进行，系统性能良好，按压测情况618无需再像往年大促需要下线规则。

 

2、618期间系统实际运行情况

☀  618零点主要支付场景1性能

策略数量是去年双11的2.5倍以上，性能依然有所提升

☀  618零点主要支付场景2性能

策略数量是去年双11的3倍以上，性能依然有所提升

从1.0到2.0，再到3.0，天盾的版本更新见证了京东的飞速发展，相信随着业务进一步高速发展，天盾系统也将不断的迭代优化以满足需求，我们将继续努力，做好京东的保护盾。

京东金融技术说

   ▼▼▼     

原创·实用·技术·专业

不只一技之长

我有N技在手

你看，我写，共成长！