细分五层解说网站架构

网站架构一般分为网页缓存层、负载均衡层、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等。

最后

以上就是犹豫烧鹅为你收集整理的细分五层解说网站架构的全部内容，希望文章能够帮你解决细分五层解说网站架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。