严选逆向交易系统建设的思考与实践

什么是逆向交易？逆向交易的业务边界是什么？逆向交易面临的难点和痛点又是什么？很多同学对此表示不解，经常听到针对此类问题的讨论。本文主要是向大家介绍逆向交易系统实践过程中的基本思路和实施策略，以及核心业务流程。

1. 前言

严选在前期发展过程当中，主要受商业环境的影响，业务玩法层出不穷，业务飞速迭代过程中C端交易逆向流程一直是最容易被忽视以及容易出现线上问题的场景，并且在逆向流程日常运维过程中，一直由交易域领域专家跟进处理，消耗着交易域宝贵的研发资源，给用户带来不好体验的同时还消耗着严选客服资源，且存在资损风险。

严选从19年初开始了逆向交易系统建设，系统性解决逆向交易的难点和痛点，本文主要是向大家介绍逆向交易系统的定位、核心业务流程及实践过程中的方法、策略及背后的思考。

2. 为什么要建设逆向交易系统

在电商平台交易过程中，主要有以下三个核心要素：

• 人：下单用户信息，收货人信息

• 货：所购商品信息，商品履约信息

• 款：支付信息，促销优惠信息

为方便大家理解逆向交易，在介绍逆向严选逆向交易系统之前，先给大家简单介绍一下严选正向交易核心流程。

严选在前期发展过程当中，主要受商业环境的影响，业务玩法层出不穷，复杂度集中在三要素中的“款”，演进过程中逐步衍生出N种促销玩法，如：优惠券、红包、积分、礼品卡、回馈金、补贴金等优惠的使用和发放，支持几十种支付渠道，包括：支付宝、微信、网易支付和云闪付等。

相对应的，在逆向交易流程中，需要退还支付的现金、退还使用的优惠以及回收发放的优惠，下面先看一下逆向交易的核心流程。

上图只列举了“支付后取消订单”和“售后退货退款”两个典型的涉及逆向交易场景，实际上逆向交易场景有近20个。我们接着来看原来的实现方式，核心逆向交易逻辑都堆在一个公用jar包中，这个jar又被C端系统和B端系统直接引用，C端系统和B端系统又归属不同的技术团队。

早期严选业务野蛮生长，技术实现亦是如此，如上图所示，这种烟囱式架构引入了大量的技术债：

• 文档负债：缺乏统一的接口文档，影响开发和运维效率。

• 代码负债：
• 重复代码：带来开发维护成本的增加，增量需求改造不完整会导致系统表现不一致等额外风险。
• 代码耦合度高：业务域之间等存在参数、类和接口高耦合，代码改成成本高，影响面难以评估。
• 代码复杂度高：条件语句过多，过程控制过于复杂，程序扩展性差。

• 管理负债：不同的技术团队维护同一份代码，协调成本高，工期很长。

结合逆向交易业务背景和引入的技术债，逆向交易系统的建设会围绕以下的设计目标进行开展：

1. 构建逆向交易微服务，降低逆向交易与客服、售后，四端和支付等系统的耦合，简化业务实现复杂度，并且引入接口平台管理逆向交易接口。

2. 抽取所有现金和促销优惠的共性，构建通用的逆向交易能力，简化业务方接入成本，通过流程引擎提升退款审核流程扩展性。

在这里给出逆向交易的定义：已支付订单逆向流程中，完成对现金和全部促销优惠逆向操作的编排。

下面给大家介绍在逆向交易系统实践策略以及背后的思考。

3. 逆向交易系统实践

3.1 建设思路

• 先把书读厚，再把书读薄：边界治理
  首先，把交易逆向业务流程梳理清楚，并且理解透彻实现方式。三个重点抓手：当前业务代码实现、日常线上问题跟踪和向原业务域领域专家请教。目标主要是两方面：了解交易逆向业务复杂度和团队日常协作过程中的痛点。
  然后，通过微服务化完成边界治理，抽象逆向交易域能力，提升逆向交易域能力复用程度，简化业务实现复杂度。
• 寻找最小价值交付单元：需求交付策略
  结合当时团队和业务背景：严选业务快速迭代+逆向交易服务化资源不足+服务化对业务影响面必须可控。客观因素不支持一次性完整交付逆向交易项目，并且从历史经验来看一上来就集中多数资源参与的大项目，成本高、压力大，失败的概率更大。在真正的竞争压力面前，拆分逆向交易域最小价值交付单元，进行阶段性价值交付，优先交付高价值单元是最优选择。

上图中，展示了逆向交易项目交付的5个阶段，交付路径背后的考量主要有以下四点：

• 独立交付，逆向交易域拆分的各个阶段都能独立交付。

• 交付内容依赖关系，逆向交易域中“退款能力”属于基础能力，必须优先交付。

• 交付的成本和节奏，技术重构项目建议的交付周期是两周到一个月之间，如果交付过于频繁会打乱研发节奏，交付时间太长则会导致积攒很高的风险。

• 把握技术重构与业务需求之间的平衡，技术重构不能影响日常业务价值交付。

3.2 架构设计

• 建模阶段通过事件风暴完成设计从0到1：召集业务团队、产品团队、技术团队对领域信息和领域边界达成一致，统一语言，输出领域模型，通过抽象、封装和多态等设计要素，提升代码的复用程度，降低系统的业务复杂度。
• 确定“退款能力”、“退款查询”、“退款计算”、“订单取消”和“包裹取消”等领域能力；
• 构建“审核通过”、“退款成功”和“退款失败”等领域事件。

• 实施阶段采用经典的四层架构设计：在划分的业务边界内持续演进。

• 十大主流应用场景

发货前客服取消	发货后直接退款	发货后货到退款	客服创建直接退款	发货前包裹取消	发货前用户取消	发货后拒收退款
价格保护	退运费	客服赔付退款	渠道退款	渠道赔付退款	回馈金债务退款	积分债务退款

3.3 核心流程设计

3.3.1 退款审批流程 ：扩展性设计

说到审批流程，有同学估计会有疑问：一定要有审批流程吗？既然有了系统审批流程，那人工审批流程存在的意义又是什么？

先针对上面两个问题做简要解答：

1、审批流程的存在是合理的，核心意义是减少客户投诉和降低资损。

2、人工审批的价值在于建立更新审批标准、优化系统审批模型、为用户提供更精准的审批服务等，同时会为系统审批结果进行复查审批。

从退款审批流程图可以看到，根据不同产品支持不同的审批流程，定制审批流程节点，通过流程引擎来管控审批服务。

涉及审批流程变更以及需要重点关注审批流程的场景分类以下几类：

1. 售后场景由客服判定直接发起的退款流程，退款金额人工录入，审批环节能明显降低误操作概率；
2. 新产品逆向交易流程接入，审批流程必不可少；
3. 逆向业务流程中核心系统进行服务化或者涉及退款金额模型调整，审批环节需要特别留意。

流程引擎选择的是Activiti，主要原因是以下几方面：

• 开源免费；

• 逆向退款单的创建和执行解耦，不存在高并发场景，Activiti经过优化完全能够满足；

• 具备Activiti使用和优化经验，为逆向交易快速接入奠定基础；

• Activiti中节点定义粒度较粗，复杂流程中存在由理解不同造成节点定义粒度不一致等情况，但是审批流程节点定义比较明确，由不同的审批节点组合而成；

• 图形化编辑（如下图所示），流程数据和业务数据分离。

3.3.2 退款处理流程：降低复杂业务实现复杂度

从退款审批流程图中可以看到退款流程有“退款执行”和“补偿退款执行”两种类型的节点，实际上退款执行中编排了现金和各种促销优惠的逆向操作，细心的同学估计立马会问为什么不进行节点拆分并且由Activiti统一编排和管控，主要考量如下：

1. 从产品形态来看，严选主站逆向交易流程中现金和促销优惠逆向规则应该保持一致，否则用户会产生困惑；理论上不存在差异化的编排诉求，不做过度设计；

1. 为什么又把补偿退款流程单独拎出来呢？那是从业务形态上出发的，赔付和其他逆向交易流程存在着天然的差异性，赔付流程仅涉及单类现金或促销优惠的退还，不需要关联商品或者订单下单过程中使用的现金或促销优惠；

1. 从实现成本来看，进行节点拆分并且由Activiti统一编排和管控的模式，工作量会是当前实现方式的两倍以上，加上当时资源不足和工期压缩的背景，不做Activiti统一编排和管控是最优解。

退款主流程：退款能力抽象&聚合

• “退款执行”流程

• “补偿退款执行”流程

看到这，大家能直观感受到“退款执行”和“补偿退款执行”两个流程之间的差异是非常明显的。

• “退款执行”对应的是常规退款流程，例如：取消订单、取消包裹、售后退货退款等场景触发的退款；

• “补偿退款执行”则是对应非常规退款流程，例如：价保和售后赔付等场景触发的退款。

消息处理机制(EventBus)：消息解耦

微服务构建过程中，通常会把一些非强依赖的调用改成MQ消息的方式，逆向交易也不例外，比如：退款审核、退款成功和退款失败等几个节点通知给客售和超会等服务。

存在的问题是主业务逻辑和MQ消息组装生产逻辑耦合在一起，逆向交易采取的解决方案是引入Guava EventBus，通过观察者模式将一些和主业务逻辑不强相关的逻辑可以解耦出来，统一处理。

3.3.3 最大可退金额模型 ：资损兜底策略

在所有现金和促销优惠中，最敏感且容易造成资损部分自然是支付的现金，逆向交易系统必须对现金退还进行兜底，当前采取的兜底策略是：计算订单商品目前的最大可退金额，退款金额超过最大可退金额则直接失败。

上图中展示了现金退还兜底策略“最大可退金额”，但是实际业务会比图中复杂的多，计算“商品已退金额”部分就需要考虑十大主流应用场景。

3.3.4 特殊退款流程：适配正向交易订单模型

退款处理流程中，除了编排现金和促销优惠的逆向操作，还需要适配正向交易订单模型，比如：换货订单=多笔订单记录+单笔支付记录，定金购订单=单笔订单记录+多笔支付记录。

• 换货单退款流程

举个换货订单的例子，比如：用户收到一双鞋子发现尺码不合适，通过售后入口申请换货，申请后需要把收到的鞋子退回给商家，商家会根据用户要求的尺码重新派发一双鞋子给用户。在这个过程中，严选会生成一个新订单关联新发货的商品，但是支付和促销优惠等记录只会关联老订单。那么严选逆向交易是如何处理现金和促销优惠逆向的呢？

• 定金购订单退款流程

定金购是近几年非常流行的一种促销手段，本质是预售商品，客户需要先支付定金，到特定时间段再支付尾款。商家根据订单量来准备产品，降低成本，消费者也可以购买到物美价廉的商品。 企业通过预售，也规避掉一些快递或者库存的风险。下图中展示的严选逆向交易处理定金购订单的现金和促销优惠逆向流程。

通过对比，可以发现换货订单和定金购订单模型差异巨大：

• 定金购订单：定金订单和尾款订单都会使用现金和促销优惠，针对尾款订单发起逆向流程（比如：取消订单），需要对定金订单和尾款订单使用的现金和促销优惠都执行逆向操作，涉及多笔支付订单。

• 换货订单：只有原始订单关联资现金和促销优惠，针对换货后订单发起逆向流程，需要定位到原始订单，然后对原始订单使用的现金和促销优惠执行逆向操作。

4. 小结

• 本文重点介绍了逆向交易的核心流程和背后的设计思路，相信能坚持看完的同学对严选逆向交易有了一定的了解，如果想了解很多内容或者细节，欢迎在文章后面留言。

• 截止目前，逆向交易已完成退款能力、订单取消和包裹取消的建设，相比建设之前逆向交易域线上运维投入减少80%以上，新需求接入成本降低50%以上。后续我们将持续完成退款查询和退款计算能力的建设，进一步提升业务对接和运维效率，让我们有更多的时间去思考业务和技术，为用户创造更多的价值。

本文由作者授权严选技术团队发布