vivo 全球商城：从 0 到 1 代销业务的融合之路

代销是 vivo 商城已经落地的成熟业务，本文提供给各位读者 vivo 商城代销业务中两个异构系统业务融合的对接经验和架构思路。

1、业务背景

近两年，内销商城业务的发展十分迅速，vivo 商城系统的架构也完成了从单体往分布式的演进。咱们在 vivo 商城服务化方向作了不少的努力，基础服务的能力逐渐沉淀下来。

2019年咱们也开始在产品功能上玩起了多元化的营销业务。目前手机品类还是咱们销售的主力，可是非手机品类的sku单品数量仍是不多，巧妇难为无米之炊。

为了解决非手机品类商品丰富度问题，运营考虑和电商平台进行合做，但愿用代销的方式为商城扩充更多的非手机类商品品类。

先跟你们解释下“采销”和“代销”的区别，简单来说就是一个货权归属的问题，采销是买货到咱们仓库进行售卖，可自由订价；代销是货权归属于平台方，也就是货还放在对方的仓库，用“以销定采”的方式进行售卖，有利润空间，可是自主订价受限。

因此代销业务一开始就带着明确的目标出发了，咱们但愿经过接入其余的电商平台可以作到如下几点：

• 改变商品品类匮乏的现状，品类变多能进一步丰富促销玩法；
• 提高运营效率，解决代销类商品从选品到商城上架周期过长的痛点。

2、平台选择

一开始选择了几个平台方，为了提高选择效率，咱们先对平台方定了几个重要的参考指标，目的是要能过滤存在对接风险的平台。

对接参考指标：

• 【文档清晰】必需要有完整的API文档，文档逻辑要清晰，不能模棱两可；
• 【接口完备】至少具有知足全流程的数据同步接口（能实现数据的全量和增量）、异步通知（商品变动、订单状态流转等异步变动）等；
• 【商品模型】提供的商品模型要结构化。例：遇到sku信息采用内嵌html的方式，尝试用Demo预研后，效果不好；
• 【成功案例】这个具备很是重要的参考做用。通常在对方的站点上都会宣传一些成功案例，能够去体验下，由于很大可能最终接入的效果会和他们同样；
• 【沟通机制】健全的沟通机制也很重要（刚开始咱们没有重点考虑，致使对接过程沟通仍是不太通畅）。

可是参考指标只能做为一个筛选器排除不能对接的。剩下的平台方，须要咱们从技术和产品的角度进行深度的调研分析，预研期间也主动和各个平台方电话沟通了几回，最终咱们挑了一个各个方面都比较合适的候选人“网易严选”。

3、挑战

此次对接任务是经过对方提供的API接口，把他们的商品同步过来在咱们商城进行售卖。

咱们要求的是商城能正常地展现，用户能正常的下单并支付，同时支持逆向的用户取消订单，退款退货等等。

可是外部系统的对接存在不少的风险，尤为是非公司的第三方异构系统，并且对接的是包含商品、订单的全流程，咱们要面对不少的挑战。

1. 未知挑战

• 首先要考虑商品数据能不能完美地融合进来？
• 其次订单的正逆向流程能不能打通？
• 对方是否有环境可以测试验证？生产环境接入有没有过多的限制？安全性如何保证？
• 对方能不能及时、准确地解决咱们遇到的问题？

2. 前期预研

为了保证全流程完整接入的可控，咱们先和对方沟通了测试环境配置，尝试调通他们的接口。

紧接着咱们开发人员分红了两批，一批尝试经过手工组装字段把对方商品接入vivo商城，一批预研订单正逆向的全流程，此次咱们尝试接入的目的很明确“打通全流程”。

3. 预研结果

最终经过使用 Demo 拉取对方报文，手工组装数据，快速试错，实验结果和前期预研的同样，经过实践证实全流程确实可行，链路能打通！实验结果让你们信心大增，也预示着咱们能够整装待发，正式踏上代销系统的架构之路了。

4、代销业务的设计

1. 开篇

在正式设计以前，咱们须要对新系统有点畅想，由于咱们不只仅只是完成此次对接的任务，咱们更但愿它拥有更抽象的业务功能，具有必定的扩展能力。

架构代销平台的意义：

• 对接外部系统，提高咱们自身的系统架构、设计的能力；
• 填补代销的空白，将来咱们但愿这个平台可以达到快速对接的目的；
• 积累必定的经验，将来定制咱们本身的标准API，低门槛接入品质好的第三方。

2. 系统设计

咱们把系统简单地归类，划分红了三部分，从左往右分别是平台方 → 代销平台 → 商城内部系统。

代销系统总体的设计的思路有点相似API网关，但在细节方面又有不少不一样，代销系统的设计仍是总体偏业务实现，也提供了额外的平台方信息的查询服务供内部系统调用。

2.1 平台方系统

对咱们来讲是个黑盒，他们的系统设计、数据交互咱们是没法得知的，不过若是仔细研读文档的话，也能从他们提供的API中窥探一二，可是相比于对方的设计咱们更须要把精力花在和他们的沟通和环境联调上。

2.2 代销平台

是此次设计的重点，它承接着外部和内部系统，是系统交互的重要纽带。目前摆在咱们面前的仍是一张白纸，咱们须要先梳理下全部的基础功能，把它的框架先搭建出来。

为此，咱们制定了简单的设计原则“无侵入，对内屏蔽掉底层适配的细节，关注服务自己，并具有必定的业务抽象和扩展能力”。而后在此设计原则基础上咱们作以下比较精心的设计：

模块化设计

对接严选以后，再对接其它平台方的话。咱们但愿各个平台分红模块化进行对接。保证各接入方之间业务彻底隔离，互不侵入。

可以作到可插拔，如遇到合做终止的状况，能以最小的成本关闭对接通道。

路由层

• 商城内部系统发过来的报文/请求能识别并路由到对应的平台模块中处理。
• 平台方回调的报文可以准确解析并路由到模块中去。

适配层

• 来自于适配模式（Adapter Pattern），适配能力是整个系统横向的核心能力。
• 模块化设计以后，各个对接的平台都会具有独立的适配层。
• 商城 ↔ 平台方的商品和订单维度的字段映射。
• 持久化双方的主键映射关系，如：<vivoSpuId, YxSpuId>，<vivoOrderId, YxOrderId>。

服务暴露

• 提供映射关系查询，如：商品spuId、订单关联关系映射。
• 提供对帐信息查询。
• 提供平台方冗余信息查询，如：平台方更丰富的商品信息。

统一回调

• 开放外网访问接口，提供接口给平台方进行消息的异步回调。
• 创建访问白名单，接收并将消息经过路由层分发到各平台模块进行处理。
• 异步回调的消息包含：商品信息变动、库存预警&校准、订单状态流转等。

统一配置

• 利用配置中心统一管理各平台方对接帐号、秘钥等信息。
• 系统监控指标阈值、告警、开关等。

横向能力

• 接口调用异常监控、业务异常告警等。
• HTTP底层通讯服务。

2.3 内部系统

2.3.1 商品中心

【高可用】

以前对外提供的都是高QPS的只读Dubbo接口，此次要开Dubbo写接口提供给代销系统来建立商品。

了解接口设计的小伙伴都比较了解，写接口最主要的是保证事务的同时要能作到防刷防重。为此咱们在写接口上加了统一验签（内部系统弱校验）和接口幂等性设计。

【接口设计】

你们平时在浏览电商网站的时候，商详页呈现出来的内容是十分丰富的，这也间接说明了商品的模型自己仍是比较复杂的，因此在设计商品写接口的时候，开发内部产生了争论，讨论出了两个方案。

方案一：部分开发认为应该按如今的商品模型，把接口打散，代销平台对接多个写接口，好处是局部更新比较方便，也避免一次性提交一个大事务；

方案二：另外一波同窗认为就应该是一个接口，不然会出现接口散乱、乱序的状况。

最终咱们仍是采纳一次性提交的方案二，虽然会有大事务的风险，可是能够经过代码层面来缓解，并且架构设计自己就是一种权衡，设计接口的时候仍是要多站在调用方的角度，对方确定不会但愿服务方的接口是散乱、无序的，这会增长调用和维护的成本。

2.3.2 订单中心

【正逆向的流程】

订单的难题最主要仍是双方流程的融合，因此咱们针对代销逻辑作了部分的流程改造。

这边只给你们举一个下单的例子，严选提供的建立订单API实际上包含的是下单+支付两个动做，为了适配他们的流程，咱们作了点改造。

当用户在商城下完订单以后，代销系统仅对接严选作库存和配送区域的校验，确保订单能下成功。等用户在商城侧支付完成后，代销再次发起建立订单的请求给到严选。若是遇到建立异常（从数据上看不多几乎没有），咱们也会有自动的取消流程。

3. 严选对接逻辑

上面的设计肯定了各个模块的功能，划分了业务的边界，让咱们看清了总体的骨架和脉络。可是咱们还须要画一张切实可行的调用关系图，让整块逻辑立体丰满起来，最终让每一个开发都知道此次网易严选该怎么去对接。

5、呈现效果

代销商品覆盖了官网商城列表页、活动频道页、选购页，展现效果以下：

 

6、展望将来

咱们在前期也遇到有些品类比较好的平台方，可是因为技术缘由没法和咱们系统完成对接，也挺遗憾的。将来咱们但愿代销平台也能本身制定一套API标准，对方按照咱们的标准，本身开发接口把数据传给咱们就好了，这样就少了不少沟通和接入的成本。

做者：vivo官网商城开发团队