从四个层面分析网站的架构

　　一、负载均衡层
　　首先说下负载均衡层，我们熟悉的硬件/软件技术有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服务器来执行，扩容时会相应轻松。
四、数据库层
数据库层的压力，我觉得网站的PV和并发上去以后，数据库这块的压力是最大的，CDN大型广告网站我们用的是oracle RAC方案，它保证了数据的高可用性，当然了价格也是非常昂贵的（如果使用高配置的PC服务器，Oracle一般按照CPU个数收费）；那么免费的MySQL数据库，面对这种并发压力大的情况，又用哪些方法呢？首先，我们说下传统的MySQL主从方案，配置简单，单机MySQL优化做好事性能也不弱