在线旅游OTA本质是用技术手段提高旅游供应链的效率，通过接入各种供应商，将不同产品组合，加价来售卖来获取利润。从资源角度看，需要大量接入供应商来扩充产品线。
在途牛我们用1年时间搭建和完善了供应商对接系统。这张图，供应商系统提供资源标准化的服务，对外提供查询，价格校验，下单等业务，
查询引擎和订单通过接口来获取供应商的资源，不关心具体供应商api的细节。
image.png
如果是自己掌控资源，那其实是不需要对接系统的，或者只接入一个供应商，也不需要对接系统。
对接系统存在的背景是，不管在哪个行业，多个供应商系统必然会存在差异，因为系统是人设计，同样的东西不同的人会有不同的先别想法，比如航班这个名词，有的技术人员用airplane，有的用flight，很难强迫大家用一样的。
对接系统的目的是解决这些差异。
拿途牛国际机票举例子，机票是一个商品，前端呈现的各种数据都来自供应商，比如航班号，机型，价格，燃油费。
image.png
除了用户需要的数据必然提供，也会出现有的数据有些供应商有，而有些没有，比如有的系统会返回转机的城市，有的不会，又比如新接的一批供应商支持航班准确率，这种情况只需要新增字段做加法即可，这是简单的情况。
复杂的情况是，类似的功能，不同供应商接口有不同的流程。
下面举拿我们做途牛机票碰到的问题说明。
机票预订流程分先查询后价格校验，这个和淘宝里买东西类似，但是淘宝库存在自己系统，可以认为只传入商品id，价格校验接口就能够找到对应的商品。
机票校验的情况不一样，虽然都是需要查询接口返回的信息，但是有的供应商需要行程信息，有的只需要传入航班号，还有的需要传入一些自己的参数，随着接入新供应商，谁也不知道后面会增加什么参数，这会有以下问题：
1.外部调用不同供应商要传入不同信息，接入新供应商前端需要改动。
2.需要前端保存的字段过多，影响性能，特别是现在移动端4g的情况。
资源对接系统有义务屏蔽掉这些差异，提供一套简单而同一的流程，在途牛我们是通过一个rbdkey(rebooking key预订标识)的机制来实现.
rbdkey机制简单说明如下：
1.查询航班结果返回rbdkey字段
2.验价接口必须回传查询对象rbdkey字段
3.查询接口将不同供应商验价需要的字段按一定格式放到rbdkey字段
不同供应商rbdkey：
image.png
下面是机票预订时序图：
image.png
可以看到：
1 不同的接口有不同的rbdkey。
2 当前接口的rbdkey是由上一个接口生成，验价依赖查询，下单依赖验价。
这点很好理解，因为一个购买流程越往后需要的信息越多，比如查询只需要查询条件，下单的时候就需要购买人信息等，所以不同预订环节rbdkey是会变化。
这个是标准化流程简单介绍，标准化带来了便利的同时也有带来了出错的可能，因为全部供应商资源都通过这一个模块来控制，实际应用中还需要从性能和防出错的角度做一些优化和校验，这个后面会介绍。
网友评论