焦点三：高性能高并发系统架构到底该怎样设计?

　　关于12306购票系统的问题讨论到这个阶段，几乎所有人都明白，就目前情况下，使用单台服务器根本就不可能应对这种千万级PV的并发，只能用集群来解决这个问题，那么说到集群，就不可避免地谈到系统架构，可以说架构将直接影响整个系统的性能发挥。如果架构不合理，单台服务器性能再好也是无处着力;而反之则情况未必，并且这种情况在互联网行业相当常见，诸如谷歌、Facebook等公司均是采用普通性能的服务器来搭建集群，并通过系统架构和特定优化来发挥其最大性能，对于业内人士而言，这些都不必废话。

　　百度首席架构师林仕鼎认为，类似于12306的在线交易系统可采用Scale-out这种模式来做，即通过简单地不断添加机器的方式。也就是说，架设这个系统本身并不复杂，12306系统之所以崩溃，主要原因在于请求的尖峰，10倍于平常的压力是很正常的。普通模型到达性能瓶颈后，开始堆积请求(可能在web server，也可能在请求队列，不过通常不会在CDN)，吞吐急剧下降，延迟急剧上升，而随着堆积请求越多，情况越糟，引起雪崩效应。而12306的问题就是属于这种情况，这样的压力通常不会持续很久，如果性能不急剧下降的话，一段时间后其实也就能把请求都响应了。但12306的情况则是人们没有买到票，于是不停是刷新，这个操作是不间断的，而且是大规模范围内的，所以宕机也就实属必然。

　　林仕鼎随后在第二篇博文中说，(类似于12306)系统的复杂度在于海量的并发请求，并发性可以通过scale-out(简单来说，就是堆机器)加以解决，但最难的却是保证系统的稳定吞吐。值得注意的是，在线系统应以保证极限情况下的稳定输出(sustained throughput)为首要设计目标，而这是不容易实现的。至于如何切分数据，如何scale-out，这和具体业务特点关系密切。这些都是软件层需要解决的问题，如何用软件架构的方法来实现scale-up就很困难，做得好与不好可能性能差异能达几倍到一个量级。

　　IBM软件架构师景文童认为12306 互联网售票系统应该是一个高性能、高伸缩性、高可靠性的系统，可以在高峰期(例如春运时刻)增加机器能够应对高峰期的峰值用户群。而目前的传统做法是用一大堆好机器来做数据库集群和应用服务器集群，把用J2EE架构做出来的功能部署在应用服务器集群上，而把大部分压力都放在数据库上。景文童认为，传统的做法并不特别关注高性能、高可靠性、高伸缩性的应用架构设计、数据架构的设计和相应的代码质量。而这也正是12306系统所缺失的地方。

12306与中国著名的互联网企业进行合作解决—整体架构

　　针对类似于12306的高性能高并发系统设计，童文童认为12306网站完全可以和新浪、淘宝等大型互联网公司进行合作，通过他们的平台进行登录，利用这些大型互联网公司的资源与12306的平台相对接，以分散海量并发所带来的压力，具体架构设计可参考上图。

　　在集成架构方面，可采用以消息队列为核心的异步机制把新浪微博、淘宝、腾讯这些公司平台提供的互联网售票应用与12306互联网售票数据服务系统集成起来。这种消息队列为核心的异步机制进行解耦的架构有几个最大的好处：

　　当大量的并发的用户(例如千万级别的)在几分钟之内甚至1分钟之内压到新浪微博、淘宝、腾讯这些公司平台提供的互联网售票WEB应用，所产生的压力由相应的网络、均衡负载器、互联网售票WEB应用的服务器给分别的承受掉。并且转换成相应的消息异步的传到12306互联网售票数据服务系统进行处理，这样转换给12306互联网售票数据服务系统的并发压力将会下降几个数量级。

　　12306互联网售票数据服务系统可以根据相应的需求按需配置所需要的资源(例如机器数目和线程数目进行处理)对不同的队列进行处理。并且由于采用了消息队列为核心的异步机制，在高峰期的时候肯定是大量的消息涌入以期待处理，在没有采用消息队列为核心的异步机制的时候我们需要的一次一条条进行处理，而这种情况下例如我们可以对登录实现一次处理10条消息的批量处理，从而大大地降低对数据库的压力。

　　12306可以将前端交给这些公司合作一起解决高并发问题，当然也可以自己独立解决前端的并发问题，以避免合作过程中可能出现的问题。这对于整体系统架构设计而言，并不会有太大的变化，只是需要投入大量的成本而已。详细可查看《12306系统高性能高并发架构设计遐想初稿》。