一文读懂转转售后状态机

• 一、背景
• 二、设计与实现
• 2.1 动作执行抽象
• 2.2 同步or异步
• 2.3 补偿机制
• 2.3.1 技术选型
• 2.3.2 方案落地
• 2.4 执行延时
• 三、总结

一、背景

电商行业的售后服务，通常都伴随着极其复杂的业务场景。不仅需要与正向订单流程呼应，还需要与质检、仓储、物流等信息进行交互，实现售后流转。笔者目前负责售后业务的研发工作，接下来将为大家介绍，售后流程中最为核心的部分：状态机。

二、设计与实现

2.1 动作执行抽象

对于售后单来说，单据状态体现出了处理进度。而状态的变更都是由动作进行驱动的，可以简要比作如下形式：

单据到达不同的状态，就需要执行不同的动作。想要实现这一功能，最简单的方式就是if else了。对于不同的状态进行不同的执行处理。但是状态值一多，这种代码根本无法维护。那既然我们每次执行都需要执行一个动作，那么是否可以将动作抽象出来，形成一个模板呢？答案是肯定的。

首先，每个动作的执行，都可以抽象成下面的表达式：

然后，以动作为基准，使用策略模式将不同的动作独立成不同的执行单元：

我们现在可以根据不同的动作处理不同的逻辑，可以再进一步分析每个动作的共性，并将其抽象成执行模板，每个动作都按照同样的执行模式进行逻辑处理：

上图可以看出，笔者在实现类与接口之间增加了一个抽象类，之所以做出这样的改动，是为了将通用方法再次做一层封装，并对接口做出基础实现。当然大家也可以使用default关键字直接在接口层面做处理。

笔者抽象出了四个方法：preInvoke、invoke、postInvoke、autoNext。这四个方法是状态机中最常见的几个方法。大家在自己实际的业务系统中，可依据实际情况自行添加。下面简单对这几个方法做出释义：

• preInvoke：前置业务逻辑校验
• invoke：动作流程执行的核心逻辑
• postInvoke：业务附加数据处理
• autoNext：自动流转下一指定动作

以上，基本的数据流转骨架已经出来了，剩下的便是在此框架基础上进行填充。

2.2 同步or异步

上述接口是能够保证状态正常流转的，但是会遇到一个问题：某次执行请求可能会很长。那么造成这一现象的原因又是什么呢？通过分析流程不难发现，便是：autoNext这步操作。

通常我们执行完一个流程就正常结束了，但是在实际应用中我们肯定会有自动流转的诉求：

上图描述了一个场景：对于客服审核通过的售后单，我们可以通过物流动态，决定是否能够通过系统帮助用户进行实物寄回的操作，也就是信息流的自动流转。当我们可以自动操作的时候，本来执行一步【审核】的时间，变成了执行两步【审核 + 寄回】的时间，必然会拉长整个接口的请求时长。而且，对于操作审核的客服人员来说，只是关心【审核】这一操作是否成功了，后续的【寄回】流程的结果是不应该掺杂在本次【审核】结果中，所以对于自动流转的流程，都可以放到异步线程去解决，将其与现有操作解耦。

事实证明，异步化之后确实会提升整体接口的响应时长，但是细心的同学就会发现另外一个问题：异步执行是系统自行操作的，没有人能够感知到，处理失败了怎么办？请大家耐心往下看。

2.3 补偿机制

执行失败的数据，在系统上需要做好闭环处理，那么补偿机制便显得尤为重要。

2.3.1 技术选型

在补偿机制上，Spring提供了重试注解：@Retryable，通过捕获指定异常的方式进行重试。但是笔者使用的是另一种机制：MQ。之所以不使用注解的方式，是希望重试这一动作更灵活且更可控。通常情况下，在系统出现异常的时候，并不会在短时间内就会被恢复，所以短时间的重试意义并不大。

2.3.2 方案落地

具体的实现方案也很简单，在流程处理过程中，手动捕获处理结果，对所有处理失败的，或者抛出异常的动作流程，都发送延时MQ（这里的延时MQ是转转架构部封装的功能，其基本原理是通过时间拨片轮询的方式，在指定的延时时刻发送MQ），将需要执行的动作与业务数据都放入到消息体中，延时时间可依据不同的业务诉求做不同的处理。当我们接收到消息之后，便可以对失败的流程做重试处理进行补偿。

2.4 执行延时

受到补偿机制的启发，我们发现“延时”这个操作可以扩散应用到很多地方，对状态机的运作用处最大的是：延时执行。举个栗子：

比如售后的审核流程，除了必要的人工审核外，大部分根据业务规则做系统自动处理。这就要求技术方案上支持系统自动流转。技术实现上，我们依赖延时MQ，设置延迟时间，从而实现系统自动流转。

上图中可看到，在用户申请的同时，我们就发送出延时MQ消息，如果在延时时间内没有人工处理当前单据，那么就由系统自主触发审核。

三、总结

状态机的流转可以适用于很多场合，其主要思想是将执行过程高度抽象，再基于自身业务场景将流程模板化，对于需要执行的动作通过同一流程表达出来。有了执行框架之后，再针对业务痛点制定优化策略，逐渐丰富功能。