(2条消息) 大话铁道部12306订票系统云架构
一、引言
随着春节的临近，大家都忙着从网上刷票，随之而来的就是对12306订票网站的质疑声。今天就针对这个问题和朋友还讨论了一番，有感于此，本人从技术的角度对此进行分析并对整个系统的架构进行了一下重构构想。
首先整个售票系统是一个非常庞大而复杂的系统，是一个高负荷、高并发的云平台，其规模甚至比淘宝大2至3倍，而且对于数据的实时性要求非常高。光是12306网站系统的日访问量达到了15亿次，如果加上各个代售点和车站售票系统，则高峰时段数据访问层的并发量在千万级别。如此大的访问和并发量，如果没有好的架构设计肯定保证了不系统的稳定性和健壮性。
其次，本人觉得12306网络订票系统是在铁道部原有的联网售票系统基础上开发的，所以其原有的数据架构很关键，它直接影响到整个系统的扩展性和稳定性。设想一下如果整个系统全部进行重构那是多么庞大的工程，这不仅涉及到整个架构的重新设计、服务系统开发，还有一个更繁重的工作就是所有火车站的售票系统和代售点系统都将全部升级，至于12306网络订票系统肯定不会出太大的问题，但是对于车站售票系统可是一个很大的考验，不能有半点的闪失。因而我想铁道部也不会冒这个风险。正是因为12306是在原有的架构上增加和扩展的，所以才有了目前的种种问题。如果一切从头架构反而好多问题迎刃而解。
二、总体架构
这里我就对这个新的系统架构做一个详细的设计，首先要认清此应用是一个云平台的典型应用，系统要按云平台的思想分层设计，从上而下分为三层，即：应用层、数据访问层、数据层。每一层之间是松散耦合。合得每一层具有很强的扩展性和伸缩性。每一层内部都是基于集群技术，分组部署，每一组处理单元都是即插即用，可根据计算压力动态扩充，其大致的结构如下图：
应用层：主要是指各种售票和订票系统，主要有三种，如车站售票系统、代售点系统及12306网络订票系统。其中前两个是C/S结构的应用，后一个是B/S应用模式。其客户端应用服务器之间增加一个负载均衡服务，这有利于系统的并发，可以有效地根据当前用户量和访问情况自动地分配相对压力较小的服务器。
数据访问层：主要是将业务应用与底层数据库之间的操作接口专门独立出来，业务应用访问数据不是直接访问数据库，而是通过数据访问层进行间接地访问和操作。这样的好处是可以解决数据访问的并发瓶颈，可以根据系统的压力情况动态地调整和部署访问层。
数据层：根据车次和地域将车次的余票信息分别存储在很多个数据中心上，每一个数据中心是一组服务器。这样将众多的并发用户根据查询车次分散到多个数据中心上去。从而降低单点压力，提高整体的并发性能。如果数据访问是一个大瓶颈则可增加数据中心的节点而减小数据中心的粒度（也就是每个数据中心减少车次数量），可提高数据访问的速度。
三、详细架构
系统整体按分层架构处理，每一层都是可注册、可插拔的体系，这种架构的好处是每一层都可以分层优化，而互不影响。并能根据实际运行的情况对并发和访问量过大的实体层进行动态扩容，很容易提高系统的并发和稳定性。
此架构很好地解决了应用服务器和数据访问的瓶颈问题，如果应用服务器压力大则可以通过注册表对应用服务器扩容，并通过负载均衡均衡地访问各个应用服务器。如果数据访问是一个瓶颈则可增加数据加心的方式来解决数据访问拥挤情况。
对于数据层系统按车次对所有的车次车票信息进行分组，每一组是一个数据中心，数据中心的大小可随时调整。这样可以把用户对数据的访问分散到多个节点上去，从而降低数据中心的压力。每一个数据中心由若干台机器组成，一台主数据服务器，若干从数据服务器。主数据是用于给用户出票，每一个接口调用都需要加锁，保证票数数据修改的原子性，其所管理的车次和车票数据在内存中高速缓存。同时每隔一定的时间周期同步到从数据服务器上，从数据是用来提供查询的数据副本，它把大量的查询操作分散到从数据服务器上。其数据访问的流程如下：