之前也有一些介绍大型网站架构演变的文章,例如 LiveJournal 的、ebay 的,
都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很
详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为
什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章
中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历
程和所需掌握的知识体系,希望能给想从事互联网行业的同学一点初步的概
念,:),文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效
果。
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
架构演变第一步:物理分离 webserver 和数据库
最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可
能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设
这个时候 已 经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具
备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应
速度越来越慢,而这 个时候比较明显的是数据库和应用互相影响,应用出问题
了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,
于是进入了第一步演变阶段: 将应用和数据库从物理上分离,变成了两台机器,
这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到
以前的响应速度了,并且支撑住了更 高的流量,并且不会因为数据库和应用形
成互相的影响。
看看这一步完成后系统的图示:
<!--[if !vml]-->
<!--[endif]-->
这一步涉及到了这些知识体系:
这一步架构演变对技术上的知识体系基本没有要求。
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
架构演变第二步:增加页面缓存
好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因,
发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数
据库连 接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制
来减少数据库连接资源的竞争和对数据库读的压力,这个时候首先也许会选择
采用 squid 等类似的机制来将系统中相对静态的页面(例如一两天才会有更新
的页面)进行缓存(当然,也可以采用将页面静态化的方案),这样程序上可
以不做修改,就能够 很好的减少对 webserver 的压力以及减少数据库连接资
源的竞争,OK,于是开始采用 squid 来做相对静态的页面的缓存。
看看这一步完成后系统的图示:
评论7