织梦CMS - 轻松建站从此开始!

天府星空

当前位置: 主页 > 网页设计 > 建站经验 >

细分四层网站架构,网站的压力究竟在哪里?_成都网站开发公司

时间:2012-11-06 21:59来源:未知 作者:admin 点击:
目前网站架构普通分成负载均衡层、WEB层和数据库层,我其实正常还会多加一层,即文件服务器层,这样我们在后面的探讨进程中,我们可以顺次对这四层进行讨论;这里为了更存在压服力,我将用三个并发较大的生产环境来阐明下,一个是某电子商务网站(并发最大值

目前网站架构普通分成负载均衡层、WEB层和数据库层,我其实正常还会多加一层,即文件服务器层,这样我们在后面的探讨进程中,我们可以顺次对这四层进行讨论;这里为了更存在压服力,我将用三个并发较大的生产环境来阐明下,一个是某电子商务网站(并发最大值 2000,日PV500万左右,这里说的峰值,下面的网站相似)、一拍网网站(并发最大值1500,日PV500万左右)、以前保护的大型CDN广告网站(并发最大值5000,日PV 5000万左右)。

数据库层

另外,Linux集群有一个上风,就是它的高扩展性,就算我们的网站的并发有一万以上,我们后真个WEB服务是Apache,我们多加几台Apache服务器即可,在实际的线上维护时,我们发现,顶峰期间,实际上每台WEB的并发并不算是特别大,所以网站的压力在这一层我们也能通过技术手腕加以战胜。

◆级联复制架构,即Master-Slaves-Slaves,这个也是为了避免Slaves的读压力过大,而配置一层二级 Slaves,很轻易解决Master端由于从属slave太多而成为瓶劲的危险。

数据库层的压力,我感到网站的PV跟并发上去当前,数据库这块的压力是最大的,CDN大型广告网站我们用的是oracle RAC方案,它保障了数据的高可用性,当然了价钱也是十分昂贵的(假如应用高配置的PC服务器,Oracle个别依照CPU个数收费);那么免费的MySQL数据库,面对这种并发压力大的情形,又用哪些方式呢?首先,咱们说下传统的MySQL主从方案,配置简略,单机MySQL优化做好事机能也不弱,如果这种架构解决不了数据库的压力情况,我们能够斟酌以下多少种方案:

文件服务器层

-->

WEB层

◆惯例复制架构–Master-slaves,是由一个Master复制到一个或多个Salve的架构模式,重要用于读压力大的利用数据库端便宜扩大解决计划,读写分别,Master主要负责写方面的压力。

这须要web名目初期就计划好这些东东,后期才转用域名策略的本钱比较高甚至不可以实现,大家可以留神下,其实这一层如果网站是专业的图片服务器网站时压力仍是很大的,我们需要在这个上面投入足够多的硬件资源。

WEB层这块压力比较大的网站现在都换成了Nginx作为WEB应用服务器,事实上,它的抗并发能力确实超过了预期;我友人维护的一家门户网站,高峰期时某台Nginx应用服务器的并发到达了一万以上,但Nginx也很负责和稳定的供给服务,在实际的生产环境中,如果我们考虑到后端的数据库服务时,一万并发应当也算是一个比较大的数值了。

负载均衡层

首先说下负载均衡层,我们熟悉的硬件/软件技巧有F5/LVS、HAProxy,还有Nginx,它们的性能都是无比优异的,且不说F5的抗并发能力,LVS现在在全世界范畴内的运用,而且淘宝当初进级架构,也将LVS代替了F5,HAProxy可能大家不是特别熟习,但它确切在生产环境下表示优良,强盛的吞吐才能,稳定性比之硬件过尤不迭。

◆Dual Master与级联复制联合架构,即Master-Master-Slaves,最大的利益是既可以防止主Master的写操作受到Slave集群的复制带来的影响,而且保证了主Master的单点故障。

◆MySQL的数据库切分,我们可以通过数据切刚好技术将一个大的MySQL Server切分成多个小的MySQL Server,既解了写入性能瓶颈问题,同时也一次晋升了全部数据库集群的扩展性,从而解决了数据库压力过大的问题,这个现在也是我在生产环境中比拟推举的做法之一。

再说下Nginx,我是将Nginx+Keepalived架构用于了各种出产环境中的,经由长时光的线上察看,发明Nginx作为负载平衡器/反向署理也很稳固,就算并发压力过大,我们前面可以用F5/LVS来顶,而将Nginx作为中层代办,这样的后果实在也 不差,所以负载均衡层的压力不能算是特殊大。

文件服务器层,因为网站的后期宣扬策话,名气也越来越大,PV值也越来越高,本来的DRBD+Heartbeat+NFS(这个其实也只是单NFS,只不外我们应用DRBD来保证NFS的高可用罢了)已经越来越顶不住压力了,这个时候我们想到了分布式文件系统,我测试的的是MooseFS,在内网测试了很长时间还是没敢用到生产环境下面,googel的散布式文件体系还是很成熟的,推荐大家学习;最后还是用采取以前的CDN传统的办法解决这个问题,即用了squid反向代理加速器来解决小文件过多的问题,Nginx壮大的正则处置散发能力,也让后端的NFS压力变得很小;另外,我还用采用域名的疏散策略例如使用pics.xxx.com/pdf.xxx.com…来分辨标记为a或b的一系列文件,这些文件存储的时候,仍然按照标志,存到pics或pdf的服务器上。这个策略将辨别机器的义务交由dns服务器来履行,扩容时会相应轻松。

相关的主题文章: (责任编辑:admin)
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
验证码: 点击我更换图片