司机提现链路架构演进

1 背景

随着货拉拉业务量的持续攀升，提现链路作为资金流出的主要链路，其业务规模和资金体量也在不断扩大。在提现链路建设的初期，为了保障资金安全，提现流程需要依赖人工审批，但随着业务规模的迅速增长，人工审批逐渐跟不上日益加快的业务节奏。因此，提升提现链路的自动化水平，既是应对业务发展的必然选择，也是后续链路建设的重点方向。

2 提现流程

首先先介绍提现的主要流程，如下图，提现流程可以简化为4个阶段：

1. 钱包入账：司机通过交易入账、奖励发放、业务理赔等方式，将所得收入入账至货拉拉体系内的账务钱包。

2. 发起提现：司机主动发起提现申请。

3. 财务审批打款：财务部门对提现申请单进行人工抽样审批。

4. 银行出款：系统将提现申请提交至银行处理，完成最终的出款。

流程中存在的风险：

1. 司机入账：在收入入账前，会经过各端系统的风控规则校验。然而，这一环节仍存在部分无法完全规避的风险，例如刷单套现、技术异常导致的入账问题。

2. 发起提现：因系统链路异常，无法正常处理司机提现申请。

3. 财务审批打款：由于单量过大，当前无法全量核查，只能进行抽样审批，且周末及节假日无法打款。

4. 银行出款：银行系统异常，导致提现打款未成功。

接下来，我们将详细介绍如何通过对提现链路的架构演进，逐步解决上述风险，提升整体流程的安全性与效率。

3 架构演进

3.1 PHP时期 – 烟囱架构‍

在业务初始期，主要目标是快速实现业务功能，以尽快上线产品满足用户需求。提现链路整体流程较简单，由各个端自行建设。

优点：

1. 开发快：直接开发、上线，适合初创期小团队和快速试验。

2. 成本低：由于架构简单，开发和部署成本相对较低。

存在的问题：

1. 各端重复实现提现功能，能力无法复用。

2. 代码耦合严重，难以进行维护和扩展。

3.2 1.0时期 – 平台型架构

随着业务的快速发展，提现链路对系统的功能和性能提出了更高要求。在这一阶段，公司正处于技术栈调整的关键时期，从PHP迁移至Java。借助这一契机，我们逐步完成了从传统的“烟囱架构”向“平台型架构”的转型。这次架构升级的核心在于系统平台化和技术栈升级。基于业务领域的划分，我们构建了统一的公共平台能力，为各条业务线提供标准化、统一化的服务支持。这种平台型架构不仅提升了系统的稳定性和扩展性，还极大地提高了开发效率，为后续的业务迭代奠定了坚实基础。

当前阶段，司机提现打款审批依赖人工核查，由审批人员提供每日清单，人工进行抽样核查。抽样数量有限，且核查过程耗时长，效率低。

3.3 2.0时期 – 自动化打款

在完成 1.0 时期的建设后，提现链路已具备了大部分核心能力。然而，如果要用系统代替人工审批打款，实现周末及节假日正常打款，还需解决以下关键问题：

1. 资金安全保障：提现链路需要增加最后一道兜底拦截机制，以保障资金安全。在提现出款环节，需重点识别因业务异常或技术异常导致的入账风险，确保异常资金不会流出系统。

2. 稳定性保障：提现与司机收入密切相关，其稳定性至关重要。若提现流程出现异常，不仅会影响司机体验，还可能引发客户投诉，甚至导致舆情事件。因此，需要进一步提升提现链路的稳定性，确保提现流程稳定可靠。 

3.3.1 资金安全保障

为区分资金风险和技术风险，我们将风控划分为两类：资金风控和资金内控。

3.3.1.1 资金风控

资金风控主要聚焦于业务层面的异常拦截，将财务人员在人工审批中使用的核查标准，转化为风控系统的自动化规则，来替代传统的人工抽样审批。这种方式不仅提升了审批效率，还能进行全量单据核查，大幅降低人工操作可能带来的遗漏风险，实现更加精确的异常识别与拦截。资金风控的规则设计需要结合业务场景和历史数据，涵盖常见的风险场景，确保提现链路在业务层面更加安全可靠。

3.3.1.2 资金内控

资金内控主要聚焦于技术层面的风险拦截，依托于公司前期构建的一套资损防控解决方案。其核心在于对数据链路的一致性核对，通过核对结果制定风控规则，以此来拦截可能存在的技术风险。例如，识别因幂等击穿、数据错漏或订单状态不一致导致的异常问题。资金内控不仅是对技术风险的有效防范，更是对资金安全的二次保障，确保提现链路在技术层面具备高度的可靠性。

• 命中资金内控
  ‍
  
  

‍

• 超时未打款

• 风控降级规则依赖降级

4 收益

通过对司机提现流程的改进与升级，取得了以下显著收益：

1. 资金安全提升

2. 系统能力提升

3. 司机体验优化

4. 降本增效

本篇文章来源于微信公众号：货拉拉技术