简单讨论火车票系统后面的架构设计

 　　武汉北大青鸟光谷校区：简单讨论火车票系统后面的架构设计

       简单说，在线服务scalability有两种方式，scale-up和scale-out。Scale-up追求单机性能，如硬件、异步架构等，而scale-out则用加机器的方法。Scale-out也是简单的方法，在规模不是非常大时很好用，也很容易解决问题，普通工程师就足以胜任。有很多现成的方法或模块可以使用。

　　也就是说，很多时候通过加机器就能解决大多数问题。只要规模在一定量级下(通常的在线系统规模都不会特别大)，我们可以先不考虑硬件故障以及自动运维。

　　但为什么很多时候系统还是崩溃呢?罪魁祸就是请求的尖峰，10倍于平常的压力是很正常的。普通模型到达性能瓶颈后，开始堆积请求(可能在web server，也可能在请求队列，不过通常不会在CDN)，吞吐急剧下降，延迟急剧上升，而随着堆积请求越多，情况越糟，引起雪崩效应。而这样的压力通常不会持续很久，如果性能不急剧下降的话，一段时间后其实也就能把请求都响应了。

　　为10倍压力而准备机器是不合适的，我们需要有办法能扛住瞬间压力。这时候架构设计主要考虑的问题，也就是我上个weibo所说的，如何保证限情况下的稳定吞吐。有很多种办法，分级队列、请求调度、延迟截断、主动拒绝等等，这些都有助于帮系统度过艰难时刻。具体的做法，就不在这里讨论了。

　　当然，我也并不是说这个系统是非常难做的，因为可以有很多种做法，如普通文艺、文艺等，:)。如何用软件架构的方法来实现scale-up就很困难，做得好与不好可能性能差异能达几倍到一个量级。但对于普通公司来说，直接scale-out是合适的，规模不大时多一些机器也不会对成本产生太大影响。但关键的是，要注意如何处理峰值压力，提供限情况下的稳定输出。也就是说对于普通在线系统，即那些transaction-based systems，规模不太大，只是可能有海量的用户请求。只要在设计时注意限情况下的稳定输出就可以了，实现的工艺水平高不高，差别只是机器多少而已，通常看不出来。

　　对于大数据量的系统，无论在线或离线(其典型代表就是搜索引擎)，则又是另外的故事了。