双十一谈如何从零开始搭建大型机票交易平台

简单描述上图,采购商查询机票价格的条件是：出发目的地、时间之类的,业内叫 av.这部分信息通过 OMS 同步模块将从代理商录入的政策中航班等信息作为索引放到 Solr 里,匹配到了能取到政策 ID,再去 Redis 里取政策详情,找到反馈给采购商,当然其中有一些处理航司交互的东西.

生单系统

下面介绍,生单结构类图：

简单描述下,搜索出报价,中间有个确认过程叫核价,就是最后看看是不是机票会变价,有变价是否接受.之后就进入生单.不同平台的理解不一样,有的平台把支付之后叫生单.

由于不同航司,不同 GDS 标准,不同处理路径,所以生单流程是均不一样的.所以设计模式采用的是链式,这个比较成熟,当有新的流程,只需要在绿色加上对应的 handler,写逻辑添加到 BizHandleBuilder 里,做好规则即可,结合图二进行理解.

支付系统

下面介绍,另外一个核心模块,支付类图：

简单描述下,生单之后,采购和供应都觉得 ok,采购商要支付.

B 端系统一般要支持这么几个功能：支持二次或改签支付、灵活处理各种错误、支持中断支付、继续支付机制、明细查看和导出、管理员权限支付、用户级别锁定、支持作废正在支付中单子、营收和立减、财付通支付宝三方等.

要消化这些功能,所以要设计出：便于扩展,继承指令参数拼接类,添加支付类型等抽象思想：

我这边设计,采用蓝色模块表示将支付流程统一处理,绿色代表指令执行拼接流程统一处理,橘黄色表示扩展部分,一般都是逻辑核心的地方.

比如,如果订单要支持三次支付,那么就可以多了一个 OrderThirdPayService.比如有个支付接口要适配,就要做个新的 XXX 实现指令拼接流程管理就好.

这里给公司的支付中心点个赞,无论多晚,他们都有人都在陪着联调.

以上列举了两、三个核心模块介绍,其他核心模块都类似设计.

模块设计的原则

简约的理解,模块设计是要求这样的,遵循依赖倒置单一原则.

至少三层结构,遵循依赖倒置,且实现 service 都有各种方法提供,这也是给合作方很好的支持,想有各种方法都有.缺点是代码冗余.

异步化设计

下面就是边边角角的了,异步化的设计：

（编辑：开发网_新乡站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!