高负载、高并发网站架构知识汇总-大流量网站架构的几点认识
大流量网站如何构架
大流量网站如何构架本文章来自于阿里云云栖社区大流量、高并发的网站架构是一个系统工程，主要围绕解耦化、服务化以及缓存化的思路，整体做到水平扩展，从而支撑海量访问。
可以从以下几点进行架构：多台服务器支撑业务系统水平扩展、通过CDN加速全国用户的静态文件访问、通过缓存加速数据库的访问、通过数据库的分表分库和读写分离等问题，构建海量的文件系统。
...多台服务器支撑业务系统水平扩展只要业务系统可以随时水平扩展，这样的架构理论上可以扛住任意流量的访问。
可以选用传统的负载均衡技术来进行流量分发，支撑多服务器。
常用的负载均衡技术硬件的如F5，价格比较贵；软件的有LVS、Nginx、HAProxy。
但是自己搭建并维护这套系统，会是非常挑战的事情。
您也可以选用阿里云提供的负载均衡（原文链接：https:///product/slb/?spm=5176.8072238.yqblog1.4.Hxmfq5）来完成这项工作，较传统技术更简单易用，且能降低60%的成本。
负载均衡能够根据应用负载进行弹性扩容，并在流量波动情况下不中断对外服务；其冗余设计，可使服务可用性达99.99%。
负载均衡产品的负载分担能力结合云服务器ECS（原文链接：https:///product/ecs/?spm=5176.8072238.yqblog1.5.Hxmfq5）的快速创建能力，可为我们构建海量用户的系统打下了坚实基础。
通过CDN加速全国用户的静态文件访问假如应用的服务器是部署在北京机房，则北京的用户访问是较快的，而广州的用户访问则相对较慢，这是由于广州和北京分别属于不同地区，广州用户访问需要通过互联路由器经过较长的路径才能访问到北京的服务器，返回路径也一样，所以数据传输时间比较长。
对于这种情况，可使用CDN（原文链接：https:///product/cdn/?spm=5176.8072238.yqblog1.6.Hxmfq5）解决，其原理是将数据内容缓存到附近的机房，用户访问时先从最近的机房获取数据，这样可大大减少网络访问的路径，提高用户访问网站的响应速度与网站的可用性，解决网络带宽小、用户访问量大、网点分布不均等问题。
高负载网站架构
大型网站的架构设计问题在CSDN上看到一篇文章（/fww80/archive/2006/04/28/695293.aspx）讨论大型高并发负载网站的系统架构问题，作者提出了几点建议：1.HTML静态化，这可以通过CMS自动实现；2.图片服务器分离（类似的，在视频网站中，视频文件也应独立出来）；3.数据库集群和库表散列，Oracle、MySQL等DBMS都有完美的支持；4.缓存，比如使用Apache的Squid模块，或者是开发语言的缓存模块，；5.网站镜像；6.负载均衡。
作者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”，并提出“一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群”。
在实践时可以考虑建立应用服务器集群和Web服务器集群，应用服务器集群可以采用Apache+ Tomcat集群和WebLogic集群等，Web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析均可。
从提升网站性能的角度出发，静态资源不应和应用服务器放在一起，数据库服务器也应尽量独立开来。
在典型的MVC模式中，由谁来完成数据逻辑处理的，对系统性能有着至关重要的影响。
以Java EE为例，在OO的设计思想中，我们强调系统的抽象、重用、可维护性，强调下层的更改不会扩散到上层逻辑，强调系统移植的便捷性，因而往往存在一种过分抽象的问题，比如在Hibernate的基础上再加入一层DAO的设计。
另外一方面，却会忽视利用DBMS本身的优秀特性（存储过程、触发器）来完成高效的数据处理。
诚然，如果客户要求将数据从Oracle移植到MySQL，那么DBMS特性的东西越少，移植便越容易。
但事实上，在实践中，提出类似移植要求的情况非常少见，因此在做架构设计时，不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。
此外，我不建议采用分布式数据库管理结构，这样带来的开销太大，数据维护也是个头痛的问题，尽可能采用集中式的数据管理。
大型网站架构方案分析与总结
大型网站架构方案分析与总结大型网站架构只包含高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类与一些依靠HTML静态化就能够实现的架构了，我们以高负载高数据交换高数据流淌性的网站为例，比如海内，开心网等类似的web2.0系列架构。
我们这里不讨论是PHP还是JSP或者者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是务必要面对的。
这里讨论一下大型网站需要注意与考虑的问题。
1、海量数据的处理众所周知，关于一些相对小的站点来说，数据量并不是很大，select与update就能够解决我们面对的问题，本身负载量不是很大，最多再加几个索引就能够搞定。
关于大型网站，每天的数据量可能就上百万，假如一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。
在这个时候我们关于一个表的select与update的时候(还不说多表联合查询)的成本的非常高的。
2、数据并发的处理在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。
关于缓存，在高并发高处理的时候也是个大问题。
在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，假如两个或者者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。
这个时候，就需要一个好的数据并发处理策略与缓存策略。
另外，就是数据库的死锁问题，也许平常我们感受不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
3、文件存贮的问题关于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储同时被有效的索引。
常见的方案是对文件按照日期与类型进行存贮。
但是当文件量是海量的数据的情况下，假如一块硬盘存贮了500个G的琐碎文件，那么保护的时候与使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。
高并发重负载网站架构浅析
高并发重负载网站架构浅析在高并发和重负载情形下，对网站高效能的追求，是大型网站设计和优化的首要出发点。
本文从静态内容分离和应用拆分、存储拆分、缓存机制和负载均衡四个方面简要分析了高并发和重负载网站的技术架构，最后对系统架构设计的原则进行了简单的探讨。
标签：网站架构；应用拆分；存储拆分；缓存体系；负载均衡1 静态内容分离和应用拆分网站中效率最高、消耗最小的是纯静态化的HTML页面。
实现动态的数据和逻辑与静态的表现相分离是高负载应用普遍采取的方法[2]。
对于交互应用较少的页面可以简单的以静态页面呈现，而对于内容量大且频繁更新的站点，则通常借助CMS系统批量的生成和维护静态页。
HTML静态化也是某些缓存策略的基础，对于系统中频繁使用数据库查询但是内容更新很小的应用，通常会使用静态页作为缓存的一部分，从而避免大量的数据库访问请求。
对于小型的web系统，由于负载较低，通常可将所有的应用逻辑在单一系统中实现。
所有逻辑均在一个进程或一个应用中运行。
但随着系统用户的增加和系统功能的扩展，系统复杂度将大大上升、系统维护和扩展的难度不断增加，同时系统的可用性和伸缩性也会受到影响。
因此有必要对大型的互联网应用进行拆分，即，将原来的系统根据一定的标准（如业务相关性）拆分为不同子系统，分别负责不同的功能，从而可以大大的提升系统的水平伸缩性，可以有针对性的对重负载的子系统进行水平扩展而不会影响到其它的子系统，避免了单一系统存在的由于局部应用在重负载下崩溃而引起整个系统崩溃的现象发生。
2 存储拆分静态内容分离后可以大大提升网站的负载能力，但仍无法突破海量数据集中存储和访问引起I/O效率瓶颈。
因此在存储的层面对系统进行拆分就至关重要。
2.1 数据库拆分大型网站通常由数据库驱动，那么在面对大量访问的时候，数据库的瓶颈会很快出现。
因此通常需要使用数据库集群或者库表散列对数据库进行拆分。
在数据库集群方面，大多数数据库厂商都有自己的解决方案。
架构设计中的高并发与负载均衡策略
架构设计中的高并发与负载均衡策略随着互联网的快速发展和用户需求的提升，许多企业都在面临一个共同的挑战，即如何应对高并发的访问量和保证系统的稳定性。
在架构设计中，高并发与负载均衡策略是解决这一问题的关键。
一、高并发的挑战在现代社会，随着移动设备的普及和互联网的普及，用户对网站和应用的访问需求越来越高。
而当大量用户同时访问系统时，系统将面临严峻的挑战。
高并发的挑战主要表现在两个方面：流量方面和性能方面。
首先，高并发下的流量将会给网络带宽带来很大的压力。
网络带宽有限，如果同时有大量用户发起请求，就容易造成网络拥堵，从而影响用户的正常访问。
其次，高并发会对系统的性能造成影响。
当系统处理并发请求时，如果系统的性能不足，就容易造成响应延迟或者超时，给用户带来不良体验。
系统的性能问题包括处理速度、内存、磁盘I/O等方面。
二、负载均衡策略的意义为了应对高并发的挑战，需要在架构设计中引入负载均衡策略。
负载均衡的目标是将请求均匀地分发到多台服务器上，以实现对系统资源的合理利用和响应时间的优化。
负载均衡策略的意义主要体现在以下几个方面：1. 提高系统的可用性和稳定性：通过负载均衡，当某一台服务器出现故障时，其他服务器可以接替其工作，从而保证系统的可用性和稳定性。
2. 提高系统的吞吐量：通过负载均衡，可以将用户请求均匀地分发到多台服务器上进行处理，有效地提高系统的吞吐量，满足用户的并发需求。
3. 降低系统的响应时间：负载均衡能够根据服务器的负载情况，将请求分发到性能较好的服务器上，从而减少用户等待的时间，提高系统的响应速度。
三、负载均衡的策略与实践在实际的架构设计中，有多种负载均衡的策略可以选择。
下面介绍几种常见的负载均衡策略：1. 随机策略：将请求随机地分发到服务器集群中的任意一台服务器上。
这种策略简单高效，可以实现基本的负载均衡，但缺点是无法根据服务器负载情况进行调整。
2. 轮询策略：按照事先设定的顺序依次将请求分发到服务器集群中的服务器上。
高并发高负载涉及知识点
内容 带宽(解决思路：增加带宽，DNS域名解析分发多台服务器)、web服务器连接数(负载均衡，前置代理服务器 nginx,apache等)、数据库查询性能(数据库优化、读写分离、分表分区分库集群等) Apache Bench（AB）、Webbench、http_load 阿里云态势感知、安骑士、OneAPM • CPU usage:显示 I/O wait,System, User 的平均 CPU 使用率时间曲线图 • Load average:显示平均加载率时间曲线图 • Physical memory:分别显示Used, Swap两部分物理内存使用时间曲线图 • Disk I/O utilization:某磁盘设备平均磁盘 I/O 利用率时间曲线图 • Network I/O:平均网络速率时间曲线图 • 进程:显示服务器中所有进程数列表信息 • 下浮框:截止至当前时间 2 分钟内服务器实时数据,包括: CPU 使用率，物理内存使用率，网络速率，磁盘 内存使用率、CPU使用率、IOPS、平均每秒执行SQL语句个数TPS、慢SQL 数据库结构优化、查询字段加索引、SQL语句优化、尽量不使用多表联查、加冗余字段 分表分区分库集群、读写分离、主从备份 数据库同步：持久化层使用分库分散压力；单库读写分离一主多从主写从读分散压力；加入memcache或redis的 cache层减轻数据库读压力；不同业务存在不同服务器上分散压力；从库的硬件配置更高保证高效读取数据。 Mysql从库的sync_binlog记录日志设为1最安全但性能比0差至少5倍，或禁用binlog功能； inndb_flush_log_at_trx_commit提交到磁盘设为2最合理，也是0时最快但不安全 尽量减少数据库操作，多使用内存或缓存进行数据处理 脏数据：当一个事务对数据进行了修改但还没有提交到数据库，这时另一个事务也访问了这个数据，这时读取的 错误数据就是脏数据。 不可重复读：在一个事务中多次读同一个数据，第一次对数据进行了修改但还没有提交到数据库，第二次再读取 的数据就是错误的，这个数据就是不可重复读。 同步异步，同步时增加乐观锁(设置数据库版本：等待锁-获取锁-处理程序-释放锁)和悲观锁(数据库锁机制，如 select...for update) 命名空间、单例模式、工厂模式、注册模式、适配器模式、策略模式、观察者模式、原型模式 HTTP的GET/POST/Headers/Cookie/Session校验和过滤、用户角色和权限验证、CSRF校验、HTTP页面缓存、跨域 中间件（jsonp、iframe、CORS、nginx代理、nodejs中间件、WebSocket）等 防SQL注入、IP限制、token限制、对等加密、接口时效性验证、HTTPS（SSL证书）私钥验证等方式 尽量将数据存储在缓存中，最大程度减少数据库查询操作。统计功能尽量缓存，或利用空闲时间做定时统计 LVS+Keeplived或nginx+upstream(ip_hash、权重：随机/哈希/轮询/加权轮询，设定等方式)或DNS轮询 按PV/QPS计算使用服务器数量，网站带宽=PV/统计时间（换算到S）*平均页面大小（单位KB）* 8，并发连接数 =PV/统计时间*页面衍生连接次数*http响应时间*因数/web服务器数量，服务器数量=每天总PV/单台服务器每天 架构中使用服务器集群解决单台服务器的瓶颈问题 尽量使用html静态页面，减少动态程序处理操作
大流量高并发的网站的底层系统架构
大流量、高并发的网站的底层系统架构动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、等服务器端语言开发的网络应用软件，比如论坛、网络相册、交友、BLOG等常见应用。
动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。
大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。
大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。
大型动态应用系统又可分为几个子系统：l Web前端系统l 负载均衡系统l 数据库集群系统l 缓存系统l 分布式存储系统l 分布式服务器管理系统l 代码分发系统Web前端系统结构图：为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。
该Web前端系统基于Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。
服务器对开发人员是透明的，不需要开发人员介入服务器管理负载均衡系统负载均衡系统分为硬件和软件两种。
硬件负载均衡效率高，但是价格贵，比如F5等。
软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs,nginx。
大多数网站都是硬件、软件负载均衡系统并用。
数据库集群系统结构图：由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？我们可以采用如上图所示的方案：1) 使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。
高并发网站服务器架构优化技巧
高并发网站服务器架构优化技巧随着互联网的发展，越来越多的网站开始面临高并发访问的挑战。
为了能够应对这样的挑战，网站的服务器架构需要进行优化。
在本文中，我们将介绍一些高并发网站服务器架构优化技巧。
一、负载均衡当用户数量增加时，往往会导致服务器负荷过大，无法满足用户的访问需求。
为了避免这种情况发生，可以采用负载均衡技术。
负载均衡可以将用户请求按照某种规则分配到多个服务器上，这样就可以避免其中某个服务器过载的问题。
常用的负载均衡算法有轮询、权重轮询、最小连接数等。
轮询算法是指将请求按照顺序分配到服务器上，权重轮询算法则是指根据服务器的性能等级，分配不同的权重，使得性能更好的服务器能够承载更多的请求。
最小连接数算法则是指分配到当前连接数最少的服务器上，以此来达到负载均衡的目的。
二、缓存技术缓存技术也是高并发网站优化中常用的技术之一。
缓存技术能够提高网站的访问速度，减轻服务器的负担。
通过缓存技术可以将频繁使用的数据缓存在内存中，当用户再次请求该数据时，直接从内存中读取，避免了频繁的数据库查询。
常用的缓存技术有Redis、Memcached等。
这些技术不但能够将数据缓存在内存中，还可以实现分布式缓存，提高系统的可用性。
三、CDN技术CDN技术是指将网站的静态资源（如图片、视频等）缓存在全球各地的服务器上，这样可以避免用户请求过程中跨越太多的距离，提高网站的访问速度。
同时，CDN技术还可以减轻服务器的负担，使得网站可以更好地应对高并发的访问。
常用的CDN服务商有阿里云、腾讯云等。
这些服务商提供的CDN服务可以帮助网站实现静态资源的加速分发，从而提高网站的访问速度。
四、数据库优化数据库优化也是提高网站性能的关键之一。
在高并发的访问环境下，数据库的性能往往会成为瓶颈。
为了优化数据库的性能，可以采用如下几种方法：1、分库分表：将数据库的数据划分到多个表或者数据库中，从而提高数据库的性能。
2、索引优化：为数据库中经常使用的字段添加索引，避免频繁的全表扫描。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
高负载、高并发网站架构知识汇总-大流量网站架构的几点认识2009-03-04 11:04：硬架构1：机房的选择：在选择机房的时候，根据网站用户的地域分布，可以选择网通或电信机房，但更多时候，可能双线机房才是合适的。
越大的城市，机房价格越贵，从成本的角度看可以在一些中小城市托管服务器，比如说广州的公司可以考虑把服务器托管在东莞，佛山等地，不是特别远，但是价格会便宜很多。
2：带宽的大小：通常老板花钱请我们架构网站的时候，会给我们提出一些目标，诸如网站每天要能承受100万PV的访问量等等。
这时我们要预算一下大概需要多大的带宽，计算带宽大小主要涉及两个指标（峰值流量和页面大小），我们不妨在计算前先做出必要的假设：第一：假设峰值流量是平均流量的5倍。
第二：假设每次访问平均的页面大小是100K字节左右。
如果100万PV的访问量在一天内平均分布的话，折合到每秒大约12次访问，如果按平均每次访问页面的大小是100K字节左右计算的话，这12次访问总计大约就是1200K字节，字节的单位是Byte，而带宽的单位是bit，它们之间的关系是1Byte = 8bit，所以1200K Byte 大致就相当于9600K bit，也就是9Mbps的样子，实际情况中，我们的网站必须能在峰值流量时保持正常访问，所以按照假设的峰值流量算，真实带宽的需求应该在45Mbps 左右。
当然，这个结论是建立在前面提到的两点假设的基础上，如果你的实际情况和这两点假设有出入，那么结果也会有差别。
3：服务器的划分：先看我们都需要哪些服务器：图片服务器，页面服务器，数据库服务器，应用服务器，日志服务器等等。
对于访问量大点的网站而言，分离单独的图片服务器和页面服务器相当必要，我们可以用lighttpd来跑图片服务器，用apache来跑页面服务器，当然也可以选择别的，甚至，我们可以扩展成很多台图片服务器和很多台页面服务器，并设置相关域名，如 和，页面里的图片路径都使用绝对路径，如<img src="/abc.gif" />，然后设置DNS轮循，达到最初级的负载均衡。
当然，服务器多了就不可避免的涉及一个同步的问题，这个可以使用rsync软件来搞定。
数据库服务器是重中之重，因为网站的瓶颈问题十有八九是出在数据库身上。
现在一般的中小网站多使用MySQL数据库，不过它的集群功能似乎还没有达到stable的阶段，所以这里不做评价。
一般而言，使用MySQL数据库的时候，我们应该搞一个主从（一主多从）结构，主数据库服务器使用innodb 表结构，从数据服务器使用myisam表结构，充分发挥它们各自的优势，而且这样的主从结构分离了读写操作，降低了读操作的压力，甚至我们还可以设定一个专门的从服务器做备份服务器，方便备份。
不然如果你只有一台主服务器，在大数据量的情况下，mysqldump基本就没戏了，直接拷贝数据文件的话，还得先停止数据库服务再拷贝，否则备份文件会出错。
但对于很多网站而言，即使数据库服务仅停止了一秒也是不可接受的。
如果你有了一台从数据库服务器，在备份数据的时候，可以先停止服务（slave stop）再备份，再启动服务（slave start）后从服务器会自动从主服务器同步数据，一切都没有影响。
但是主从结构也是有致命缺点的，那就是主从结构只是降低了读操作的压力，却不能降低写操作的压力。
为了适应更大的规模，可能只剩下最后这招了：横向/纵向分割数据库。
所谓横向分割数据库，就是把不同的表保存到不同的数据库服务器上，比如说用户表保存在A数据库服务器上，文章表保存在B数据库服务器上，当然这样的分割是有代价的，最基本的就是你没法进行LEFT JOIN之类的操作了。
所谓纵向分割数据库，一般是指按照用户标识（user_id）等来划分数据存储的服务器，比如说：我们有5台数据库服务器，那么“user_id % 5 + 1”等于1的就保存到1号服务器，等于2的就保存到2好服务器，以此类推，纵向分隔的原则有很多种，可以视情况选择。
不过和横向分割数据库一样，纵向分割数据库也是有代价的，最基本的就是我们在进行如COUNT, SUM等汇总操作的时候会麻烦很多。
综上所述，数据库服务器的解决方案一般视情况往往是一个混合的方案，以其发挥各种方案的优势，有时候还需要借助memcached之类的第三方软件，以便适应更大访问量的要求。
如果有专门的应用服务器来跑PHP脚本是最合适不过的了，那样我们的页面服务器只保存静态页面就可以了，可以给应用服务器设置一些诸如之类的域名来和页面服务器加以区别。
对于应用服务器，我还是更倾向于使用prefork模式的apache，配上必要的xcache之类的PHP缓存软件，加载模块要越少越好，除了mod_rewrite等必要的模块，不必要的东西统统舍弃，尽量减少httpd进程的内存消耗，而那些图片服务器，页面服务器等静态内容就可以使用lighttpd或者tux来搞，充分发挥各种服务器的特点。
如果条件允许，独立的日志服务器也是必要的，一般小网站的做法都是把页面服务器和日志服务器合二为一了，在凌晨访问量不大的时候cron运行前一天的日志计算，不过如果你使用awstats之类的日志分析软件，对于百万级访问量而言，即使按天归档，也会消耗很多时间和服务器资源去计算，所以分离单独的日志服务器还是有好处的，这样不会影响正式服务器的工作状态。
二：软架构1：框架的选择：现在的PHP框架有很多选择，比如：CakePHP，Symfony，Zend Framework等等，至于应该使用哪一个并没有唯一的答案，要根据Team里团队成员对各个框架的了解程度而定。
很多时候，即使没有使用框架，一样能写出好的程序来，比如Flickr据说就是用Pear+Smarty 这样的类库写出来的，所以是否用框架，用什么框架，一般不是最重要，重要的是我们的编程思想里要有框架的意识。
现在的.NET框架有很多选择，比如：cnForums，.text，cs, Castle,等等2：逻辑的分层：网站规模到了一定的程度之后，代码里各种逻辑纠缠在一起，会给维护和扩展带来巨大的障碍，这时我们的解决方式其实很简单，那就是重构，将逻辑进行分层。
通常，自上而下可以分为表现层，应用层，领域层，持久层。
所谓表现层，并不仅仅就指模板，它的范围要更广一些，所有和表现相关的逻辑都应该被纳入表现层的范畴。
比如说某处的字体要显示为红色，某处的开头要空两格，这些都属于表现层。
很多时候，我们容易犯的错误就是把本属于表现层的逻辑放到了其他层面去完成，这里说一个很常见的例子：我们在列表页显示文章标题的时候，都会设定一个最大字数，一旦标题长度超过了这个限制，就截断，并在后面显示“..”，这就是最典型的表现层逻辑，但是实际情况，有很多程序员都是在非表现层代码里完成数据的获取和截断，然后赋值给表现层模板，这样的代码最直接的缺点就是同样一段数据，在这个页面我可能想显示前10个字，再另一个页面我可能想显示前15个字，而一旦我们在程序里固化了这个字数，也就丧失了可移植性。
正确的做法是应该做一个视图助手之类的程序来专门处理此类逻辑，比如说：Smarty 里的truncate就属于这样的视图助手（不过它那个实现不适合中文）。
所谓应用层，它的主要作用是定义用户可以做什么，并把操作结果反馈给表现层。
至于如何做，通常不是它的职责范围（而是领域层的职责范围），它会通过委派把如何做的工作交给领域层去处理。
在使用MVC架构的网站中，我们可以看到类似下面这样的URL：/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语句显然不属于领域层的范畴，也就是说，我们的领域逻辑泄露了。
所谓持久层，就是指把我们的领域模型保存到数据库中。
因为我们的程序代码是面向对象风格的，而数据库一般是关系型的数据库，所以我们需要把领域模型碾平，才能保存到数据库中，但是在PHP里，直到目前还没有非常好的ORM出现，所以这方面的解决方案不是特别多，参考Martin的企业应用架构模式一书，大致可以使用的方法有行数据入口（Row Data Gateway）或者表数据入口（Table Data Gateway），或者把领域层和持久层合二为一变成活动记录（Active Record）的方式。