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

有了这样结构的好处：

• 结合状态机和操作,再根据交易流和数据流向的模拟,给予产品形态更好的回归,确保业务上无阻塞问题.
• 各模块互不干涉,从事务上给予更好的保证.

从数据量上,要有足够的分析,预估上线的一个月内,日票量 1500 左右 即：15 * 7875 = 118125 条(数据库记录).

产生一条主单订单时,会增加：1 条订单记录,5 条工单,20 条工单回复,10 条状态变更,5 条支付和解冻记录,4 条航班,9 条乘机人,约 45 条左右..

与主订单同比,子单约 40 条左右.每百主订单会产生 5% 售后子单,即百条订单 = 105 * 45 = 4725 (数据库记录) .假定按出票率 60% 计算的话,百张票记录 = 4725 / 0.6 = 7875,可保证 5 – 6 年的 150% 增长.

根据这个实际的业务量级考虑,所以我只做了分库没有分表.

以上的内容是是需求分析阶段,大概两周左右.

架构设计阶段

到这个阶段的时候,要分析要做的这个平台的愿景是什么?这里要结合公司对 B 端平台的期望,最后重点是稳定、可靠、安全、灵活.

由于发现有个老的运行比较久的政策管理和搜索模块可以“借”来重构,那么只需要考虑的其他几个模块了,售前、售后、工单、运营平台等.

找其他技术同学讨论几轮后,结合平台期望,也最终确定了系统结构是怎样的.

因业务情况稍微解释下,上边的深蓝色是入口和出口,左边的黑色是公共技术,采用 dubbo 的 RPC(此处有坑),DAO 用的是 MyBatis,绿色部分代表其他部门提供支持.

这个系统结构,也是结合平台期望来的,这个完了就要考虑工程结构了.

从上到下,从左到右.采用复用的设计模式,个人认为较为合理的工程结构,也是目前我们工程制定的迭代任务制定的.

整体上完事了,下面到各模块的了,由于是业务独特性,这里插播下机票内部的业务流程.

先有供应商录入航线和价格的东西,业内叫政策,录入完了,采购商就能搜索到,选择适合的下单,支付和出票,这是售前,采购商拿到供应商提供的票号就可以让 C 端用户去做飞机了.

售后,就是退改签、工单等,也是各大平台的收入来源,与本次分享无关,不细说了.

机票搜索

下面介绍,搜索报价结构类图：

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

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