背景
美团点评-境外度假事业部是酒旅事业群所属的四个事业部之一,主要业务是运营境外旅游产品,度假产品,购物优惠券,境外POI信息,对于境外旅游这种业务形态,美团点评是第一次尝试,我们从15年底开始建设整个旅游的供应链系统和交易系统,和竞对相比,我们起步晚,所以,我们必须快速的建立起来整个体系,在这个体系中,直连系统承担了上接供应商商品,下接订单的角色,实现链路的闭环。
从0到1
确立目标
大家都知道,在供应链中最重要的就是供应商把自己的产品录入到我们美团点评的系统中,通常这有两种实现方式,人工上单和系统对接。显然,我们需要后发制人,必须短时间铺大量的商品上去,而这两种方式中,系统对接比人工效率要高很多,所以我们的目标之一实现供应商商品对接功能
好了,现在我们产品有了,那么用户在美团点评下单之后,我们需要把订单信息同步给供应商,这样供应商才能给确认订单,然后给客人出票。这个过程也有两种方式,供应商的运营人员把我们系统中相同的订单在他们系统中重新复制一份,这就是人工搬单。还有一种就是系统对接,及我们直接通过接口把订单信息推送给供应商,这两种方式的效率和准确性方面,系统对接显然是最佳选择。
随着我们业务的发展,我们平台的商品越来越多,这个时候我们还要考虑是否分销,所以直连系统还要具备分销的功能
至此,我们确认了我们目标
- 商品&订单对接
- 分销产品
方案设计
前面说到,直连系统负责对接供应商的商品和订单数据的对接以及未来进行的分销,而在这其中有个问题,商品的数据是分为两部分的,及商品的基本信息和价格库存,所以我们需要对接的数据有商品基本信息,价格库存,订单数据。
对于商品基本信息,它的特征是相对比较固定,变化不频繁。我们可以选择主动的抓去供应商的数据,也可以选择让供应商推送,考虑到我们是平台,需要制定标准的数据格式。我们选择供应商主动推送的方式。
对于价格库存则恰恰相反,价格库存都是实时的变化,尤其对于机票,酒店这种库存要求比较高的商品,所以我们要保证价格库存能够及时的更新,保证数据的一致性。鉴于价格库存对于数据的实时性和一致性要求比较高,我们采取推拉结合的模式,及供应商主动推送+平台定时拉取
第三部分则是订单数据的同步,首先来解释下我们的下单流程,用户下单-支付-取消。在直连系统的流程中我们演化为用户下单-供应商占位-支付-供应商确认-取消-供应商取消,可以看到,直连系统中的订单流程是原有订单流程的延伸。这里说下为什么需要占位接口,对于供应商来说,一个供应商的产品往往是分销到多个平台,而且大部分供应商都没法做到硬分销(及划给某一个平台固定的库存,与之相对的为软分销,及多个平台共享一份库存),所以我们需要保证用户下单时候的库存是可用的,并且占位之后是要供应商来锁定该库存,避免用户在支付之后没有库存,造成退款。
综上,我们大致可以画出系统基本的模块功能
供应商接入API提供商品基本信息,价格库存,订单数据的对接标准,数据开放API负责产品的分销和共享,WEB站则是供应商接入的门户。
由于我们和供应商之间是http接口交互,所以对接口和网络的监控必不可少,监控只是发现问题,那么补偿则是解决问题,针对失败的请求,加入补偿队列,确保请求的最终可达。
接口限流,针对我们不同的供应商需要设置各个接口的最大请求频次,在调研了公司的限流系统之后,暂时没找到适合我们场景的限流系统,所以,这个我们自己开发了一套适合我们业务的限流系统。
WEB站
前面说过,直连系统的web站是供应商接入的门户,里面需要承担的功能有API文档展示,接入流程介绍,测试工具,以及系统和业务的监控,其中最主要的功能就是测试工具和实时监控
测试工具
在双方系统对接中,总有一个联调过程,及双方开发约定一个时间,然后测试接口,对于平台而言,对接的供应商有成千上万家,那么,每一个都需要我们联调的话,那么这个投入是非常巨大的,那么怎么能把联调这部分工作转移给供应商,就成为测试工具要解决的问题。
为此,我们开发了如下图的自动化测试流程,由平台发起对供应商的调用,请求参数可动态配置,供应商可以自定义,我们会记录一个订单完整的生命周期,以此来判断供应商是否通过了测试,如果通过测试,则可以直接切到线上。这样,减少了我们的联调时间,供应商接入效率和质量大大提高。
实时监控
业务监控是WEB所必须要实现的功能之一,实时的监控系统是确保线上业务正常运营的前提,要做到有问题立即能够感知,发现,处理。为此,我们采取了心跳机制和接口监控来实时的监控供应商系统状况。
心跳机制:我们与供应商系统之间建立每3分钟一次的心跳请求,如果失败,则频次改为1分钟1次,连续三次失败,关闭供应商交易开关,邮件短信通知供应商和负责的开发同学,订单转人工操作,做到及时发现问题,及时处理。
接口监控:针对供应商的各个接口请求频次,响应时间做实时监控,方便对于响应比较慢和频次比较高的接口及时优化
沙箱环境
大家都知道,互联网的系统基本都有线上和线下环境,和供应商系统对接也是一样,需要我们先在测试环境和供应商联调,然后在上线。这样的流程会有几个问题
测试环境可能不是很稳定,经常会有流程不同的问题
测试环境都有访问控制,比如白名单,各个供应商技术设施不同,可能经常需要添加白名单,对于国外供应商而言,这个问题更加突出
测试环境测试通过,上线之后可能因为配置等原因出现问题
对于这些问题,我们实现了一套沙箱环境,具体实现是共用一套线上代码和环境,数据库分为沙箱数据库和正式数据库,测试数据进入沙箱数据库,正常数据进入正式数据库。这样一来,测试的数据,环境配置,网络等都和线上一致,从沙箱环境切换线上环境不需要发布,只需要开关配置即可。
自此,供应商对接所有流程都在线上进行,可以极大的减少系统发布和提高对接效率
精益求精
上述结构可以满足业务发展的初期需求,随着业务拓展,系统面临这越来越多的问题和挑战,主要有以下几个方面
网络
我们接入的国外供应商越来越多,针对国外供应商http的优化显的格外重要,怎么缩短网络调用时间是一个新的挑战,我们经历了两个阶段来优化此问题
香港代理
香港代理是指,主服务在上海机房,在香港部署一个Gateway,http请求从香港机房发给国外供应商,上海机房和香港机房走RPC,这个链路相对于之前直接从上海机房发出http调用可以缩短50%以上的时间
长链接
香港代理上线初期,我们的海外供应商主要集中在亚洲,澳洲。随着更多供应商的接入,我们发现欧美供应商调用时间还是比较高,整体链路还是比较长,为此,我们的方案是:在供应商服务器以jar的形式部署我们的SDK,我们的SDK和香港接入点实现长轮询,香港接入点和我们的上海主服务通过RPC调用,这样,对于每次海外供应商接口的调用,可以省去三次握手。
数据一致性
随着我们的数据体量越来越大,之前供应商主动推送+平台定时拉去面临这严峻的考验,主要问题有
供应商推送不及时
定时拉去全量,数据太多
这两个问题都会导致数据的不一致,我们参考了兄弟团队的做法并且结合自身业务特点从以下几个纬度优化
拉取频次按照业务形态区分,比如门票等弱库存的商品拉取间隔放长,机酒等强库存的商品拉去间隔缩短
拉取频次按照商品洞箫区分,热点商品拉去拉取间隔缩短,非热点商品拉去拉取间隔放长
提前主动拉取,在用户进入下单页的时候主动拉取该商品的价格库存,等到用户下单
被动拉取,假如有订单因为价格库存的原因占位或者确认失败之后,拉取该商品的价格库存
通过以上优化,因为价格库存原因导致的订单失败大幅下降
供应商服务治理
前面说过,我们针对供应商服务采取了心跳机制来防止大规模的对接失败,但这样粒度太粗,还需要针对不同的case做特定的处理。同时,供应商的服务还需要供应商主动来做治理,我们可以采取监管,报警,惩罚的策略督促供应商。
接口失败的status标准化,针对不同的status采取不同的处理方式
细化报警&惩罚策略,24h接口异常的订单占比超过10%,关闭交易开关,邮件短信报警供应商
同一个商品24h之内连续下单异常两次,下架该商品
星辰大海
做任何一个项目或者系统,我们都会希望做好,做精,成为标杆,公司的标杆,行业的标杆。
对于在线旅游行业,大家共享的底层资源都是一样的,从地接社到B2B再到OTA,平台,我们的流程都是一致的,资源都是一致的,但是现在并没有统一的标准来约束,控制,分享这些资源,每个公司相对来说的都是垂直的,我们应该致力于行业的标准化,减少地接社到B2B, B2B到平台的多条链路,减轻供应商的对接成本。
对供应商来说,有分销权限,再加上共享资源池,则能快速的将产品发送到任何一个平台。
对平台来说,统一标准,所有流程可以配置化,极大的减少对接成本。