原文地址：http://toutiao.com/news/6232654162220286465/?tt_from=mobile_qq&utm_campaign=client_share&app=news_article&utm_source=mobile_qq&iid=3167618386&utm_medium=toutiao_ios

目前网站架构一般分为网页缓存层、负载均衡层、Web层、数据库层、文件服务器层。我们可以依次用这五层对网站架构进行讨论，为了增强说服力，我将用如下三个并发较大的生产环境来说明。

• 电子商务网站（并发最大峰值2900，日PV500万左右）

• 电子广告网站（并发最大峰值1500，日PV150万左右）

• 大型CDN门户广告网站（并发最大峰值5000，日PV5000万左右）

1.网页缓存层

首先说网页缓存层，比如CDN租凭，其效果比公司自己部署Squid/Varnish要好，它们专业、价格低廉（比如：快网、蓝讯、阿里、腾讯）而且覆盖的城市更多，自己架设Squid/Varnish是次选。

很多朋友喜欢尝试自建CDN，这是一项吃力不讨好的工作，未必能达到预期的目标，系统架构师应该在架设网站初期就规划好，不要等到网站流量及压力巨大时才去规划。事实上，这一层有很多优秀的开源软件都能胜任，比如传统的Squid Cache。另外，越来越多的朋友喜欢尝试在自己的网站是用Nginx和Varnish作为自己的网页缓存。事实上，Nginx已经具备Squid所拥有的Web缓存加速功能。此外，Nginx对多核CPU的利用胜过Squid，现在越来越多的架构师都喜欢将Nginx同时作为”负载均衡服务器”与”Web缓存服务器”来使用，大家可以根据自己的情况，来决定究竟使用那种软件作为网站的网页缓存。

2.负载均衡层

我们熟悉的硬件/软件技术有F5、LVS/HAProxy，还有Nginx，它们的性能都是非常优异的，现在F5/LVS在全世界范围内应用，而且淘宝现在升级架构，也用了LVS取代了F5。

HAProxy可能大家不是特别熟悉，单HAProxy+Keepalived确实在生产环境下表现优异，强大的吞吐能力，稳定性能比之硬件过犹不及，并且淘宝也在大规模地推广使用HAProxy，有兴趣的朋友也可以关注。

再来聊聊Nginx，我已经将Nginx+Keepalived架构用于各种生产环境，经过长期的线上观察，发现Nginx作为负载均衡器/反向代理也很稳定，如果兵发压力过大，我们前面可以用F5/LVS作为最前端的负载均衡，而将Nginx作为七层代理，这样的效果其实也不差，所以说负载层压力不算特别大。

3.Web层

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

另外，Linux集群有一个优势，就是它的高扩展性，就算网站的并发有一万以上，后端的Web服务是Nginx，我们多加几台Nginx服务器即可。在实际的线上维护时发现，高峰期间，实际上每台Web的并发不算是特别大，所以我们也能通过技术手段对这一层的网站的压力加以克服。

4.文件服务器层

现在大家生产服务器一般是使用如下四种作为自己的文件服务器层：

1、单NFS+备份NFS作为文件服务器，这样做的好处是维护方便，但存在单点故障，需要人手动干预。

2、DRBD+HeartBeat+NFS高可用文件服务器，维护方便，也不存在单点故障，单随着访问量的增大，后期一样存在压力过大的情况。

3、分布式文件系统MFS、Glustr。MFS易用、稳定、对海量小文件很高效，而且新版的MFS解决了MasterServer存在单点故障的问题，国内越来越多的公司在使用MFS。事实上，分布式文件系统是解决文件服务器压力过大的最终途径，但也存在隐患，网站功能越多，摊子越大，机器越多，维护起来越复杂。

4、如果是淘宝和腾讯这种巨量级的公司，可以尝试开发自己的分布式文件系统了。大家可以尝试根据自己网站的情况，来决定究竟选择哪一种如那件作为自己的文件服务器。

5.数据库层

数据库层的压力，我觉得网站的PV和并发上去以后，数据库这块的压力是最大的，CND大型广告网站用的是Oracle RAC方案，它保证了数据的搞可用性，当然了价格也是非常昂贵的（如果使用高配置的PC服务器，Oracle一般按照CPU个数收费）；那么字啊使用免费的MySQL数据时，面对这种并发压力打的情况，我们应该怎么办？

首先，可以在数据库中加入memcached数据缓存，在实际线上使用时，发现memcached功能强大、性能稳定，在数据流频繁读写，压力过大的情况下，增加一台memcached数据库缓存服务器的效果能超过我们的预期。

数据库的硬件方面可以考虑投入磁盘队列做成RAID10，如果资金充裕，磁盘可以用固定硬盘来代替SAS硬盘，毕竟数据库的压力主要来自磁盘I/O方面。

合理的设计MySQL数据库的架构，事实上，在生产环境下，一主多从、读写分离是靠谱的设计方案，从MySQL的负载均衡推荐大家使用LVS，这是因为当后面的MySQL机器超过十台时，HAProxy在这方面的性能不如LVS。

如果网站的业务量过大，可以采用分库的方法，比如将网站的业务量分成Web、BBS、Blog等几组，每一组均采用主从还够，这样的设计避免了单组数据库压力过大的情况。

另外我们应该还配合公司的MySQL、DBA和开发人员，在数据库参数优化、SQL语句优化、数据切分上多下功夫，避免数据库成为网站的瓶颈。

后续我会发布如何优化MySQL，从硬件–安装方式–配置文件优化-SQL优化-status状态优化–慢查询优化–表优化-MySQL高可用的扩展。

网站架构关注方向小结

1、我们的网站放在IDC机房内，首选考虑的就应该是如何防止DDOS/CC攻击。DDOS攻击虽然没什么技术含量，但真正攻击过来还是很让人烦躁的。在搭建网站或系统时，我们应该尽可能地了解和熟悉各种防火墙的技术指标参数，为客户提供性价比最好的防火墙方案也是保证整套系统或网站成功的因素之一。

2、业务逻辑设计要合理，尤其是程序代码层的相关设计，如果程序应用架构和业务实现不够优化，一个本来很简单的实现却绕了很多弯路才实现，那么多强的硬件也没有用。

3、也许是受张宴先生的影响，现在越来越多的朋友把注意力放在Nginx上了。其实Apache的抗并发能力并不弱。在生产环境下，如果我们的网站不是广告型网站、门户型网站或游戏型网站，2000并发已经是一个很惊人的数字。另外这个仅仅是一台Apache的并发，一个中等规模的网站，后端至少会有3~4台Apache的Web应用程序，所以，全部加起来我们的网站差不多可以顶住上万的并发，上万的并发量对网站根本没有什么大的影响。当然，如果换作Nginx作为Web应用服务器更没问题了。另外，就算并发量非常大，我们最前端的F5/LVS还是顶得住的，无非是在后端多加几台Web应用服务器。所以说，并发量大不可能成为Web应用服务器的瓶颈。

4、DRBD+HeartBeat+NFS文件服务器在初期没什么压力，但随着网站的用户数和流量越来越大，它可能会感觉有些顶不住了，特别是用户频繁访问图片文件时。我们在公司内部也测试郭Google的分布式文件系统，但是一直没敢用于生产环境中，最后还是决定采用Nginx作为中层代理，增加Squid反向代理服务器集群的方法来解决文件服务器的压力问题。另外，如果资金充裕，最前端也应该租售CDN用于网站加速。

5、将Nginx作为中层代理使用是一件性价比非常高的事情。如果担心单点Nginx故障，我们可以设置3台以上的Nginx负载均衡器，而它们的load balance可以让F5/LVS来做。Nginx在这层可以利用其强大的正则处理能力很完美地处理客户端对静态文件的访问，比如将html、jpg、png、css等交给后端的Squid/varnish集群处理，冬天的PHP/JSP访问请求交给后端的PHP/Tomcat集群服务器处理，动静分离，最大化地发挥Nginx作为负载均衡器/反向代理的优势。

如果没有硬件的F5 Big-Ip设备，我们也可以用软件LVS来实现，这样成本会相当低。Nginx则利用其强大的正则功能，并根据URL或客户请求文件的后缀名来做动静分离，或者轮训不同的Squid/Varnish反向代理群组。

6、上线的项目在后期无论怎么优化或架构，最后其压力最大的肯定是MySQL数据库，尤其是那些动态网站。我们在维护时也发现，MySQL数据库在频繁地读写，如何优化MySQL数据库及设计高性能高可用的MySQL数据库架构一致是我们关注和研究的方向，我也希望大家在工作中注意这个问题。

7、系统或网站的构建、运维和调试并不只是一个人的事情，它是整个团队合作努力的结果，需要整个团队的开发人员、系统工程师和DBA及测试人员共同努力，要写出安全、效率高、优美的代码，需要花费开发人员大量的心血。

作者：徐亮伟

原文：http://www.xuliangwei.com/xubusi/188.html

    本文转自深蓝医生博客园博客，原文链接：http://www.cnblogs.com/bluedoctor/p/5084616.html，如需转载请自行联系原作者