细分五层解说网站架构

网站架构一般分为网页缓存层、负载均衡层、Web服务层、文件服务层、数据库缓存层及数据库层，一共五层。

1.网页缓存层

网页缓存层，比如CDN租赁，效果比公司自己部署Squid/Varnish更好更专业，很多朋友喜欢尝试自建CDN,这是一个吃力不讨好的活儿，未必能达到预期目标，关于这块运维架构师在网站架构初期就应该规划好，不要等到网站流量和压力巨大时才去规划。
这一层，很多优秀的开源软件都可以胜任，如传统的Squid，后起之秀Nginx和Varnish因为性能优异，越来越多的朋友尝试在自己的网站使用他们作为自己的网页缓存。

proxy_cache_path

它用来制定缓存的目录以及缓存目录深度制定等。它的格式如下：

proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size]; 

PATH

用来指定缓存在磁盘的路径地址**。比如：/data/nginx/cache。那以后生存的缓存文件就会存在这个目录下。

Level

用来指定缓存文件夹的级数**，可以是
levels=1, levels=1:1, levels=1:2, levels=1:2:3
可以使用任意的1位或2位数字作为目录结构分割符，如 X, X:X,或 X:X:X 例如: 2, 2:2, 1:1:2，但是最多只能是三级目录。

keys_zone

所有活动的key和元数据存储在共享的内存池中，这个区域用keys_zone参数指定。

zone_name

指的是共享池的名称,zone_size指的是共享池的大小。注意每一个定义的内存池必须是不重复的路径

2.负载均衡层

我们熟悉的软件技术有LVS/HAProxy,还有Nginx。HAProxy在生产环境下表现确实优异，拥有强大的吞吐能力，稳定也能与硬件能力媲美。
负载均衡建议分成2级处理，一级是流量四层分发，二级是应用层面七层转发，即业务层面。首先可以通过LVS或HAproxy将流量转发给二层负载均衡，即实现了流量的负载均衡，此处可以使用轮询、权重等调度算法来实现负载的转发；然后二层负载均衡会根据请求特征再将请求分发出去。

为什么要将负载分为两层呢？

1.第一层负载均衡应该是无状态的，方便水平扩容。我们可以在这一层实现流量分组（内网和外网隔离、爬虫和非爬虫流量隔离）、内容缓存、请求头过滤、故障切换、限流、防火墙等一些通用型功能，无状态设计，可以水平扩容。
2.二层Nginx负载均衡可以实现业务逻辑，或者反向代理到如Tomcat，这一层的Nginx跟业务有关联，可实现业务的一些通用逻辑。

3.Web服务层

Web层压力比较大的网站现在豆将Web主要应用服务器换成了Nginx，事实上，它在抗并发能力和稳定性方面确实超过了预期。

4.文件服务器层

现在大家的生产服务器一般是使用下面的方案：

1. 单NFS作为文件服务器，这样的好处是维护方便，但存在着单点故障的问题，NFS机器出现故障时需要人为手动干预。
2. NFS分组，虽然这样可以分摊压力，但一样会出现单点故障的问题，出现故障时需要人为手动干预。
3. DRBD+Heartbeat+NFS高可用文件服务器，维护方便，也不存在着单点故障的问题。
4. 采用分布式文件系统，文件服务器磁盘I/O压力过大，这也是一个常见的问题，采取以下做法

• 对于静态内容，如CSS，JS，HTML还有图片文件，可以通过租赁CDN方式来处理。
• 将图片服务器独立处来，并分配独立域名。
• 磁盘的优化：将程序的读写缓存区设置得尽可能大些。
• 在适当得场景下采用分布式文件系统，例如MooseFS

5.数据缓存层和数据库层

网站的PV、UV及QPS和并发连接数增加以后，数据库这块的压力是最大的，数据库的压力归根揭底还是磁盘I/O压力。
Oracle RAC 是很成熟的商业分布式方案，它保证了数据的高可用性。当然价格也是非常昂贵的。

MySQL数据库，面对这种数据库磁盘I/O压力大的情况，应该如何处理呢？
1.在业务逻辑上将数据进行分离。很多读写频繁的业务数据，利用redis分布式缓存保存；
2.数据库的硬件方面可以考虑投入磁盘阵列做RAID 10,如果资金充裕，磁盘可以用SSD固态硬盘来替代SAS机械硬盘。
3.合理设计Mysql数据库的架构，事实上，在生产环境下，一主多从，读写分离是是比较靠谱的设计方案，对于MySQL的负载均衡，这里推荐大家使用LVS/DR ,这是因为从机MySQL节点机器超过10台时，HAProxy的性能将不如LVS/DR。
4. 如果网站的业务量过大，还可以采用分库的方法，比如将网站的业务量分成Web、Blog、Mail等几组，每一组均采用主从脚骨，这样的设计的话就避免了单组数据库压力过大的情况。最后，还应该配合公司的MySQL DBA，在数据库参数优化、SQL语句优化、数据切分上多做功夫，避免让MySQL数据库成为网站的瓶颈。必要的时候，考虑分布式SQL解决方案，例如Redshfit及Hbase等。