网站架构的设计方法

网站架构的设计方法

网站架构，一般认为是根据客户需求分析的结果，准确定位网站目标群体，设定网站整体架构，规划、设计网站栏目及其内容，制定网站开发流程及顺序，以最大限度地进行高效资源分配与管理的设计。其内容有程序架构，呈现架构，和信息架构三种表现。而步骤主要分为硬架构和软架构两步程序。网络架构是现代网络学习和发展的一个必须的基础技术。在选择机房的时候，根据网站用户的地域分布，可以选择网通或电信机房，但更多时候，可能双线机房才是合适的。越大的城市，机房价格越贵，从成本的角度看可以在一些中小城市托管服务器，比如说北京的公司可以考虑把服务器托管在天津，廊坊等地，不是特别远，但是价格会便宜很多。

现在的PHP框架有很多选择，比如：CakePHP，Symfony，Zend Framework等等，至于应该使用哪一个并没有唯一的答案，要根据Team里团队成员对各个框架的了解程度而定。很多时候，即使没有使用框架，一样能写出好的程序来，比如Flickr据说就是用Pear+Smarty这样的类库写出来的，所以，是否用框架，用什么框架，一般不是最重要的，重要的是我们的编程思想里要有框架的意识。网站规模到了一定的程度之后，代码里各种逻辑纠缠在一起，会给维护和扩展带来巨大的障碍，这时我们的解决方式其实很简单，那就是重构，将逻辑进行分层。通常，自上而下可以分为表现层，应用层，领域层，持久层。

所谓表现层，并不仅仅就指模板，它的范围要更广一些，所有和表现相关的逻辑都应该被纳入表现层的范畴。比如说某处的字体要显示为红色，某处的开头要空两格，这些都属于表现层。很多时候，我们容易犯的错误就是把本属于表现层的逻辑放到了其他层面去完成，这里说一个很常见的例子：我们在列表页显示文章标题的时候，都会设定一个最大字数，一旦标题长度超过了这个限制，就截断，并在后面显示“..”，这就是最典型的表现层逻辑，但是实际情况，有很多程序员都是在非表现层代码里完成数据的获取和截断，然后赋值给表现层模板，这样的代码最直接的缺点就是同样一段数据，在这个页面我可能想显示前10个字，再另一个页面我可能想显示前15个字，而一旦我们在程序里固化了这个字数，也就丧失了可移植性。正确的做法是应该做一个视图助手之类的程序来专门处理此类逻辑，比如说：Smarty里的truncate就属于这样的视图助手（不过它那个实现不适合中文）。

所谓应用层，它的主要作用是定义用户可以做什么，并把操作结果反馈给表现层。至于如何做，通常不是它的职责范围（而是领域层的职责范围），它会通过委派把如何做的工作交给领域层去处理。在使用MVC架构的网站中，我们可以看到类似下面这样的URL： domain/articles/view/123，其内部编码实现，一般就是一个Articles控制器类，里面有一个view方法，这就是一个典型的应用层操作，因为它定义了用户可以做一个查看的动作。在MVC架构中，有一个准则是这么说的：Rich Model Is Good。言外之意，就是Controller要保持“瘦”一些比较好，进而说明应用层要尽量简单，不要包括涉及领域内容的逻辑。

所谓领域层，最直接的解释就是包含领域逻辑的层。它是一个软件的灵魂所在。先来看看什么叫领域逻辑，简单的说，具有明确的领域概念的逻辑就是领域逻辑，比如我们在ATM机上取钱，过程大致是这样的：插入银联卡，输入密码，输入取款金额，确定，拿钱，然后ATM吐出一个交易凭条。在这个过程中，银联卡在ATM机器里完成钱从帐户上划拨的过程就是一个领域逻辑，因为取钱在银行中是一个明确的领域概念，而ATM机吐出一个交易凭条则不是领域逻辑，而仅是一个应用逻辑，因为吐出交易凭条并不是银行中一个明确的领域概念，只是一种技术手段，对应的，我们取钱后不吐交易凭条，而发送一条提醒短信也是可能的，但并不是一定如此，如果在实际情况中，我们要求取款后必须吐出交易凭条，也就是说吐出交易凭条已经和取款紧密结合，那么你也可以把吐出交易凭条看作是领域逻辑的一部分，一切都以问题的具体情况而定。

在Eric那本经典的领域驱动设计中，把领域层分为了五种基本元素：实体，值对象，服务，工厂，仓储。具体可以参阅书中的介绍。领域层最常犯的错误就是把本应属于领域层的逻辑泄露到了其他层次，比如说在一个CMS系统，对热门文章的定义是这样的：每天被浏览的次数多于1000次，被评论的次数多于100次，这样的文章就是热门文章。对于一个CMS来说，热门文章这个词无疑是一个重要的领域概念，那么我们如何实现这个逻辑的设计的？你可能会给出类似下面的代码：“SELECT ... FROM ... WHERE 浏览 > 1000 AND 评论 > 100”，没错，这是最简单的实现方式，但是这里需要注意的是“每天被浏览的次数多于1000次，被评论的次数多于100次”这个重要的领域逻辑被隐藏到了SQL语句中，SQL语句显然不属于领域层的范畴，也就是说，我们的领域逻辑泄露了。

网站的性能瓶颈分析

网站的性能影响因素很多，下面主要从如下4个方面进行分析说明：

网络负载

公网负载

内网负载

WEB应用服务器性能

CPU

存储，I/O访问

内存

并发TCP/IP连接数

数据库服务器性能

数据库参数配置

服务器性能（CPU、内存、存储）

数据结构的合理性

不同WEB应用的处理方式而对不同的性能瓶颈

对于静态的网站：

静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一个静态HTML文档发出访问请求后，服务器端只是简单地将该文档传输到客户端。从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资/源。对于静态HTML的访问瓶颈为：网络带宽、磁盘I/O以及cache(高速缓冲存储器)。

对于动态页面

因为服务器解析动态页面必须在其传输到客户端前就通过服务器来进行解释，这样就会给应用服务器添加额外的性能消耗，如果进一步要访问数据库，则会增加数据库服务器的性能消耗，则动态页面还有额外的瓶颈：应用服务器的性能，数据库服务器的性能。

系统架构设计

总体思路

为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计:

负载均衡

四层交换负载均衡：

采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载均衡。

通过第三方软件来实现负载均衡,同时实现页面请求的缓存。

通过Nginx实现反向代理服务器集群，同时搭建squid集群以作为静态页面和图片的缓存。

通过web服务器的配置来实现负载均衡

即通过apache或是Nginx 将客户请求均衡的分给tomcat1,tomcat2....去处理。

WEB应用开发架构思路