我也要谈谈大型网站架构之系列(1)——纵观历史演变(上)

 

转自:http://www.cnblogs.com/huangxincheng/p/3682008.html

 我们知道一个网站都是随着业务的发展,逐渐演变成几万服务器,几亿用户数的大型网站,经历了若干年,甚至上十年的

发展成为大型网站,然而真正亲身经历这个发展过程的人已经不多了,这种人也是拿着公司股票,赶都赶不走的人,所以正因

为很多人没有亲身经历过,所以对架构的演变没有深刻的了解,包括我自己在内,不过没吃过猪肉,也看过猪跑。。。

 

一:第一代架构

  这年头创业大多都是从穷屌丝开始的,奔着 “快好省”的原则建立网站,将“应用程序”,“文件”,“数据库”通通放在一台服务

器上,匆匆的就走上了网站架构之路。

我们知道业务的发展对技术会有更高的要求,业务的创新会触动技术的创新,当业务逐渐发展起来的时候,最容易出现的问题就是

”存储空间“和通用的”性能低下“,这个时候就需要做到”应用程序“和”数据“的分离。

 

二:第二代架构

   随着业务规模的扩大,需要将”应用程序“,”文件“,”数据库“进行分离,用更强大的cpu处理服务器来承载应用程序,记得在上一

家用的cpu就是16核,”文件“的话则需要更大的磁盘空间的服务器,”数据库“的话需要更大的磁盘和超大内存的服务器,我们知道

sqlserver还是很吃内存的,记得用过最大的是120g的内存。

随着业务规模不断扩大,访问人数逐渐增多,我们也开心了,起码挣到钱了,然后我们会发现数据库开始出现瓶颈了,大量的读写操作让

数据库出现访问延迟以及死锁现象的发生,继而影响用户体验。

 

三:第三代架构

     既然大量的读写操作让数据库出现瓶颈了,这个时候就要从两个方面优化读写操作

1. 读操作

 

    我们知道任何东西都是遵守二八原则,也就是网站上经常访问的东西也就那么多,对于这种命中率非常高的东西就需要用缓存来处理,

  减少读的次数,在携程里面的memcache就做了“数据热度”的操作,对于热度低的数据会自动从缓存中踢掉。

 

2. 写操作

    这个有分及时写和非及时写,对于非及时写的数据,我们可以采用 “消息队列”来对写操作节流,从而缓解数据库写入时的瞬时压力。

这时候数据库的读写操作得到了很大的缓解,随着业务规模的继续扩大,用户人数的再次暴增,我们会发现”应用程序服务器“的CPU

经常高烧不退,被玩爆的次数越来越多。

 

四:第四代架构

      既然被爆表了,这时候必须再拉一个应用程序服务器来分摊前端访问带来的压力,做了集群之后,需要再配一台”负载均衡调度器“,

不过屌丝公司用的比较多的还是nginx,高大上的公司都是动辄几十万的硬件负载均衡,比如携程用的就是A10,还有市场上几十万F5

等等产品。

 

好了,先大概这么说了,睡觉时间到了,明天继续往下扯。

我也要谈谈大型网站架构之系列(1)——纵观历史演变(上),古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。