[铁道部信息化管理]核心业务需求及逻辑架构分析

Posted 2020-08-18 海天小阁

快要太监了 :-( 由于各种个人原因, 铁道部的这个博文系列中止了很久。最近终于连自己都不好意思了。所以还是继续完成它吧，估计1-2周一篇的节奏。 感觉不先划分一下大的系统架构总会让大家感觉有点头晕, 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想

• 12306的已知信息、数据及问题
• 需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
• 需求分析（二）—— 涉众、用户体验
• 核心业务需求及逻辑架构分析
• 需求分析（三）—— 票仓
• 票仓设计（一）—— 预生成车票方案的优缺点
• 票仓设计（二）—— 区间二进制方案的优缺点
• 票仓设计（三）—— 平衡方案的优缺点
• 票务并发冲突处理原则设计（基于平衡方案）
• 缓存逻辑架构设计
• 数据库逻辑设计
• 灾难备份与恢复

 

快要太监了 :-(

由于各种个人原因, 铁道部的这个博文系列中止了很久。最近终于连自己都不好意思了。所以还是继续完成它吧，估计1-2周一篇的节奏。

 

感觉不先划分一下大的系统架构总会让大家感觉有点头晕, 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想

 

朴素的面向对象分析

面向对象是一个万金油，但是据说真正懂的人不多是吧？

我对面向对象的感觉就是: 他本质上是对现实世界的抽象，其表面现象是不断细分对象的粒度，提升对象的抽象度。最终形成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。

而系统级别的分析也大致如此，我们可以借鉴类分析中的很多概念，不断划小系统规模，剥离职责，抽出依赖性。

 

一般系统结构

这里只是一个简单模型，用以表达我对多数项目的结构分析。

配置数据服务：系统运行所需要的动态配置信息
资产数据服务：所有实际或虚拟的“物”的管理（CRUD），甚至可以包括人。
业务数据服务：该企业实际经营的业务产生的数据。超市的收银记录，企业的销售记录，铁道部的售票记录
报表数据服务：各类统计报表需要的

其中业务系统和业务数据服务应该是最核心的部分。

一般而言，那些配置和资产管理的部分不会造成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求，努力做到任何资产的属性变动时，确保相关的业务完整性就好（出租公司管理系统里，一辆出租车今天还在运营，后台系统绝对不应该可以轻松地把它标记成报废车辆，连软删除都是不合理的做法）。

12306之所以能招全国人民围观，我觉得主要还是花的钱和大家的感受之间有落差。而我阴暗的以为这个问题的核心部分就在票务处理的部分。

所以我后续的几篇博文都会围绕票务处理里面的内容展开。

另外，我要大家了解的是，我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他自己的需求，而太极公司的需求分析有可以进一步深挖的可能。

 

12306核心需求及模块分析

整体架构没法子设计，太大了。有兴趣的可以参考

中国铁路客票发售和预订系统5_0版的研究与实现
国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操作说明

目前我专注的是用于订票的部分。我感觉这个是最重要的部分。

12306最大的问题，就是如何在订票的时候高效率得并且适当优化得找到需要数量的车票。并且要能彻底保证一张票不会被两个请求同时处理成功。

只要这个问题无法彻底解决，任何分布式处理，最终都会卡在这个问题上。

我会涉及到的模块

 

12306票务处理功能模块分析

假想完整网络订票流程图

这里实际的用户和系统的交互有4种类型。

1、车次和余额查询

2、订票

3、取消订票

4、确认订票

 

这里希望广大围观群众都来评估一下这个假设的订票流程及其参数是不是都合理？如果这个流程本身不合理，则我后续的分析都要重写了。不熟悉售票流程的，可以看看我之前的分析文章。

然后我们继续来细化一下

 

车次和余额查询

输入：起始站，终到站，日期，座位类型集合

输出：车次，对应座位类型可售余额

作用：最终用户根据查询结果选择需要出行的车次，并进一步进入订票操作。但是系统不保证显示为有票的车次在下一步操作中必然有票。

这里其实涉及到两个类型的查询

1、哪些车次符合用户的查询结果，可以通过一个基本固定不变的数据源来提供。而该数据源可以实现分布式缓存以缓解查询压力，甚至可以考虑客户端部分结果缓存。
输入：起始站，终到站，日期
输出 :车次列表，

2、特定车次，特定座位类型的可售票数量。这个数据的来源应该和第一个查询不同。
输入：起始站，终到站，车次，日期
输出：数量

订票(我喜欢称它为锁票)

输入：起始站，终到站，日期，座位类型，需要车票数量，用户ID

输出：实际到的获取车票数量

作用：最终用户通过订票操作，顺利锁定需要数量的车票。系统保证用户在规定的时间段内对这几张车票具有优先订购权利，且其他人不得购买这些车票。

目前我感觉留给用户10-15分钟时间继续后续操作，以进入支付环节（当然，这必须是在系统本身性能良好条件下。否则点个按钮就要等10分钟，那就不对了。）
同时如果超时，则系统会在后续订票操作中忽视该锁定状态。

取消订票

输入：起始站，终到站，日期，座位类型，数量，用户ID

输出：成功标志

作用：用户放弃已经获得的被锁定的售票权利，系统恢复对应的数据为可售。

确认订票（确认支付）

输入：起始站，终到站，日期，座位类型，数量，用户ID，支付相关信息

输出：成功标志/确认失败（刚好锁定超时，且被他人订走）

作用：最终确认售票，系统向第三方支付服务提交确认请求。