大型网站架构体系的演变(上)

    互联网上有很多关于网站架构的各种分享,有些主要是从运维和基础架构的角度去分析的(堆机器,做集群),太关注技术细节实现,普通的开发人员基本看不太懂。

本文上篇将主要介绍大型网站基础架构的扩展,下篇则重点从应用程序的角度去介绍网站架构的扩展和演变。


草根时期,快速开发网站并上线。当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限。

大型网站架构体系的演变(上)_第1张图片

有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了。

大型网站架构体系的演变(上)_第2张图片

市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把DB和APP做分离。

大型网站架构体系的演变(上)_第3张图片

单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。

大型网站架构体系的演变(上)_第4张图片


数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。

大型网站架构体系的演变(上)_第5张图片


加机器谁都会加,关键是加完之后得有效果,加完之后可能会引发一些问题。例如非常常见的:页面输出缓存和本地缓存的问题,Session保存的问题......

大型网站架构体系的演变(上)_第6张图片

到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引。

Java领域用的较多的是Lucene、Solr等,而php领域用的比较多的是sphinx/coreseek。

大型网站架构体系的演变(上)_第7张图片

到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。当然,每一步扩展里面都会有很多技术实现的细节,后续有时间会写文章单独去剖析那些细节。

下篇我们继续


  欢迎大家关注微信号:neihanrukou


你可能感兴趣的:(大型网站架构体系的演变)