Building a Business Risk Management System for Logistics

一、什么是业务风控

互联网流量红利时代趋于结束，如何低成本的获得高质量的流量，是众多互联网公司在业务发展中的重要锚点。

根据中国信息通信研究院2021年《移动数字广告与互联网欺诈蓝皮报告》，整个2020年期间，国内互联网假量占比连续多月超过 30%，直接和间接造成的经济损失超过1500亿元。在欺诈流量中，出行行业是仅次于电商的第二欺诈流量来源。（因疫情影响，过去两年出行行业欺诈流量占比略有下降）

达达快送作为同城配送的头部企业，在做线上营销时常会遇到黑产流量的攻击。图1可看出，一波异常流量，从凌晨持续到中午。这部分流量恶意注册裂变，套取平台补贴，消耗营销费用，给平台带来严重的业务损失。所以构建线上风控系统尤为重要。

黑产流量来自于虚假需求，其目的是骗取平台补贴，其结果是扰乱平台正常交易撮合秩序。

黑产流量与正常流量的重大区别是，黑产流量的用户生命周期总价值为负，正常流量的用户生命周期总价值为正。换句话说，运营正常流量，拦截黑产流量，是业务能有效增长的重要报障。

而所谓业务风控，就是对黑产流量做精准识别、拦截，并尽量减少对平台用户的干扰。

1、黑产产业化带来的挑战

黑产发展到当前，产业已经相当成熟。下图是黑产产业链的产业结构。从图中可以看出，黑产产业链成熟，分工精细。这大大降低了黑产的攻击成本，同时也导致黑产门槛低，黑产攻击范围广泛，黑产受害群体更普遍。

我们平台在发展过程中也验证了这一现象：历次平台营销活动，均经历了被黑发现，攻击，对抗的过程。

2、风控的底层逻辑

要知道，不存在无法攻破的系统。差别是，有的系统的攻破成本低，有的系统的攻破成本高。

从黑产的角度看，黑产来到平台，目的是通过一定的手段，赚取平台补贴。而黑产的攻击工具箱里的工具，代理ip，虚拟账号，虚拟设备， 群控设备，自动化脚本，每一个的使用都是有一定的成本。黑产的盈利空间=赚取平台利润 - 攻击成本。黑产的盈利空间越大，黑产攻击意图越强烈。

从平台角度看， 风控系统正常的运营也有一定的运营成本。这部分成本包括研发成本、数据分析成本、系统运营维护成本。风控成本加上活动的其他投入成本，不能高于活动带来的总收益，否则即便成功拦截了黑产，活动本身已经没有正向收益，也得不偿失。

概括下来，风控就是用低成本的方式提高黑产攻击成本并达到一个收益平衡的过程。

二、物流业务风险场景

物流系统与典型电商系统的业务风险场景有一定的差异。除了典型的营销系统、商城以外，达达具有物流特有的风险场景。

1、营销系统

营销系统包括达达需求侧的平台业务的拉新留存业务，骑士激励、招募等业务。营销系统的特点是玩法多，迭代快。这给业务风控系统带来的挑战是，业务多接入成本高，风险点多风险接入点易疏漏，风险变化快风险对抗节奏快。

业务多是指营销系统有繁多的活动玩法：裂变、促活、投放、激励等活动玩法，活动玩法随运营策划种类多。这要求风控系统具备低成本、快捷的、统一的接入能力。

风险点多是指，由于活动玩法复杂，一个活动存在众多风险点，比如任务领取、邀请好友、提现等多个节点在同一个活动内均需要接入风控。这要求业务风控系统与业务有较深入的结合。

风险变化快是指，同一个风险拦截方式具有一定的时效性，黑产会针对风控逻辑做攻击的工具升级对抗。这要求风控系统具有低成本、高时效风险规则迭代能力。

2、订运单流程

达达物流包括需求侧与履约侧。需求侧除了从客户端直接下单的平台业务外，还包括通过开放API下单的KA业务、京东到家订单业务。这部分业务存在虚假单、刷单等欺诈风险。

3、骑士商城

达达商城是达达平台为骑士提供的增值服务。骑士可以通过平台便捷、优惠的购买骑士日常用品。该业务面临着和主流电商平台类似的电商欺诈风险。

三、业务风控关键模块

风控系统按照功能模块，可以分为４部分：风险感知，风险拦截，风险分析，效果监控。

1、风险感知

风险感知的关键是，结合具体的业务场景，收集齐备数据。

2、风险拦截

风险拦截包括实时拦截规则引擎和风控规则管理后台。

３、风险分析

风险分析包括实时数据风险分析和离线大数据风险分析。

４、效果监控

效果监控包括风控指标监控和对应业务指标监控。风控指标监控从用户行为角度包括风险率，拦截率，误拦率等，从账号维度包括设备量、账号量等。业务指标随着各种业务场景会有不同的差异，概括的说，包括业务请求量和利益点流量。比如说，营销系统会关注不同业务线的补贴金额，订运单会关注虚假订单量，下单设备量等。

当指标本身异常或指标间趋势不一致时，则会触发风控报警。

四、风控系统实践

1、风控架构设计

风控系统作为一个系统，不能简单理解为决策风险的实时服务自身。风控系统正常的运行需要研发人员与运营人员共同协作，涉及风控核查，风控运营，风控策略分析师、产品经理、系统开发工程师等多个角色，系统由业务服务、实时风控服务、风控策略管理后台、风控客服操作后台、大数据离线分析系统、风控监控报表系统等多个模块组成。总之，风控系统是一个非常庞大的系统。下面是达达物流风控的总体架构设计图。

风控系统的实现有５部分组成：

Ⅰ、业务层

该层是业务接入层。各种存在业务风险的功能需要将业务关键环节接入风控，这种关键业务节点被称为风控接入点。

Ⅱ、实时风控平台层

基于风控数仓层的风控平台层，就是风控系统的核心层。这一层连接业务层与数据层。业务请求会首先进入风控平台层，运营对应的策略、通过对应的模型校验，做实时的数据累计，最终形成实时风险等级的判断，供业务做决策。为支撑风控平台正常运营，风控运营层对风控平台做管理和后处理。

Ⅲ、数据处理层

最下层是数据层，包含实时数据、离线数据等。需要注意的是，数据层并不只做数据的存储，数据层会对数据做前处理，数据维度、指标的转换、去重、清洗等。

Ⅳ、数据收集层

数据采集层，并不能望文生义的理解为前端层。根据风控的业务特征，数据采集包括4部分：行为数据，设备数据，业务数据。其中行为数据和设备数据在前端产生，需要前端上报，这部分也相对比较清晰简单。业务数据相对就比较复杂，数据的采集也是千差万别。业务数据根据业务架构的特点有不同的采集方式，常用的采集方式包括：消息通知，主动接口查询，底层DB直接数据同步。

各种数据采集方式分别有自己的优缺点，主动接口查询实时性好架构简单，但会给下游服务造成压力。最终采取哪种方式，取决于数据要全，实时性要有报障，架构足够简单三者之间的平衡。

Ⅴ、风控运营层

策略运营等基于数据层数据做数据分析，输出有效的策略、模型，形成规则，并同时对底层数据加工处理，形成监控指标。

模型层和数据层由于关系比较紧密，在物理架构上都属于风控数仓层。

2、风控规则引擎

规则引擎作为风控平台的核心模块，其引入对提高对抗黑产的效率至关重要。有了规则引擎，就能做到对黑产实时分析，实时上线，实时拦截。不用经过分析，研发，测试，上线等漫长过程。

规则引擎就是一段if-then结构，if里面是策略规则，then是满足规则所要执行的行为。

规则引擎的目的是提升对抗时效，其关键有两点：①数据收集要齐备；②拦截逻辑的迭代要灵活。

为了实现拦截逻辑的灵活迭代，第一，需要将风控场景中的数据按一定层次进行组织，最大化的复用数据。第二，需要将风险拦截算法数据化，从而实现实时变更拦截算法，这里我们引用规则引擎。

风险拦截过程中的两个关键领域模型是因子、规则。规则引擎不是直接建立在通过各种渠道收集到的原始数据上的，而是建立在因子之上。

所谓因子是风险拦截中的最小数据单元。举个例子，前端上传的User-Agent并不能直接用于风险拦截，需要对User-Agent做处理提取出设备平台、机型等原子性的信息，后续规则是建立在这些因子上运行的。

考虑到基于自身的业务的复杂性，传统的开源方案如Acitivities和drools，对于我的业务来说，过于重了。同时，阿里巴巴开源的EQexpress作为规则引擎，除了groovy脚本具备的灵活性、稳定性外，还具有线程安全、与Spring亲和性好等优点。我们并没有使用EQexpress，主要是顾虑其在社区内应用历史不长，文档不够丰富全面，一旦出问题难定位等原因。

达达物流采用了groovy脚本作为规则引擎。一方面是作为Java系统开发技术栈，开发人员对groovy上手快，另一方面，结合当前业务场景其灵活性满足要求，其三，groovy脚本与java虚拟机的兼容性好，在并发量大时，性能有报障，即便遇到性能问题，由于良好的社区生态也更容易获得帮助。

对于易用性，通过代码会有一个直观的感受：

drools脚本非常接近于自然语言，运营等非技术背景的同时很容易操作上手：

groovy 仍然具有很多技术细节，非技术背景同时很难直接使用:

3、风控流式计算

在风控流式计算中，累计函数是一个非常通用的场景。用一句话概括：某事件段内，若干个条件（维度）小，某个值的统计值（包括总次数、最值、中数）等。

实现该功能的技术方案有redis, mongoDB, flink三种。redis轻量易用性能好，flink复杂消耗资源多但可追溯，而mongoDB的方案属于复杂性与性能的平衡，且支持复杂的统计函数。以下是三种技术方案的对比。

达达最终采用了Redis的实现方案。这里的原因也很简单，redis足够简单灵活，性能好，适合互联网应用，同时达达的业务风控对溯源性要求不高，大多场景均是短时间窗下场景。

下面以某个设备上访问次数为例，基于redis zset数据结构，举例介绍下累计函数的实现。

实现代码：

4、架构高可用设计

在服务本身支持弹性伸缩动态扩容的基础上，我们将高可用设计的关注点放在了隔离设计上。

a、按照隔离粒度，可以分为三级：服务级隔离，接口级隔离，接口内逻辑隔离。

Ⅰ服务隔离。 服务隔离是指风控服务与业务服务做隔离部署。并且，当整个风控服务出现异常时，业务服务作为接入方，应该具备能力降级运行。比如风控服务出现不可用时，登录环节、下单环节均依赖风控服务，此时该主流程环节应该不受风控服务不可用的阻塞，仍然能够正常工作。

Ⅱ接口隔离。 接口隔离是指，在接口粒度做降级设计，当其中一个接口不可用时，只有该接口降级提供服务，只有当前接口熔断短路，不能影响其他接口的可用性。在设计中注意将接口的熔断分开在不同的线程池内部署就能实现，这里对实现细节就不做赘述了。

Ⅲ内部逻辑隔离。 事实上，很多服务都有内部逻辑的降级设计，比如最常见的三方依赖降级。风控之所以不同在于，风控作为独立的服务，同时对多种场景提供服务，同一个场景内由若干因子、规则同时执行最终得到结果，有时候因子、规则多达上百个，所以对场景、因子、规则之间隔离就非常有必要。当其中一个因子异常时，只影响并跳过依赖该因子的规则，不会影响到其他规则。通过隔离，将异常带来的业务损失降低到最小。

b、按照隔离手段，可分未手动隔离和自动隔离。

Ⅰ自动隔离。 在各级交互界面之间，当下游模块出现异常时，服务会自动降级为一个业务可接收的有损状态，维持上游模块正常运行。比如接口出现异常达到一定比例后，具备自动熔断，不再校验风险，避免影响接口整个响应事件，甚至业务的正确性。

Ⅱ手动隔离。 在各级交互界面之间，可以以手工开关的方式做隔离。比如订运单主流程可以独立于风控服务运行，比如大促期间，服务压力过大，可通过手动关闭若干非必要风控，降低系统并发，缓解系统压力，提升核心流程性能等方式。

五、总结

本文介绍了互联网服务面临的业务风控的调整，并结合达达物流自身的业务特殊性，介绍了同城物流行业的业务风控场景。在此背景下，本文介绍了达达风控系统的架构设计，并对架构设计中的关键技术做了介绍，比如规则引擎、实时统计和架构的高可用设计。

关于作者

曹圣路: 达达集团高级工程师, 2019年加入达达集团， 达达物流风控系统技术负责人之一，目前投入在达达用户增长团队，致力于构建完善的营销系统支持业务的高速增长。

陈小钦：达达集团高级工程师，2020年加入达达集团，从零搭建基于规则引擎的风控系统的技术负责人之一，目前投入在达达用户增长团队，致力于通过风控支持业务稳定健康的增长。

加入我们

达达集团目前还处于高速成长期, 欢迎对技术有追求的同学加入, 可发送简历至: [email protected] , 邮件标题: 姓名-上海物流-Java高级开发工程师/资深测试工程师