五层网站架构

目前网站架构一般分为网页缓存层、负载均衡层、 Web层、数据库层、文件服务器层

。我们可以依次用这五层对网站架构进行讨论，为了增强说服力，我将用如下三个并发较大的生产环境来说明。

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

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

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

笔者联系QQ：572891887 也可以加入架构师交流群:471443208

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 语句优化、数据切分上多下功夫，避免数据库成为网站的瓶颈。