目前网站架构普通分红负载平衡层、WEB层和数据库层，我其实普通还会多加一层，即文件效劳器层，这样我们在后面的讨论过程中，我们能够依次对这四层停止讨论；这里为了更具有压服力，我将用三个并发较大的消费环境来阐明下，一个是某电子商务网站（并发最大值 2000，日PV500万左右，这里说的峰值，下面的网站相似）、一拍网网站（并发最大值1500，日PV500万左右）、以前维护的大型CDN广告网站（并发最大值5000，日PV 5000万左右）。

负载平衡层

首先说下负载平衡层，我们熟习的硬件/软件技术有F5/LVS、HAProxy，还有Nginx，它们的性能都是十分优良的，且不说F5的抗并发才能，LVS如今在全世界范围内的应用，而且淘宝如今晋级架构，也将LVS取代了F5，HAProxy可能大家不是特别熟习，但它的确在消费环境下表现优良，强大的吞吐才能，稳定性比之硬件过尤不及。

再说下Nginx，我是将Nginx+Keepalived架构用于了各种消费环境中的，经过长时间的线上察看，发现Nginx作为负载平衡器/反向代理也很稳定，就算并发压力过大，我们前面能够用F5/LVS来顶，而将Nginx作为中层代理，这样的效果其实也 不差，所以负载平衡层的压力不能算是特别大。

WEB层

WEB层这块压力比拟大的网站如今都换成了Nginx作为WEB应用效劳器，事实上，它的抗并发才能的确超越了预期；我朋友维护的一家门户网站，顶峰期时某台Nginx应用效劳器的并兴旺到了一万以上，但Nginx也很担任和稳定的提供效劳，在实践的消费环境中，假如我们思索到后端的数据库效劳时，一万并发应该也算是一个比拟大的数值了。

另外，Linux集群有一个优势，就是它的高扩展性，就算我们的网站的并发有一万以上，我们后端的WEB效劳是Apache，我们多加几台Apache效劳器即可，在实践的线上维护时，我们发现，顶峰期间，实践上每台WEB的并发并不算是特别大，所以网站的压力在这一层我们也能经过技术手腕加以克制。

文件效劳器层

文件效劳器层，由于网站的后期宣传策话，名气也越来越大，PV值也越来越高，原先的DRBD+Heartbeat+NFS（这个其实也只是单NFS，只不过我们应用DRBD来保证NFS的高可用而已）曾经越来越顶不住压力了，这个时分我们想到了散布式文件系统，我测试的的是MooseFS，在内网测试了很长时间还是没敢用到消费环境下面，googel的散布式文件系统还是很成熟的，引荐大家学习；最后还是用采用以前的CDN传统的办法处理这个问题，即用了squid反向代理加速器来处理小文件过多的问题，Nginx强大的正则处置分发才能，也让后端的NFS压力变得很小；另外，我还用采用域名的分散战略例如运用pics.xxx.com/pdf.xxx.com…来辨别标志为a或b的一系列文件，这些文件存储的时分，仍然依照标志，存到pics或pdf的效劳器上。这个战略将辨别机器的任务交由dns效劳器来执行，扩容时会相应轻松。

这需求web项目初期就规划好这些东东，后期才转用域名战略的本钱比拟高以至不能够完成，大家能够留意下，其实这一层假如网站是专业的图片效劳器网站时压力还是很大的，我们需求在这个上面投入足够多的硬件资源。

数据库层

数据库层的压力，我觉得网站的PV和并发上去以后，数据库这块的压力是最大的，CDN大型广告网站我们用的是oracle RAC计划，它保证了数据的高可用性，当然了价钱也是十分昂贵的（假如运用高配置的PC效劳器，Oracle普通依照CPU个数收费）；那么免费的MySQL数据库，面对这种并发压力大的状况，又用哪些办法呢？首先，我们说下传统的MySQL主从计划，配置简单，单机MySQL优化做好事性能也不弱，假如这种架构处理不了数据库的压力状况，我们能够思索以下几种计划：

◆常规复制架构–Master-slaves，是由一个Master复制到一个或多个Salve的架构形式，主要用于读压力大的应用数据库端低价扩展处理计划，读写别离，Master主要担任写方面的压力。

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

◆Dual Master与级联复制分离架构，即Master-Master-Slaves，最大的益处是既能够防止主Master的写操作遭到Slave集群的复制带来的影响，而且保证了主Master的单点毛病。

◆MySQL的数据库切分，我们能够经过数据切恰恰技术将一个大的MySQL Server切分红多个小的MySQL Server，既解了写入性能瓶颈问题，同时也一次提升了整个数据库集群的扩展性，从而处理了数据库压力过大的问题，这个如今也是我在消费环境中比拟引荐的做法之一。