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

有了这样结构的好处：

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

从数据量上,要有足够的分析,预估上线的一个月内,日票量 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 端用户去做飞机了.

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

机票搜索

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

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

生单系统

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

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

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

支付系统

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

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

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

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

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

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

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

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

模块设计的原则

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

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

异步化设计

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

（编辑：ASP站长网）