一、铁路票务业务分析

可以参考12306官网。
分为两大类：匿名服务、登入服务。
匿名服务包括：登入、售票时段查询、订票时长查询、余票查询、自助订票、列车时刻表查询、旅客列车正晚点查询、票价查询、代售点查询、车站引导等等。
登入服务包括：订票（个人网上订票、代售点售票、窗口售票、补票、团体票、学生票）、退票、支付、验票。
与核心业务相关的有：登入、售票时段查询、订票时长查询、余票查询、自助订票、订票（个人网上订票、代售点售票、窗口售票、补票、团体票、学生票）、退票、支付。核心业务不多，但是最繁忙的，尤其以订票最繁忙。
其他非核心业务虽然涉及到数据库，但大多都可以用静态方式呈现，就是说数据库在非核心业务当中存在的意义没有那么显著。
所以完全可以将核心业务独立出来，用单独的架构设计。所用框架必需保障一定的安全性、稳定性、集群性、可扩展性等必要的元素；所用数据库一定要高速与大数据两手准备（现在看来两者不可合并，所以采用共用的方式）;语言首选java，健壮、安全。
余票查询：意义不大的但又必需的一个业务，因为即使查询到了，但转瞬之间就被人订了几张，根本不具有时效性。所以用定时将统计的结果存储某个数据表，查询数据就从这个数据表获取，减轻运算上的压力。
登入：对安全要求较高，除了保障传输以及服务器的安全外，还要辅助客户端的安全。比如用桌面程序、单独的插件录入、汉字验证码（对抗暴力破解比英文有效）等等。服务端所能做到的就是汉字验证码。
售票时段查询、订票时长查询：基本上属于静态化了，但为了客户端的访问便捷，还是放在这里了。
余票查询：业务非常简单。
订票：最为核心的业务了，没啥好说的，直接上内存数据库处理。订票方面的管理也是经验丰富的，只要铁老大肯传授。比如分时段售票、车站或区间预留票等等，都是一些具体操作方法了，也是经过实践检验行之有效的方案。不知铁老大如何解决联程票的，因为分时段售票後，必然影响到联程票。这个与原系统的对接也是最为关键的一个业务。如何处理售票窗口、售票点与个人订票。
退票：有人提到了预定退票的操作，想法非常不错。在操作上就要区分订票时段与非订票时段。订票时段的退票直接打入票池，供其他人订票；非订票时段的退票进入退票池，然后按预约发送短信。这样即使抢票软件也不会在非订票时段抢票了，因为根本抢不到，除非遇到无聊的或者水平低的：明知不可为而为之，诚心干扰系统运行。如何处理售票窗口、售票点的关系，比如无人预定的退票才可以有售票窗口或售票点出售，凡只要距离发车时间一定时限内的退票只能由售票窗口出售。
支付：可交由第三方支付，如支付宝。与支付宝会晤後确认是否已经支付。
分析到现在，尚未把货运、托运等功能算为核心业务，这个也不是当前的重点。还有一些增值功能（线路规划等）尚未考虑。这样核心业务与非核心业务可以由留个团队完成，即使非核心业务遭受攻击，也不会影响整个系统运行。这样看来，核心业务真的不多，难得是工作中遇到了哪些问题，这个铁老大最是心知肚明。比如规定一张身份证只能订三张同车次同始发同终到的车票，虽然也为黄牛留下了缺口，但这也限制了黄牛票，而且也是必需的（小孩子、身份证丢失、没有身份证的）。新系统与原系统的对接如何操作，铁老大不会把宝压在一个系统上的，必然存在两个系统并行很长一段时间。