大话铁道部12306订票系统云架构

一、引言

    随着春节的临近，大家都忙着从网上刷票，随之而来的就是对12306订票网站的质疑声。今天就针对这个问题和朋友还讨论了一番，有感于此，本人从技术的角度对此进行分析并对整个系统的架构进行了一下重构构想。

    首先整个售票系统是一个非常庞大而复杂的系统，是一个高负荷、高并发的云平台，其规模甚至比淘宝大2至3倍，而且对于数据的实时性要求非常高。光是12306网站系统的日访问量达到了15亿次，如果加上各个代售点和车站售票系统，则高峰时段数据访问层的并发量在千万级别。如此大的访问和并发量，如果没有好的架构设计肯定保证了不系统的稳定性和健壮性。

    其次，本人觉得12306网络订票系统是在铁道部原有的联网售票系统基础上开发的，所以其原有的数据架构很关键，它直接影响到整个系统的扩展性和稳定性。设想一下如果整个系统全部进行重构那是多么庞大的工程，这不仅涉及到整个架构的重新设计、服务系统开发，还有一个更繁重的工作就是所有火车站的售票系统和代售点系统都将全部升级，至于12306网络订票系统肯定不会出太大的问题，但是对于车站售票系统可是一个很大的考验，不能有半点的闪失。因而我想铁道部也不会冒这个风险。正是因为12306是在原有的架构上增加和扩展的，所以才有了目前的种种问题。如果一切从头架构反而好多问题迎刃而解。

二、总体架构

    这里我就对这个新的系统架构做一个详细的设计，首先要认清此应用是一个云平台的典型应用，系统要按云平台的思想分层设计，从上而下分为三层，即：应用层、数据访问层、数据层