两个系统交互方式有几种_服务端(后端)| 大型分布式系统协作中复杂数据结构定义方式解析...

3238dd1ba2e37d7597bfca5ca2abca81.png

在旅游系统的各种实践中,各品类资源描述方式的差异化给系统的抽象带来了很大困难,从采购、到库存、到销售的整个链路上,每个环节都要有大量的代码去解析或封装各种类型资源和产品的代码逻辑,而这些数据结构,绝大部分是本系统用不到的,只是为了传递给下游系统,所以当一个系统改动了一个字段后,各个环节的系统都要跟着改一遍,这在系统设计、开发和维护上,都带来了很多不必要的麻烦,增加了复杂度,如何减少甚至屏蔽这类困扰,降低成本,提高系统的稳定性,是一个需要重视的课题。

01

现状分析

目前,途牛涵盖了机票、酒店、门票、跟团、用车、签证、游轮等大小几十种旅游资源类型,由于属性、特点和售卖形式的不同,描述这些资源的数据结构差异也非常大。

以机票和酒店为例,数据结构分别如下(注:这只是一小部分,真实数据字段的数量是下图的两倍甚至三倍):

26c540b13dc5f90d86a22dff43ab958c.png

图:机票数据结构

085dba72208235d6a764d221b702dcc9.png

 图:酒店数据结构

大家可以看出,这两种资源的描述字段几乎没有相同的,这是客观存在的事实,我们无法强行统一或者合并,更何况还有很多其他不同的资源类型,所以如果想要在它们上层做抽象将十分困难。

接下来试想一个简单的业务场景:

采购系统将这两个资源生成采购单采购,完成后录入资源及库存系统,产品系统将资源封装并上架销售,客人在网站上查找然后下单到订单系统,订单系统去库存系统申请出库,结算系统到账期生成结算单给供

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值