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

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

 

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

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

为不少人没有亲身经历过，因此对架构的演变没有深入的了解，包括我本身在内，不过没吃过猪肉，也看过猪跑。。。

 

一：第一代架构

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

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

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

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

 

二：第二代架构

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

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

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

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

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

 

三：第三代架构

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

1. 读操做

　

    咱们知道任何东西都是遵照二八原则，也就是网站上常常访问的东西也就那么多，对于这种命中率很是高的东西就须要用缓存来处理，

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

 

2. 写操做

    这个有分及时写和非及时写，对于非及时写的数据，咱们能够采用 “消息队列”来对写操做节流，从而缓解数据库写入时的瞬时压力。

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

常常高烧不退，被玩爆的次数愈来愈多。

 

四：第四代架构

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

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

等等产品。

 

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