一文读懂转转售后状态机

见贤思齐

一、背景二、设计与实现2.1动作执行抽象2.2同步or异步2.3补偿机制2.3.1技术选型2.3.2方案落地2.4执行延时三、总结一、背景电商行业的售后服务，通常都伴随着极其复杂的业务场景。不仅需要与正向订单流程呼应，还需要与质检、仓储、物流等信息进行交互，实现售后流转。笔者目前负责售后业务的研发工作，接下来将为大家介绍，售后流程中最为核心的部分：状态机。二、设计与实现2.1动作执行抽象对于售后单来说，单据状态体现出了处理进度。而状态的变更都是由动作进行驱动的，可以简要比作如下形式：单据到达不同的状态，就需要执行不同的动作。想要实现这一功能，最简单的方式就是ifelse了。对于不同的状态进行不同的执行处理。但是状态值一多，这种代码根本无法维护。那既然我们每次执行都需要执行一个动作，那么是否可以将动作抽象出来，形成一个模板呢？答案是肯定的。首先，每个动作的执行，都可以抽象成下面的表达式：然后，以动作为基准，使用策略模式将不同的动作独立成不同的执行单元：我们现在可以根据不同的动作处理不同的逻辑，可以再进一步分析每个动作的共性，并将其抽象成执行模板，每个动作都按照同样的执行模式进行逻辑处理：上图可以看出，笔者在实现类与接口之间增加了一个抽象类，之所以做出这样的改动，是为了将通用方法再次做一层封装，并对接口做出基础实现。当然大家也可以使用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消息，如果在延时时间内没有人工处理当前单据，那么就由系统自主触发审核。三、总结状态机的流转可以适用于很多场合，其主要思想是将执行过程高度抽象，再基于自身业务场景将流程模板化，对于需要执行的动作通过同一流程表达出来。有了执行框架之后，再针对业务痛点制定优化策略，逐渐丰富功能。