订单中台服务产品架构

发表于2022-06-17|更新于2025-08-07|产品叨叨叨

|总字数:6.3k|阅读时长:18分钟|浏览量:|评论数:

零、引子

恰逢当下的公司在轰轰烈烈的搞订单服务化（伪），虽然并非中台形态的服务，但在重构的过程中，尽量使用中台化的思考，将整套服务扩展性变强一点，对企业未来需求的响应效率以及自己的工作压力降低总归是有一些帮助的。

一、订单中台服务定位

在任何涉及交易的业务体系中，订单均属于最为底层的核心系统。以前段时间极其火热的社区团购示例，供应链体系承担着货物从进入到履约给团长与客户的定位，客户运营侧承担着客户的留存、转化等产生GMV贡献的定位，商家侧承担着激活拉动商家更好的服务客户的定位；在这之中，订单、商品等看似并不能给业务挣钱（更高的arpu，更多的复访留存转化）或省钱（履约成本下降），但如果缺失订单，从客户侧的需求到供应链的满足的链路是中断的，同时，订单数据的缺失也会造成客户分层运营以及品类高效运作的数据支撑缺失。

在单一业务场景中（如交易双方、品类结构、交易类型、支付类型、交易流程、履约类型等简单且趋同），订单的系统非常简单，无需过度复杂的产品/系统设计，只要能够贴合业务将上下游的需求记录下来并且传递出去即可。但当业务复杂度上升后，随着不同交易方（F2B、B2C、C2B等），不同品类结构（实物商品、卡券类商品、服务类商品），不同交易形态（直售、租赁等），不同交易流程（先货后款、先款后货等）同时出现在一个商业主体时，其系统复杂度的提升会远大于多个新的单点业务的难度之和数倍。

所以一套高扩展性高前瞻性的合理的订单系统，在业务推进的过程中，可以更好的响应业务的拓新，做好企业前进的后勤保障。

我一直很喜欢乐高的理念，一系列不同组件通过多种合理的拼接可以变成多个不同的完备的展示品。同样的，现今各行各业都随着世界产业结构调整而进入组件化的供给方式，将各个产品的零部件拆解到最细粒度，分散到世界各地进行生产组装以谋求供应链成本的最优。相比于重线下长链条的实体产业都可以将一个完整的整体拆解后进行最优调配，以互联网技术的能力与实施方式，更容易实现以碎片化组件化来支撑随时变化与灵活的业务的底层系统。

二、三流分离的订单设计思想

在订单交易模型的思考一文中提及，现在的订单设计近乎一致的趋向于三流分离的设计，所谓三流即信息流-订单，资金流-支付结算，货物流-供应链。

电子商务的本质仍然是商务，商务则由若干次的交易构成。交易作为一个最细粒度的单元，其线上与线下的本质均是A用X置换了B的Y。

在原始社会里，人们以物易物，在这个时期不存在货币，不存在所谓的资金流，不存在文字，没有任何资料能够记录某一次交易，不存在信息流，仅存在极其简单的货物流，即把物品从双方手里换过去；

当人类进入文明时期后，开始出现文字，一次交易行为以文字记录下来，则构成了信息流，同样的，货物的交付的完结亦可以看成货物流的完成；

随着人类使用金银珠宝等构建完整的货币体系，标定每一样东西的价值，以物易物逐渐的被以“钱”易物取代，资金流开始出现。

随着社会的不断进步，货币从最基本的金银贝壳等与银票逐渐细化出现信用额度、不动产资产、股票期权证券等，商品也从实体商品不断分化出虚拟卡券、服务、知识、权益等，履约也开始从面对面换东西发展出镖局再到现在的各种长距离快递、物流等等。交易的形态逐渐饱满，但交易的本质从未发生过变化，即约定并记录一次交易，支付交易应付的成本，获得交易应得的内容物。

在产品与系统设计中，三流分离的设计思路可以更好的帮助我们将一次交易所需要的复杂的长链条的系统进行相对独立的多系统职责拆分，以更好的对业务变化进行响应；帮助产品研发体系的从业者更结构化的思考一次业务需求的合理的解决方案。

（对于从原始社会发展到有货币体系的历史，仅为通过资料获取，或许与严格的历史相悖，敬请历史学家们谅解。文中引入这些仅希望通过这些例子更直白的阐述三流的定义）

三、信息分层

1、概述

订单作为最底层的核心系统，其承接与依赖的上下游非常之多，举例如支付、供应链、商品、价格、客户等。如果将这些所有信息一股脑的全都扔到订单的统一数据中，在后续的业务需求变动的时候，极其容易出现原有订单的信息层级混乱，新的需求支持成本高，变动起来要考虑众多的历史数据，清洗成本高等诸多问题。

以乐高的思维看订单，一个订单包含的信息是存在主次、扩展关系的。在此先进行声明一下，所谓的订单信息分层，并非研发的DB设计，而更多的是以业务视角对订单的信息进行归类和层级划分。

01-订单信息分层

基于订单的定位与特性，对订单的信息进行了两个大层级的拆解，即订单维度的信息，与订单内所交易物维度的信息。

2、订单维度

将订单这件事儿进行极致的抽象去看，订单的本质就是A与B发生了一次交易。至于交易了什么，交易了多少钱，怎么给的钱，东西怎么交付的，还有没有什么额外的约定等等一系列的东西，其实都是围绕着这一次交易的完善性的信息。

对于订单维度最核心的也是最不能去掉的，即订单基础信息，至少要包括什么时间交易、谁和谁交易的。

基于订单的基本信息的维度进行扩展，从上下游系统获取的一些基础信息，由于部分信息属于变动的（如客户年龄等），在订单层面如有需求可以进行下单一刻的快照冗余，这些信息围绕着订单进行扩展记录。大致分为以下几个类型：

交易双方信息，如用户类型（个人、企业/组织）等；
营销活动类的信息，包括订单命中了什么活动，商品命中了什么减价机制，用了什么优惠券等；
履约的基础信息，包括预期收货日期、收货地址、下单时的履约promise等
订单的附加信息，如订单备注等；

以上几个类型，通过其他系统获取后并不会频繁的与上下游系统交互进行变动，而接下来的两个类型，则会随着订单的支付、履约频繁变动，并随之影响订单的状态流转，同时随之透传给到用户端进行信息展示。

支付信息，订单的支付行为有极多种可能性；从形式上看在线支付、线下现金支付、大额对公转账等，从时序上先款后货、先货后款，从次数上单次支付、多次支付；而对于标准的在线支付，其对于数据的要求与逻辑，相比于订单来讲也是相对复杂且独立的。因此，从订单的视角看，不对支付本身的业务逻辑与系统逻辑做干预，仅将支付信息（成功时间+金额+渠道等）作为订单的扩展信息记录，影响订单的状态及流程变化。由于多次支付与合并付款的存在，支付信息与交易信息通常会存在N:N的关系。
履约信息，同样的，履约行为也存在极多种可能性；供应链的涉线下业务的复杂性，在其标准化与信息化的程度上甚至低于支付；同时出于客户端对用户信息友好展示的诉求，订单必须能够找到与其相关的完整履约流程信息（如CDC出库、转运、RDC入库、分包、派送等），这些信息对于订单本身是无用且非标的。因此，从订单的视角看，仅将履约的核心节点信息（当前状态时间+节点情况等）作为订单的扩展信息记录，影响订单的状态及流程变化。同样的，由于多次履约及合并履约的存在，履约信息与交易信息通常也会存在N:N的关系。

通过对上述两类信息的存储，结合订单自身的状态控制能力，可以得出某一订单的全周期的状态，如下单成功、支付成功、待出库、待收货、已完成等，此类信息作为单独的与订单相关的数据储存记录。同时，订单的状态存在与外部系统交互的需求（如ERP、CRM等），也存在在客户端对用户做友好展示以及交互操作的需求（如操作确认收货），订单状态信息应该对三方的核心节点变动与订单全量的状态节点进行记录与管理，并管理与上下游协同系统的状态管理与维护。

最后，在非自营交易体系内，各三方商家的订单均由平台交易系统进行统一的系统支持，商家存在其自有订单的查看与管理需求，此外出于平台的数据统计需求，以及数据权限、操作权限等管理需求，针对各订单的商家归属维度的信息记录也是一个相对独立的信息板块。

3、订单交易内容维度

由于订单基础信息仅记录了订单维度的内容，对该订单交易的内容并未做记录处理，在订单信息维度之上，额外对订单交易交易内容（后称order_iterm=OI）进行信息记录，包含OI基础信息，如名称、类型、图片等。

同样的，OI本身的信息仅对内容做基础的记录，对于OI的业务信息的记录，继续进行扩展记录，分为如下几个类型：

OI控制维度，即该商品可能影响支付方式或履约方式的信息，如股票、理财等不允许通过信用卡支付的（影响支付），如特殊品不允许通过快递寄送的（影响供应链），刀具需要前置身份证校验才可快递的（影响供应链）等；
OI价格信息，针对各OI明细的价格信息，包括应收价格、应收金额、实收价格（支付后分摊）等；
OI货主信息，针对多货主的业务形态下，各商品的货主信息的记录；
OI状态信息，针对拆分履约或拆分支付的订单，对各OI的状态的记录；

上述几个类型在通过其他系统获取后并不会频繁的与上下游系统交互进行变动，而履约信息则会履约频繁变动，并随之影响订单的状态流转，同时随之透传给到用户端进行信息展示。

（电商场景中，并不会频繁的出现针对订单内的OI进行独立支付，因此不对OI的支付信息进行信息层级的拆分，在其他场景交易形态下，如有需求，同样可对OI的支付进行信息维度拆分)

针对OI的履约信息与针对订单的履约信息一致，OI同样需要能够找到与其相关的完整履约流程信息（如CDC出库、转运、RDC入库、分包、派送等），同时这些信息对于OI本身是无用且非标的。因此同样仅将履约的核心节点信息（当前状态时间+节点情况等）作为OI的扩展信息记录，影响OI的状态及流程变化。

在部分极特殊场景下，会存在多个OI一起履约与同一OI多次履约的业务需求，在信息层级的设计上，支持N:N的关系。但如此类需求发生极少，可通过其他方式解决，建议在上层业务应用通过隐藏界面交互或其他技术方式禁止此类操作，以简化整体系统逻辑。

三、能力组件构成

1、概述

上述仅对订单的各信息进行了描述，订单本质上是一个连接上下游的流程性系统，通过其高效灵活的能力，承接各类上游的业务特性，响应适配下游的各项要求。

02-订单能力组件

2、订单业务逻辑

在订单服务中，通常存在两套核心能力，其一是业务逻辑的服务，其二是调度算法的能力。业务逻辑对订单本身的常见逻辑做高灵活度的能力支持，如流程引擎，算价引擎，订单处理、订单校验服务，各类日志快照等基础能力。

1）流程引擎

对于一个流程型系统来讲，订单内部的各项流程虽然不像审批流那样变动灵活，但每一个流程的复杂度都远超审批流（通过、驳回、加签、驳回至xx节点、会签等），且订单的核心即为控制各流程节点的变动响应及配合。

通常意义上，订单内部有一整套完备的可能多于目前业务的状态集合，同时拥有一套完备的上下游节点的状态映射集合，拥有一套面向客户端的友好展示的状态集合。

通过对不同的包括但不限于订单来源、支付方式、履约方式、商品类型、货主等条件，灵活的调配各状态的变化以及调整流程的先后顺序以达成对不同类型的订单的支持。

对于订单服务的业务逻辑来讲，流程引擎是最重要也是最复杂的一环。

2）算价引擎

在简易业务模型下，算价引擎通常作为一个极简单的工具存在。但当业务加入特殊价格（年框合同、长期协议价格等），各类繁杂的营销活动（定金膨胀、定向红包、阶梯折扣等）后，以及增加了配件、服务等非标准商品的订单后，需要一套标准化的能力来对各类价格进行能够还原业务的精准计算。

3）订单处理与订单校验

通常意义上，订单层极少会出现订单合并的情况，绝大多数情况为多订单在履约环节进行合并履约；相比之下，订单拆分则较为常见，在出现了同一订单不同货主、不同履约方式、不同履约仓等情况时，如订单受平台运营机制的要求，需要在下单后对订单进行拆分后，再同上下游进行交互。

订单校验则出现在订单的各个环节，通常意义上出现最多的是在创建订单一刻，由外部上下游系统与订单本身联合生效；举例如风险客户无法进行下单的判断由风控系统提供校验，该地区过于偏远无法进行履约无法下单由经营区域（GIS）或供应链体系提供校验；其他如数据是否齐全以及一些其他系统无法提供或处理的下单限制，由订单本身提供规则并进行校验；两者共同生效对订单流转过程做校验与拦截。

4）快照/日志

由于业务的特殊性，订单会存在大量的快照，如下单一刻商品的描述，价格等；同时，订单作为客户资产的一部分，每次状态的变动（如订单每次被人为操作或系统触发所导致的状态、信息等变化）均应有相应的日志记录；以及作为最核心保密的数据之一，浏览、查看、截图、复制等涉密操作，均应有对应的行为日志记录。

2、统一履约中心

对于任何一个业务系统来讲，能够支持业务仅仅是第一步，进一步讲，需要通过技术的能力对整体业务进行效率的提升。

在订单服务中，对于极简单业务模型，如商品没有多货主、不存在多个仓、物流只能选择指定的某一个时，履约的环节相对单一，不需要系统帮助业务进行效率优化。

而当业务模型进入复杂化后，对于一次交易，其履约的过程应该由哪个仓选用哪个履约方式通过哪个货主的商品进行履约，不同的组合会极大的影响成本，在结合销量、库存、履约成本、货主有无额外加权等条件下，对每一次订单进行全局最优解的算法调度能力，即是订单中台服务中更容易产生量化价值的一环。

3、上下游系统网关

在不同类型的订单流程中，有可能会存在调用不同的支付方式，使用不同的履约方式的需求。

通常来讲，这项工作往往由支付清算系统与供应链系统来支持，即订单接入统一的支付清算与供应链系统，由其进行对应的分发。

但当订单与上下游解耦并不是很清晰时，又或者是有诸多三方渠道（如托管给旅行OTA、大客户内部商城等）存在时，订单亦可直接对接第三方的完备系统来达成业务流程与数据的记录，但随之而来的就是支付与履约的逻辑与数据，完全由第三方进行处理直接对接回订单，那么这时就需要订单自身具备与更多的支付清算、供应链做对接的能力。

4、支撑系统

对于订单来讲，一个订单的信息一定会包括用户、商品、价格等；同时在一个订单的运转过程中，无论是超时自动关闭的脚本、亦或是上下游系统交互的消息，均应该有对应的支撑系统如脚本服务、消息服务等进行服务的提供。

5、对外能力

订单作为底层系统，需要对外不断的输出能力以满足各系统的需求；常见的如下单接口（自建/三方商城，协同系统）创建订单，查询订单的能力、修改与删除订单的能力，以及订单变动的消息通知等。

四、常见状态流

1、先款后货

03-先款后货

对于行业中最常见的现货后款，其最基本的逻辑即创建订单→支付→履约→完成。在其中通过与支付清算的交互完成资金流的数据，通过与供应链的交互获得履约的数据。

2、先货后款

04-先货后款

与前者相同的是通过与支付清算的交互完成资金流的数据，通过与供应链的交互获得履约的数据。但在创建订单前，需要额外通过用户体系/信用体系等能够验证客户是否被允许未支付先行使用商品的权限校验。

五、订单中台实例

前文提到了，随着社会的逐步发展，交易开始呈现出各式各样的模式，对于不同交易双方，不同商品类型，不同交易场景，不同履约方式等的组合，会出现不同种类型的订单。以阿里集团示例：

（以下可能存在错误，请勿偏听偏信）

交易双方	交易商品	物流类型	业务形态
F2B	实体、卡券、服务、权益等	标准物流、即时达、无物流	阿里巴巴
F2C/B2C	卡券	无物流	淘票票
F2C/B2C	实体、卡券、服务、权益等（出行品类）	标准物流、即时达、无物流	飞猪
F2C/B2C	实体、卡券、服务、权益等（综合品类）	标准物流、即时达、无物流	淘宝/天猫
C2C	任意	任意	闲鱼
B2C	实体（以餐饮类居多）	即时达	饿了么
F2C	实体、卡券、服务、权益等	标准物流、即时达、无物流	淘特
F2F/F2B/F2C	服务、权益（云服务）	无物流	阿里云

在阿里集团的交易业务内，综合了各种交易双方，结合各种交易商品，各类物流类型的业务，分散在不同的BG与BU内，但整体上均可以使用一套订单系统进行全面的系统提供（阿里巴巴应该是尚未接入）。

对于飞猪与淘系，在交易双方、商品、物流均一致的情况下，仍以BG区分，有另一个原因是其商品供给背后的供应链逻辑差异极大，以订单视角看扔趋同。（在淘宝中依旧可以发现大量的飞猪的商品）

影响订单的元素包括非常多，如果将所有元素的内容排列组合之后有上万种可能性，在此仅对各元素做简要描述，不进行排列组合。

1）交易双方

交易双方	释义	类举
F2F	工厂卖给工厂	工厂与工厂的大规模原材料采购
F2B	工厂卖给渠道	制造业厂商销售给下游经销商
F2C	工厂直接卖给顾客	淘特、拼多多
B2F	渠道卖给工厂	商家整体旧货回收给到工厂报废
B2B	渠道卖给渠道	制造业厂经销商分销给到下游渠道
B2C	商家卖给个人	淘宝、京东
C2F	个人卖给工厂	暂未发现此类场景
C2B	个人卖给商家	爱回收
C2C	个人卖给个人	闲鱼、转转

2）交易形态

形态	释义
买卖	买与卖的资产与货权的转移
租赁	货权不进行转移，一定时间内使用权进行转移，会涉及押金、租金、赔付等多种支付内容

3）交易选购到履约过程

选购→履约过程	业务形态
Online to Online	电商
Online to Offline	团购、到店场景
Offline to Online	线下交钱报名线上使用
Offline to Offline	商超线下行为线上信息化

4）商品类型

商品类型	示例
实体商品	3C、服饰等
储值	水电费等直接充值到账的
卡券	电话卡等需要用码、卡密等需核销的
服务	安装、教育等
权益	会员、保险等
资产	股票、理财、黄金