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

2023-10-17 09:30

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

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

本文属得物技术原创,更多精彩文章请看:得物技术官网

未经得物技术许可严禁转载,否则依法追究法律责任!

这篇关于电商订单履约-卖家发货演化史的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/224462

相关文章

Vue2电商项目(二) Home模块的开发;(还需要补充js节流和防抖的回顾链接)

文章目录 一、Home模块拆分1. 三级联动组件TypeNav2. 其余组件 二、发送请求的准备工作1. axios的二次封装2. 统一管理接口API----跨域3. nprogress进度条 三、 vuex模块开发四、TypeNav三级联动组件开发1. 动态展示三级联动数据2. 三级联动 动态背景(1)、方式一:CSS样式(2)、方式二:JS 3. 控制二三级数据隐藏与显示--绑定styl

提升PrestaShop外贸电商网站安全的几款行业必备工具

提升PrestaShop外贸电商网站安全的几款行业必备工具 PrestaShop发展历程 PrestaShop是一款优秀且强大的外贸开源电商软件,我们开始使用PrestaShop始于2009年,那时PrestaShop还是0.9版本:界面清新,性能强悍,扩展友好等特性,既没有Magento的笨重,也没有ZenCart的古老,更没有OpenCart的脆弱,因此PrestaShop如雨后春笋,迅速

运营版开源代码 多语言跨境商城 跨境电商平台

默认中英双语 后台带翻译接口 支持133种语言自动翻译 支持多商户联盟 一键部署版本 伪静态+后台登陆后缀 源码下载:https://download.csdn.net/download/m0_66047725/89722389 更多资源下载:关注我。

基于Python的电商导购APP设计与实现

基于Python的电商导购APP设计与实现 Design and Implementation of an E-commerce Shopping Guide App based on Python 完整下载链接:基于Python的电商导购APP设计与实现 文章目录 基于Python的电商导购APP设计与实现摘要第一章 简介1.1 研究背景1.2 研究目的1.3 研究方法1.4 论文结

店匠科技携手Stripe共谋电商支付新篇章

在全球电商行业蓬勃发展的背景下,支付环节作为交易闭环的核心,其重要性日益凸显。随着消费者对支付体验要求的不断提高,以及跨境电商的迅猛发展,支付市场正经历着前所未有的变革与挑战。在这一充满机遇与竞争的领域,店匠科技(Shoplazza)凭借其创新的嵌入式支付解决方案—— Shoplazza Payments,成功在市场中占据了一席之地。 近日,在新加坡举办的 Stripe Tour 新加坡站 20

新一代实验分析引擎:驱动履约平台的数据决策

总第601篇 | 2024年第021篇 传统实验引擎基于单一实验单元、普通随机分组、大样本和个体独立性,适用于单边场景实验,但在多边场景中显得不足。此外,多边场景中溢出效应成为常态,进一步挑战了传统方法的适用性。针对这些挑战,本文提出了新方案可作为有用的指南,帮助实验平台建设者应对开发中的挑战,并采用不同方法确保实验的可靠性和高效性。 1. 引言 1.1 AB实验的发展:从单边场景到单边与多边

3-KYLIN订单例程

转:http://blog.itpub.net/30089851/viewspace-2122586/ 一.Hive订单数据仓库构建 1. 创建事实表并插入数据 DROP TABLE IF EXISTS default.fact_order ; create table default.fact_order (   time_key string,   product_key stri

探索API接口新篇章:深度解析各大电商平台商品详情数据接口

——在成长的路上,我们都是同行者。这篇关于API接口的文章,希望能帮助到您。期待与您继续分享更多API接口的知识,请记得关注Anzexi58哦! 在数字化浪潮的推动下,电子商务已成为全球经济的重要组成部分,而商品详情数据接口作为电商平台的“心脏”,不仅连接着商家与消费者,更是驱动个性化推荐、智能搜索、库存管理等核心功能的关键。本文旨在深入剖析当前主流电商平台(如淘宝、京东、亚马逊等)的商品

米壳AI:做跨境电商欧美市场必备工具--AI图片翻译!

在竞争激烈的欧美跨境电商领域,如何脱颖而出? 对于欧美市场的跨境电商从业者来说,语言和文化的差异常常是一大挑战。 但有了米壳 AI 这个强大的工具,问题便迎刃而解。是一个无需下载安装的网站,打开就能用,极其方便。 它支持批量上传产品图片一键翻译,无论是产品展示图上的详细说明,还是广告宣传图中的关键信息,都能快速、准确地翻译成目标市场的语言。 而且米壳 AI 支持翻译

尚品汇-延迟插件实现订单超时取消(四十五)

目录: (1)延迟插件封装 (2)基于延迟插件测试         如何保证消息幂等性? (3)改造订单service-order模块-实现订单超时取消 (1)延迟插件封装          把消息带过去:  在消息的重试发送消息的方法里封装:retrySendMsg (2)基于延迟插件测试 service-order模块  rabbit-util模块配置