核心业务需求及逻辑架构分析

核心业务需求及逻辑架构分析

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，支付相关信息

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

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

界面编程模仿篇(QQ登录界面逼真篇)

写了好多天的爬虫，偷空前前后后用了两天的时间(排除吃饭睡觉)写完了这个QQ登录界面，看起来还凑和着吧，如果是的大神的，莫见笑，纯属业余作品，废话先不多说，截图如下,其中第二幅图片中的红色方框部份有待完善，明天开始继续搞爬虫，等有时间时再完善，先凑和着吧：









本篇博文就分析一下这个界面设计中的几个关键点，在阅读本博文之前请先阅读我个人博客上关于模仿QQ界面先行篇

界面编程模仿篇(模仿腾讯QQ登录界面先行篇)

本程序开源，下载地址，请查看我个人博客：烟雨林


对于还不会使用github的同学，以下是我的个人博客上的两篇教程

Github简明教程(入门篇)

Github上如何给别人贡献代码

程序采用

Java

语言实现，本人只懂

C++

/

Java

/

Python

/

Shell

,其他程序语言一概不懂，等有时间再写其他两种语言的登录版本，可以订阅我的个人博客,获取后绪相关文章与资料

1、QQ界面登录程序最显著的地方就是界面无标题栏，所以第一步就是去掉标题栏，Java中给

JFrame

去标题栏的方法很

easy

的确很easy是吧，但问题又出来了，是去掉了，连窗口的边框都去掉了，这肯定不是想要的结果，在这里可以采用

JInternalFrame

实现去标题栏同时保留窗口的边框，核心代码如下(代码中

jif

是

JInternalFrame

类型):

2、QQ界面窗口居中

3、由于去掉了标题栏，结果最小化，最大化，关闭均被去掉了，更重要的一个功能是窗口随鼠标拖动也被去掉了，因此这些功能都需要自已再重新实现，实现的代码也是很easy的，给JInternalFrame增加监听器，此时得注意的是监听器里操作的对象应该是JFrame,因为最终的目的是对JFrame操作，窗口移动的核心代码如下：

4、重写JPanel，给

JPanel

增加背景图片，核心代码如下:

5、按钮的相关设置，对JButton的设置主要是设置背景的透明化，大小，内边框等，对JLabel以及JCheckbox作类似处理，相关代码例子如下：

6、对JPasswordField的处理，QQ密码限制了长度，而且禁止了copy,paste,cut,以及对文本的选择操作，在这里就要自已实现一个类继承JPasswordFiled,在这个类里面重写copy,paste,cut,同时还得重写

JPasswordField

的Document模型对像，只有重写了它，才能限制密码的输入长度，以下是限制密码长度的代码：

7、最重要的一点，就是如何缩减代码的长度，增加代码复用，这个得自已考虑去

8、程序中不采用任何界面布局，Java中的界面布局不太适合，将布局设置成

null

,自已控制控件的位置

备注：本程序开发过程中需要用到的软件请参考 界面编程模仿篇(模仿腾讯QQ登录界面先行篇)

最后，如果先和我合作，把这个界面做的更逼真，请阅读Github上如何给别人贡献代码，期待你的参与