电商订单对接系列-第1章-整体设计

背景

电商行业在处理订单的业务时，初创一般是直接通过电商后台导出表格，然后根据其来跟进进销存。在单量到了一定规模时，业务场景会变得复杂，如促销套餐，拆单，合单等，一般会购买市面上的产品来做订单管理。随着公司业务越做越大，业务越来越复杂，如大数据分析，定制化报表，业务二开等，这个时候如果还是依赖外采系统，在新功能研发上会比较被动，沟通成本较大，效率也较低，这个时候企业可能会选择自研对接电商订单。

对接流程

对接电商平台订单大致有以下几个步骤，此处暂不展开细说

1.申请开放平台账号,提供企业资料,并完成认证

2.创建应用,提交审核（审核通过后会有appKey和appSecret，用于对接其开放接口）

3.店铺授权（企业在一个电商平台中可能有多个店铺，需要授权获得token，然后每个token只能获取其对应店铺的订单数据）

4.充值，购买服务器等（部分电商要求需要入云，故需要购买服务器，这个后面细说）

5.申请sdk包并下载（一般平台都有sdk可供使用，大大减少开发量）

6.编码

7.调试

8.上线

对接设计

部分平台要求入云，即需要购买其指定的服务器，在服务器上部署一个应用，专用于与其开发API交互，然后暴露接口再与业务系统进行订单同步。例如淘宝，京东，拼多多，其中拼多多不强制入云。有赞，抖店属于无容器对接，即在业务系统中直接与其开放API进行交互。一般订单同步有2种方式，

主动拉取：我们的系统主动请求开放API获取到订单列表进行同步，优点：我们系统主动发起，比较灵活，可以自行实现任务调度，失败重试，人工补偿等机制，可以保证不会漏单；缺点：会有不必要的拉取，效率较低。

消息通知：订单发生变更（如完成支付，退款等）平台会主动发消息通知到我们的系统（通过http或者长连接的方式等）进行同步，消息通知最大的优点是实时性高，有消息通知，我们可以降低主动拉取的频率。缺点：不可控，平台有可能会丢失消息，网络异常也会丢失消息。

开发中这两种方式都要对接。消息通知及时把变更的订单通知给我们完成同步，另外我们定时主动去拉取订单，防止出现漏单

下图是以淘宝为例子的对接设计示意图，无容器的对接也类似但更简单，砍掉“云服务器”的部分即可

如图，主要有4个交互

1. 云应用主动调用开放API获取订单列表

2. 开放API把订单变更消息通知到云应用

3. 业务系统主动调用云应用的接口获取订单列表

4.在第2步后，可以通过编写把变更消息通知到业务系统（并非所有云应用都可以以通知方式给到业务系统，具体要看平台的规定）

总结

本文主要介绍电商订单的对接大致流程以及整体的交互设计，这里面有很多很多的细节都还没有讲。如主动拉取订单的任务调度、失败重试机制，授权店铺token管理，token刷新等。这些内容将在下一章介绍