【大型网站开发系列】——网站结构层次

独孤求财 2012-03-23

展开全文

【大型网站开发系列第一篇】——网站结构层次

前言

网上有很多关于网站结构的各种讨论，对于他们的好坏，我没有资格去评论，因为对于不同领域需要不同的结构。我这里只讲解下我所开发的项目的各个方面，整理下自己的思路，同时也希望分享给大家。

好了，还是回归到正题上。

项目背景

我所开发的项目是一个会员中心，一个社区项目，用户量比较大。至于具体有多少功能，这里不太好详细介绍，单纯从一个社区性质的角度来解读下该网站项目。

我们经历过的网站架构

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代架构中，最有讲头的应该是数据访问层，因为该层是提供数据服务，对整个网站来说性能、稳定性就全靠它了。

【大型网站开发系列第二篇】——网站代码结构

开篇一言

任何东西都不是一蹴而就，它往往有一个衍变的过程，把握事情的规律，会让我们更加深刻地理解它。而本文也是是顺着这个思路过来的。

第4代架构代码结构简图

如果你没有看过该系列的第一篇文章，那么你可能会对这篇文章有些困惑，所以建议读者先查看第一篇文章（【大型网站开发系列第一篇】——网站结构层次）。

从上面图片看来，一切都是那么的熟悉，跟大家在开发项目的过程中项目的设定基本一致。你可以把它说成是三层架构、多层架构，随便你怎么给它取名。但是第4代架构代码不仅仅是这样，这里只是一个最最基本的代码结构，实际开发中，我们还有Windows Serivces服务、Remoting Services服务，以及很多在Microsoft给我们提供的模板之上开发的各种服务。

详细代码结构图（最重要、也是最容易扩展的一个项目代码）

Jiangzhichao.Demo.DAC

做过数据库操作代码底层封装的人，应该差不多都知道这些类的含义，以及它们之间的一些关系。

抽象类DataHelper，是对各种数据库操作代码的一个抽象，提取出公共的代码逻辑，定义一些公共的代码接口让子类去实现，基本上做到了数据库和应用之间的解耦。

使用介绍

使用Jiangzhichao.Demo.DAC还是比较简单的，只要实例化一个DataHelper子类出来，然后使用该子类的实例进行数据库操作。这一步的操作我封装在了Jiangzhichao.Demo.DataAccess项目的BaseDataAccess类里面，只需要传入一个连接字符串和数据库类型（这个可以放在配置文件中），然后进行业务开发就OK了。

第5代架构的衍变成型

从上面代码结构简图可以看出，业务开发人员，只需要操作除Jiangzhichao.Demo.DAC项目以外的项目，业务开发人员不需要去了解Jiangzhichao.Demo.DAC里面对数据库操作的封装，唯一需要去了解的就是怎么去跟DBA沟通，让DBA提供符合业务需要的数据接口（sql语句、存储过程、方法）。

那么这就给底层开发人员一个很好的机会，专心研究底层架构，Jiangzhichao.Demo.DAC项目把数据和业务做了分离，底层开发人员在DAC这个项目中，只要保证对外的接口不变，内部的封装就可以随意改动，对业务开发人员一点影响都没有，这做到了两不误，业务开发人员专心业务，底层开发人员专心底层封装，并行开发，对整个项目的推进是个很大的帮助。

所以出现了第5代架构。第5代架构中，数据访问层就可以在目前DAC的基础上进行扩展，引入面向服务开发的概念，所有的数据都是以服务的方式提供给业务开发人员。那这个服务会是用什么方式提供呢？也许是WebServices，也许是Remoting，也许是WCF，还有可能是我们自己封装的XX框架，你还可以把目前热炒的分布式、海量存储等XX东西给弄进来。