众所周知，大家习惯将网站分成三层：即负载均衡层、web层、数据库层，但我根据线上的实际压力情况，强烈建议分成五层，即硬件防护层、负载均衡 层、web层、文件服务器层(图片)、数据库层，这样大家理解一个简单的网站可能更容易。理解了最基础的网站后，再理解大型网站架构可能就更容易了。
硬件防火墙层：
这一层最重要的是安全防护，最基本的是要防止DDOS攻击及应用层的防护等。我目前应用得比较好的是华赛的三层防火墙+天泰七层应用防火墙，具体实 施案例请参考我在51cto.com的文章，这里限于篇幅我就不详细说明了；如果成本预算不是太高的话，可考虑Juniper系统的防火墙，效果也不错。
负载均衡层
这一层要考虑的东西其实很多，包括：
一、你考虑布署的网站到底要承受多大的并发量；
二、负载均衡层是否能稳定，存在单点故障吗；
三、成本的考虑有时要高于技术的；
四、网络的情况也决定了你到底要考虑哪种负载均衡器。
基于以上几点情况，我拿实际情况分明下：
我最早之前维护的CDN广告网站，并发长期在6000以上，所以只能考虑F5，而又要做到高可用，此时不是单F5了，所以上了二台F5，当然成本也 非常的高；公司光在F5上的投入，大约应该在60-80万之间，相信这样的投入，未必会被你所在公司的决策层所接受；而我后期维护及布署的证券类资讯网 站，并发比较小，大约在200之间，所以我用了二台Linux机器作的LVS+Keepalived，效果也不错，相当稳定；而现在维护的公司的电子商务 网站，并发大约在1.1K左右，初期我们其时也考虑的是LVS+Keepalived，但上上去就发现公司的网络情况非常乱，每台服务器至少有六七条静态 路由，lvs上上去根本就发挥不了作用，所以换上了Nginx+keepalived，我也编写了shell监控nginx服务进程，实现真正意义上的负 载高可用。这一层我总结了下，其时考虑以下几点情况，即成本、网络、并发、高可用。
web集群层
这一层为了避免单点故障，大家都用的是Apache、Nginx或tomcat集群，其好处也很明显：①避免单点故障；②负载客户端的高并发请求。 Apache是LAMP架构最核心的WebServer，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销 大，性能上有损耗，不如一些轻量级的Web服务器(例如Nginx)高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。而 且现在根据实际的线上环境，Nginx服务器抗并发确实高于Apache，这一点张宴的博客已作了大量详细叙述，但在Apache在高内存 (>=16G)的情况下，单Apache的抗并发能力也是很强的，高于6000。我现在的做法是，如果是生级现有的以Apache作为 webserver的网站，我单纯只是考虑加上Nginx作负载均衡，不会动原有网站的架构；如果是架构新网站，我会采用Nginx作为 webserver。
文件服务器层
这一层的作用容易被人忽视，其实现在服务器的性能都上上去了，并发情况也都被大家重视，但服务器层的压力却甚少有人关心，在大规划的频繁的访问过程 中，单NFS越来越不能满足网站的需求了，我们有时接到用户反映网站慢的情况，结果采用故障排查才发现，居然是NFS不堪重负，针对于这种情况，目前采用 的方案有：
①可采用田逸推荐的分布式文件系统MFS(moosefs)实现存储共享，他目前将此系统应用于遨游，线上用的东西毕竟比较有说服力；
②直接用NEC的存储，虽然强悍，但增加了网站的实施成本及复杂度；
③用DRDB+Heartbeat+NFS组建NFS集群，效果也很稳定，但也要注意Heartbeat的脑裂问题。
数据库层
为了更好的说明力，我这里用的网站都以电子商务和广告网站，这些对数据库要求严苛的网站来说明，这些网站对数据库的要求是很高的，在数据库并发、稳定及延时性方面均有要求，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储。目前采用的方案有：
①目前多采用MySQL的主从方案，实际读写都采用单一服务器，服务器采用公司性能最好的服务器充当(MySQL的cluster暂时不敢用于线上环境)；
②采用oracle的RAC双机方案，在实际高并发的数据库需求下，效果还是相当不错。
加速缓存层
PHP的负载采用Apache集群，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。这一层可以根据你的网站情况来 考虑，现在由于Nginx的反向代理越做越好，我们其实可以用最前端的Nginx来充当反向代理，这时的Nginx服务器，充当的作用是负载均衡器/反向 代理；张宴已将其用于了生产环境，具体可参考他的相关文档.
网站架构是一个艺术活，责任重大；系统架构师不等于系统工程师，要想从系统工程师到系统架构师，不仅需要许多多年的运维经验和广泛的运维知识，还需要付出大量的努力，希望大家都成为未来的系统架构师，最后祝大家工作愉快!
