电商订单履约-卖家发货演化史

本文主要是介绍电商订单履约-卖家发货演化史，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1 背景

订单的履约之路就是从发货开始，看似简单的发货功能，其背后却藏着许多的小秘密。

发货的业务特点：

B端业务，性能要求不高，因为存在批量发货的场景。
发货时间比较分散，所以并发量不大。
业务复杂，涉及到N种订单类型的发货，不同的订单类型有着不同的业务规则。

随着公司业务的发展，订单类型的增多，没有进行抽象的发货逻辑随着迭代的推进难免会显得落后。当然，在迭代的过程中，也一直在优化，一直在演进，正所谓没有最好，只有符合当前业务现状的最合理。

2 一阶段卖家发货

卖家发货在一开始的时候，有N个接口。比如，现货单个发货，现货批量发货，现货极速发货，App发货，直发发货，定制发货等。

有这么多发货接口也是我们平台的业务特性决定的，现货就是卖家发货到平台，直发就是卖家发货到买家，不同的业务有不同的流程。除了接口多这个问题，另一个问题是逻辑分散，每个接口都是独立的逻辑，大量重复代码的出现极大地增加了维护的成本。

比较简化的发货流程如下：

参数校验
一些业务校验，比如订单状态，发货冷静期等
核销卖家优惠
推状态机
订单数据修改保存
广播发货消息
下发入库单
订阅物流轨迹
……

在整个流程里面，存在很多可以优化的点。如在订单数据更新之后的很多操作都可以通过异步的方式去处理，这样可以提高发货整体的性能。

总结下之前卖家发货存在的几个问题：

对外接口多，难以维护
发货业务跟订单类型强绑定
内部逻辑分散，无业务全貌
整体性能偏差

3 二阶段卖家发货

3.1 业务改造

前面也提到了，目前发货是基于订单类型分类来进行编排。之所以要通过订单类型去做分类是因为之前只有订单类型，所有的业务都是根据订单类型去做区分。主要还是没有站在履约的视角下去做发货这件事情，所以导致每加一种订单类型，对发货都有一定的影响。

在履约视角下，会有履约单。履约单上有履约模式，目前有现货，直发，仓发，虚拟，服务单，跨境直发，跨境现货，跨境在仓。

履约模式是对货品怎么从卖家交付到买家手里的一种业务模式，不同的模式在业务流程的处理上不一样，在卖家发货的场景下，只关注货怎么到买家，而不需要关注订单是什么类型。

现货

现货模式指的是卖家把货发平台，平台质检/鉴别合格后再把货发给买家。现货类的订单类型有普通现货，极速现货，极速预售，定金预售等。

直发

直发模式指的是卖家直接把货发到买家。直发类的订单类型有品牌直发，定金预售直发，拍卖直发，众筹直发，盲盒直发等。

仓发

仓发模式指的是卖家提前将货发到平台仓库，买家下单后直接从仓库发出。

虚拟

虚拟模式指的是在线履约，无需快递配送。虚拟类的订单类型有随心省，洗护卡，虚拟卡卷等。

服务单

服务单指的是定制类的服务，需要将货品从平台寄到服务商，服务商完成定制服务后再寄回平台，再由平台寄给买家。

从履约模式的划分可以看的出来，每个业务场景都有一个订单类型，但从履约的方式来说都一样。二阶段发货会根据履约模式去做业务流程编排，不感知订单类型，这样就能沉淀平台化的能力，而不是跟着上层业务每次都需要改变。如有特定的针对某种订单类型的业务处理，这个逻辑会放在订单侧。

3.2 稳定性改造

在稳定性方面也做了一些改造，发货虽然不是导购下单链路，但也是非常重要的一个节点。发货有问题就会导致订单状态无法推进，后续会引发超时关单等问题，所以在稳定性上必须严格保证。

整个发货的操作，有失败的会立刻告警出来，当然这里会屏蔽一些正常的业务校验场景，否则告警太多就显得毫无意义。同时也基于订单目前现有的错误码大盘构建了发货的大盘，发货失败量，失败的原因通过大盘一看便知有没有问题。

3.3 业务感知

作为研发同学，无论是业务研发还是中间件研发，都需要对自己负责的系统和功能的使用情况比较了解。构建业务大盘就是一种非常好的能够实时感知业务情况的一种方式。

比如说在发货场景我们需要感知的数据有如下：

总发货量
各履约模式的发货量，现货 xxx，直发 xxx，虚拟 xxx
各场景的发货量，App xxx，商家后台 xxx，开放平台 xxx
发货承运商分布情况，顺丰 xxx ，京东 xxx
发货方式分布情况，上门取件，自主发货，普通履约（平台下运单）
……

3.4 改造收益

这次改造的收益如下：

统一发货接口
只有一个接口，支持所有的卖家发货场景
接入成本低，接入方式简单
统一发货协议，支持多运单多订单同时发货
基于履约模式做业务编排，新增订单类型无需改造
提升后续发货相关开发效率
完善业务大盘，错误码大盘

4 三阶段卖家发货

4.1 什么是业务身份

我们做平台化的业务，同时对多业务提供服务时，需要有标识能够区分每一次业务服务请求的身份，这样就可以提供差异化个性化的服务，我理解这就是业务身份。

就好比消费者去一家线下门店消费，商家会让消费者办会员卡，会员卡有不同的等级，比如黄金卡，铂金卡等等。消费者每次去店里消费都会带上这张卡，这张卡就是消费者的身份，商家也能根据这张卡来给消费者提供差异化的服务。

4.2履约模式下卖家发货面临的问题

在构建业务身份之前，我们是基于履约模式去处理差异化的业务流程。也并不是说非得抽业务身份，而是到了某个阶段，业务的复杂度不得不让你改变现有模型，说白了就是没办法支持多变的业务，就算能支持，改动带来的影响面比较大，对测试回归的范围比较广。所以我们需要反思以什么样的形式来解决复杂业务，同时又能支持后续业务的多变性，还能减少测试范围，这就是我们构建业务身份的根本原因。

上面说的可能有点抽象，下面通过一个具体的例子来说明下目前遇到的问题以及用业务身份如何解决这个问题，如何获得高扩展性。

在本文第四点基于履约视角的卖家发货中已经说明了最新的发货是基于履约模式来进行业务编排。直发和现货模式都是基于实物的履约模式，需要使用快递发货。但我们还有一种虚拟履约模式，虚拟履约是不需要快递发货，而是线上进行，比如月卡，游戏皮肤，票务（电子票）等等。

如下图所示：

在虚拟模式中的票务目前仅仅支持电子票的形式，在最新的需求中，需要支持实体票。实体票默认都是快递配送，如果购买时间临近演出开始的时间，那么快递配送在时间上肯定是不能满足要求，这个时候另一种方式出现了，它就是现场取票。

此时可以看下图，虚拟模式下又存在多种业务场景，当虚拟订单需要走快递配送的链路，现有基于履约模式的业务编排没办法支撑。如果不谈合理性，只实现需求的话只能在虚拟模式下再开一条新流程，处理快递配送的流程。但是快递配送相关的流程在直发和现货的模式下都是现成的，这样做后续维护成本和理解成本太高，这就是基于履约模式的发货目前面临的业务扩展问题。

4.3 业务身份如何破局，提高扩展性

如上图所示：底层能力不再跟履约模式进行一一绑定，而是基于业务场景进行了抽象。这样做的好处在于这些底层能力可以被复用，怎么复用就需要抽象出具体的业务身份。

举例说明：

现货通用业务身份对应的能力如下：
运单号校验需要
创建发货批次单不需要
优惠核销需要
状态机现货
现货App业务身份对应的能力如下：
运单号校验需要
创建发货批次单需要
优惠核销需要
状态机现货
虚拟通用业务身份对应的能力如下：
运单号校验不需要
创建发货批次单不需要
优惠核销不需要
状态机虚拟
虚拟快递业务身份对应的能力如下：
运单号校验需要
创建发货批次单不需要
优惠核销不需要
状态机虚拟快递

通过上面的例子我相信大家都看明白了业务身份的作用，结合业务抽象出业务身份，同时为业务身份绑定对应的能力，这样就能完全的复用底层能力。

当然，这里的重点是如何提取出对应的业务身份，业务身份是一个多维度聚合的一个结果，并不是随便编造出来就可以。以卖家发货的场景来分析，业务差异性体现在下面几个点上：

不同的端有不同的逻辑
这里的端指的是卖家发货时使用的系统，比如App，商家后台，开放平台对接等等。
不同的履约模式有不同的逻辑
履约模式目前已经细分完成，有直发，现货，定制，虚拟等等。

所以我们的业务身份就是对应的端+履约模式，对于没有差异性的可以定一个通用的业务身份，后面有差异性了再单独提取出来。比如通用现货，需要细分的那就是App现货。

上面这个维度组成的业务身份能满足大部分场景，还是有些场景无法满足，那就是虚拟订单走快递配送的场景。也就是说我只能识别出当前的业务身份是虚拟模式，但是无法识别出虚拟模式下是要走快递配送，还是现场取票，还是凭证发货。

为此，增加了第三个维度来组成业务身份，这样就能明确当前的业务身份需要做哪些事情。所以对于虚拟的业务身份就会有虚拟通用，虚拟快递发，虚拟现场取三个业务身份。

对业务身份来说，也是会随着业务而进行演变，也许以后将整个履约链路标准化，提供给多业务使用，这个时候业务身份中就会增加非常重要的一个维度：租户。

4.4 改造收益

4.4.1 高扩展性

高扩展性其实上面已经讲过了，通过业务身份编排的方式轻松的就支持了虚拟订单走快递配送的履约方式。根本不需要在之前很多逻辑里面加 if 进行强判断。

比如有个需求要对发货时子母件（一个运单多个包裹）的场景进行拦截，只在某一种履约模式下进行拦截。这个时候我们就可以新增一个子母件拦截的基础能力，分别是拦截和不拦截。

然后给需要拦截的业务身份配置上拦截，给不需要拦截的业务身份配置上不拦截，这样就只有指定的场景才会用到子母件拦截的能力。如果后面其他模式也要支持拦截，直接改配置就可以了，无需改动底层业务代码。

高扩展性的前提是有好的抽象和分层，发货整体业务架构如下图所示：

4.4.2 测试成本低

测试成本低主要体现在改动范围都是可控的，因为整个发货流程中都抽象出了具体的能力。比如说你改了A能力，A能力只作用在虚拟模式下，那么测试只需要回归虚拟模式的流程即可。

以上面说的子母件拦截的场景来讲，也只需要测试现货模式，而且老逻辑都不用看，因为是新增的能力点，完全不会影响老的业务逻辑。

或者说在业务的发展下，新出现了一个业务身份，但是这个业务身份对应的能力都是之前已经存在的能力，只不过是有些能力不需要，这个时候只需要改两个地方，一个是业务身份对应能力的配置，另一个是计算业务身份的逻辑，能够根据某些条件决策出当前请求是这个新的业务身份。这个时候测试只需要简单的验证下即可，底层能力都是已经在使用的，不同的点只在于编排。

无论是新增，还是修改，还是重新编排。都能很明确的知道当前调整的范围，这样测试的成本自然也就比较低。不再需要像以前一样，改动了几行代码，不清楚什么场景在使用，然后全部回归一遍。

5 未来展望

5.1 底层能力的持续完善

目前发货场景的底层能力数量不多，在某些场景还是会有简单的if判断逻辑。在目前看来这些场景还没有特别复杂，随着业务的发展和规则的变化，这些逻辑越来越复杂的时候，就需要继续去提取出原子级别的能力。

能力的提取和业务身份的抽象是个漫长的过程，不存在一成不变的情况，只存在慢慢演进和优化的过程。

5.2 业务身份的可视化编排

可视化编排在初期并不是重要的一环，随着底层能力越来越丰富，业务规则越来越多且变化频繁，此时研发侧能否快速交付就变得很重要。通过可视化编排，不用依赖代码改造和版本发布，就可以快速调整业务流程和新增一套完整的新流程。当然，这也需要有很多相应的机制来保证稳定性，毕竟代码变更是每次都经过一个迭代的测试才能发布，这种动态变更的也需要有相应的灰度机制才行。