存储 频道

林仕鼎:简单讨论火车票系统的架构设计

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

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

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

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

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

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

1
相关文章