前言
网上有很多关于网站结构的各种讨论，对于他们的好坏，我没有资格去评论，因为对于不同领域需要不同的结构。我这里只讲解下我所开发的项目的各个方面，整理下自己的思路，同时也希望分享给大家。
好了，还是回归到正题上。
项目背景
我所开发的项目是一个会员中心，一个社区项目，用户量比较大。至于具体有多少功能，这里不太好详细介绍，单纯从一个社区性质的角度来解读下该网站项目。
我们经历过的网站架构
1）server-lient：一台服务器，搭载了DB和Web服务器，这样开始了网站服务。
2）DB server-Web server-client：DB和Web服务器分开，随着网站访问量增加，这个做了拆分。
3）DB server-Web server;Web server-client：一台DB，多台Web。
4）DB server;DB server-Web server;Web server-client：多台DB，多台Web时代。
从第4代网站架构开始，网站对架构的依赖越来越强，这个时候需要考虑的问题也越来越多，DB同步、Web缓存、负载均衡、DB业务拆分、Web服务拆分等等。
对于第3代以前的架构，这边应该没有必要讲解，这些相对简单，而且基本上大家都已经理解。那么我们就从第4代开始讲解，并衍生出我们现在的第5代架构。
第4代构架简图
1）便携电脑：客户端发起请求，通过CDN负载均衡，将请求分配到各个Web server上。
2）Web server：Web服务器直接读取DB数据，或者读取Web服务器上的缓存，或者读取专门的缓存服务器（App server的一种）来加载用户数据。
3）App server：这里我给的是一个统称，App server有很多功能，比如：缓存用户数据、缓存业务数据、MQ异步服务器、搜索服务器等等，依靠这些App server来降低对DB服务器的直接依赖，减轻数据库压力，提高网站的性能。
4）DB server：这个不用做太多介绍，主要是业务数据的固化，但是这里做了很多DB业务拆分，DB服务器负载均衡等操作，这些都放在后续的文章中讲解。
好了，从这个架构图来看，似乎很完美了。但是事实总是往相反的方向发展，网站用户数量增长比较快，这个架构又不满足了。
衍生出来的第5代架构
先来说说为什么第4代架构不满足需求。
随着用户量的增长，Web server服务器自然需要增加，但是用户数据缓存服务器访问量增大，需要增加服务器；MQ异步服务器请求量增大，大量MQ处理不过来，需要增加服务器。服务器的增加固然可以提高性能，但是服务器的管理问题随之来临，经常出现服务器挂掉，服务不稳定等问题。往往是一台服务器挂掉，整个网站就慢下来，严重影响用户体验。
第5代架构简图
1）便携电脑：客户端发出请求，依然通过负载均衡发送到我们的Web服务器集群。
2）Web服务器集群：Web服务器依然可以直接读取数据库和读取本地缓存的数据，但是增加了一个数据访问层，由数据访问层来提供数据服务。
3）数据访问层：数据访问层对外只提供接口，不提供实现细节，采用分布式技术，提供可靠的、高性能的数据服务。（该部分我也在努力研究中，会在后续的章节进行解读）
4）其他服务：这些服务只是针对一些边缘业务，数据量不大的一些业务。就类似于第4代架构中的App server服务一样。
5）DB服务器集群：我这个架构里的DB集群，在现实实现中，其实并没有做到集群，还是沿用第4代架构中的DB业务拆分，但是DB服务器集群是我们的发展方向。
第5代架构中，最有讲头的应该是数据访问层，因为该层是提供数据服务，对整个网站来说性能、稳定性就全靠它了。
请关注后续文章。
