1 背景

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

发货的事务特点：

• B端事务，功用要求不高，由于存在批量发货的场景。
• 发货时刻比较涣散，所以并发量不大。
• 事务杂乱，涉及到N种订单类型的发货，不同的订单类型有着不同的事务规矩。

跟着公司事务的开展，订单类型的增多，没有进行笼统的发货逻辑跟着迭代的推动难免会显得落后。当然，在迭代的进程中，也一直在优化，一直在演进，正所谓没有最好，只要契合当时事务现状的最合理。

2 一阶段卖家发货

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

有这么多发货接口也是咱们渠道的事务特性决议的，现货便是卖家发货到渠道，直发便是卖家发货到买家，不同的事务有不同的流程。除了接口多这个问题，另一个问题是逻辑涣散，每个接口都是独立的逻辑，许多重复代码的出现极大地添加了保护的本钱。

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

• 参数校验
• 一些事务校验，比方订单状况，发货镇定期等
• 核销卖家优惠
• 推状况机
• 订单数据修改保存
• 播送发货音讯
• 下发入库单
• 订阅物流轨道
• ……

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

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

1. 对外接口多，难以保护
2. 发货事务跟订单类型强绑定
3. 内部逻辑涣散，无事务全貌
4. 全体功用误差

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 事务身份的可视化编列

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

5.3 扩展事务身份的适用规模

事务身份现在只在卖家发货场景落地，在履约这边有其他许多渠道化的才能，怎么用渠道化的才能去支撑上层多变的事务是核心诉求。一旦事务身份确定，那么在整个履约链路中，都可以依据事务身份来做全体的流程编列，做差异化的处理。

*文/YJH

本文属得物技能原创，更多精彩文章请看：得物技能官网

未经得物技能答应禁止转载，不然依法追究法律责任！