订单

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业务身份 对应的能力如下： 运单号校验 须要创立发货批次单 须要优惠核销 须要状态机 现货虚构通用业务身份 对应的能力如下： ...