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

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

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


草根时期,高速开发站点并上线。

当然,通常仅仅是先试水。用户规模也没有形成,经济能力和投入也非常有限。


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


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


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



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



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


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

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


到眼下为止。一个可以承载日均百万级訪问量的中型站点架构基本介绍完了。

当然,每一步扩展里面都会有非常多技术实现的细节。兴许有时间会写文章单独去剖析那些细节。

下篇我们继续。

posted @ 2017-07-27 14:01  lytwajue  阅读(160)  评论(0编辑  收藏  举报