共计 4698 个字符，预计需要花费 12 分钟才能阅读完成。
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 业务身份的可视化编排
可视化编排在初期并不是重要的一环，随着底层能力越来越丰盛，业务规定越来越多且变动频繁，此时研发侧是否疾速交付就变得很重要。通过可视化编排，不必依赖代码革新和版本公布，就能够疾速调整业务流程和新增一套残缺的新流程。当然，这也须要有很多相应的机制来保障稳定性，毕竟代码变更是每次都通过一个迭代的测试能力公布，这种动静变更的也须要有相应的灰度机制才行。
5.3 扩充业务身份的适用范围
业务身份目前只在卖家发货场景落地，在履约这边有其余很多平台化的能力，如何用平台化的能力去撑持下层多变的业务是外围诉求。一旦业务身份确定，那么在整个履约链路中，都能够基于业务身份来做整体的流程编排，做差异化的解决。
* 文 /YJH
本文属得物技术原创，更多精彩文章请看：得物技术官网
未经得物技术许可严禁转载，否则依法追究法律责任！
