http://www.ha97.com/5095.html
说到大型网站，就得先说大型网站的特点：高并发、大流量、高可用、海量数据等。下面就说说大型网站的架构演化过程吧。
1. 初始阶段的网站架构
初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图：
2. 应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图：
3. 使用缓存改善网站性能
毫无疑问，现在的网站基本上都会使用缓存，即：80%的业务访问都会集中在20%的数据上。
4. 使用应用服务器集群改善网站的并发处理能力
因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。因此使用负载均衡处理器势在必然。通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。
5. 数据库读写分离
当用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。而目前主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库的数据更新同步到另一台服务器上。网站利用数据库这一功能实现数据库读写分离，从而改善数据库负载压力。
6. 使用反向代理和CDN加上网站相应
提高网站的访问速度，主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理是部署在网站的中心机房，当用户请求到达中心机房后，首先访问的反向代理，如果反向代理缓存着用户请求的资源，则直接返回给用户。
7. 使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。
分布式数据库时网站数据库拆分的最后手段，只用在单表数据规模非常大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务拆分，将不同业务的数据部署在不同的物理服务器上。
8. 使用NoSQL和搜索引擎
搜素引擎也基本已经形成现在大型网站必须提供的功能了，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。
9. 业务拆分
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将真个网站业务拆分成不同的产品线。
具体到技术上，也会根据产品线话费，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过超链接建立管理，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
10. 分布式服务
由于每一个应用系统都需要执行许多相同的业务操作，比如用户管理，session管理，那么可以将这些公用的业务提取出来，独立部署。
每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作。
所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。为此，在实践中提出了许多解决方案，以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。
1. 分层
分词是企业应用系统中最常见的一种架构牧师，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。
在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。应用层具体负责业务和视图的展示；服务层为应用层提供服务支持；数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。
2. 分隔
如果说分层是将软件在横向方面进行切分，那么分隔就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分隔的粒度可能会很小。比如在应用层，将不同业务进行分隔，例如将购物、论坛、搜索、广告分隔成不同的应用，有对立的团队负责，部署在不同的服务器上。
3. 分布式
对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
在网站应用中，常用的分布式方案有一下几种.
分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如js、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
4. 集群
对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可；另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
5. 缓存
缓存目的就是减轻服务器的计算，使数据直接返回给用户。在现在的软件设计中，缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。
使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中；数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。
6. 异步
使用异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步执行进行协作。
具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。
异步架构的典型就是生产者消费者方式，两者不存在直接调用。
7. 冗余
网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。
8. 自动化
具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。
9. 安全
网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证；登录、交易需要对网络通信进行加密；为了防止机器人程序滥用资源，需要使用验证码进行识别；对常见的XSS攻击、SQL注入需要编码转换；垃圾信息需要过滤等。
所谓架构，一种通俗的说法就是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。
而软件架构即“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各方面的设计”。一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。
1. 性能
性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题。也正因为性能问题几乎无处不在，所以优化网站性能的手段也非常多：
浏览器端：可以通过浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输等手段，甚至可以使用CDN加速功能。
应用服务器端：可以使用服务器本地缓存和分布式缓存，也可以通过异步操作方式来加快响应，在高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。
数据库服务器端：可用使用索引、缓存、SQL性能优化等手段，还可以使用NoSQL数据库来优化数据模型、存储结构等。
衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过这些指标以确定系统设计是否达到目标。
2. 可用性
可用性即能够不间断提供服务的时间。几乎所有网站都承诺7×24小时可用，但事实上任何网站都不可能达到完全的7×24，总会有一些故障时间，扣除这些故障时间，就是网站的可用时间。一些大型网站可以做到4个9以上的可用性，也就是99.99%。
网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份，任何一台服务器都不会影响应用的整体可以，通常的实现手段即把多台服务器通过负载均衡设备组成一个集群。
衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。
3. 伸缩性
大型网站需要面对大量用户的高并发访问和存储海量数据，网站通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断整体上市用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总服务器数量是否有限制。
4. 扩展性
不同于其他架构要素主要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目标。
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不同产品之间是否很少耦合等。
网站可扩展架构的主要手段是事件驱动架构和分布式服务。
事件驱动通常利用消息队列实现，通过这种方式将消息生产和处理逻辑分隔开。
服务器服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增加产品可用通过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。
5. 安全性
互联网是开发的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击和窃密手段，是否有可靠的应对策略。
网站性能是客观的指标，可以具体体现到响应时间、吞吐量、并发数、性能计数器等技术指标。
1. 性能测试指标
1.1 响应时间
指应用执行一个操作需要的时间，指从发出请求到最后收到响应数据所需要的时间。如下列出了系统常用的操作响应时间表。
操作
响应时间
打开一个网站
几秒
数据库查询一条记录（有索引）
十几毫秒
机械磁盘一次寻址定位
4毫秒
从机械磁盘顺序读取1M数据
2毫秒
从SSD磁盘顺序读取1M数据
0.3毫秒
从远程分布式换成Redis读取一个数据
0.5毫秒
从内存读取1M数据
十几微妙
Java程序本地方法调用
几微妙
网络传输2Kb数据
1微妙
实践中计算响应时间通常是通过平均时间计算的平均值。
1.2 并发数
指系统能够同时处理的请求的数目，这个数字也反映了系统的负载性能。对于网站而言，并发数指网站用户同时提交请求的用户数目。
网站系统用户数>网站在线用户数>网站并发用户数
1.3 吞吐量
指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可用“请求数/秒”或“页面数/秒”或“访问人数/天”或“处理业务数/小时”等来衡量。
TPS(每秒事物数)是吞吐量的一个常用量化指标。刺猬还有HPS（每秒HTTP请求数）、QPS(每秒查询数)。
1.4 性能计数器
指操作系统的一些数据指标如System load(系统负载)，CPU使用率、内存使用率、磁盘等使用情况。
2. 性能优化策略
根据网站分层架构，可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化。
2.1 Web前端优化
2.1.1 浏览器访问优化
减少HTTP请求数,主要可通过合并CSS，JavaScript、图片。
使用浏览器端缓存。在某些时候，静态资源文件编写需要及时应用到客户端浏览器，这种情况下，可通过改变文件名来实现。
启用页面压缩，文本文件的压缩效率可达80%以上。
CSS放在页面最上面，JavaScript放在页面最下面
减少Cookie传输。可以考虑使用独立域名来发送Cookie等。
2.1.2 CDN加速
CDN的本质仍然是一个缓存，只是部署在离用户最近的服务器上，一般缓存的都是静态资源。
2.1.3 反向代理
除了能够保护网站安全的作用以及负载均衡的作用外，反向代理还能够提供缓存作用(动态资源)。
2.2 应用服务器性能优化
应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，主要优化手段有缓存、集群、异步等。
2.2.1 分布式缓存
缓存主要用来存放哪些读写比很高、很少变化的数据。
分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其具体架构有两种，一种是以JBoss Cache伪代码的需要更新同步的分布式缓存， 一种是以Memcached为代表的不互相通信的分布式缓存。
Jboss Cache 的分布式缓存在集群中的所有服务器中保存相同的缓存数据，当某台服务器有缓存更新的时候，会通知集群中其他机器跟新缓存数据。优点是应用程序可以 从本地快速的获取缓存数据，但当集群规模较大的时候，缓存更新信息需要通过到集群所有机器，其代价可想而知。
大型网站需要的缓存数据一般都很大，可能会有TB的内存占用，这时候就的使用Memcached，是一中互不通信的架构，每台存储的缓存数据可以不一样。
2.2.2 异步操作
为了改善网站的扩展性，可以使用消息队列将调用异步化。
2.2.3 使用集群
在网站高并发访问的情况下，使用负载均衡技术为一个应用构建一个由多台服务器组成的集群，将并发访问请求分发到多台服务器上处理。
2.2.4 代码优化
代码优化主要涉及多线程、资源复用（对象池或单例）、数据结构和垃圾回收。
2.3 存储性能优化
可以考虑使用分布式存储、openfiler、磁盘阵列、HDFS（Hadoop）。
网站的可用性（Avaliability）描述网站可有效访问的特性。
1. 网站可用性的度量与考核
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度不可用时间=（1-网站不可用时间/年度时间）× 100%
可用性指标时网站架构设计的重要指标，对外是服务承诺，对内是考核指标，具体到每个工程师，更多的是使用故障分。
所谓故障分是指对网站故障进行分类加权计算故障责任的方法。如下是个案例：
分类
描述
权重
事故级故障
严重故障，网站整体不可用
100
A类故障
网站访问不顺畅或核心功能不可用
20
B类故障
非核心功能不可用，或核心功能少数用户不能访问
5
C类故障
其他故障
1
故障分的计算公式为：
故障分=故障时间（分钟）* 故障权重
2. 网站的高可用架构
一个典型的网站设计通常遵循如下图所示的基本分层模型。
在负载的大型网站架构中，划分的粒度会更小，更详细，但通常还是能够把这些服务器划分到这三层中。
对于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同 对外提供服务，当负载均衡设备通过心跳检测到某台服务器不可用时，就将其从集群列表中提出，并将请求分发到集群中其他 可用的服务器上，是整个集群保存可用，从而实现应用高可用。
位于服务层的服务器情况和应用层类似，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问， 分布式服务调度框架会在应用层客户端中实现负载均衡功能。
位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。
网站升级的频率一般都非常高，每次网站发布都需要关闭服务，重新启动系统，相当于服务器宕机。因此网站的可用性架构还需要考虑到网站升级 发布引起的宕机。
3. 高可用的应用
应用层主要处理网站应用的业务逻辑，也称为业务逻辑层，应用的一个显著特点就是应用的无状态行，因此实现负载均衡相对简单一点。
Web应用中将这些多次请求的上下文称为回话（Session），在单机情况下，session可部署在服务器上的Web容器上管理。在使用负载均衡 的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的session比单机 时要复杂的多。在集群环境下，session管理主要有 以下手段。
3.1 Session复制
Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能，在集群中几台服务器之间同步Session对象，是每台服务器上都保存所有用户的Session信息。
这种方案虽然简单，从本机读取Session信息也很快，但当集群规模比较大的时候会占用服务器和网站的大量资源，在大量用户访问的情况下，甚至会出现内存不够Session使用的情况。
3.2 Session绑定
Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。这样在整个回话期间，用户所有的请求都在同一天服务器上处理，即Session绑定到某台特定的服务器上，保证Session总能在这台服务器上获取，这种方法有成为回话粘滞。
3.3 利用Cookie记录Session
一种管理Session的方式是将Session记录在客户端，每次请求服务器的时候，将Session放在请求中发送给服务器，服务器处理完请求后再将修改后的Session响应给客户端。
3.4 Session服务器
Session服务器，即把session的管理独立部署在某一台机器上，Web服务器不保存用户Session信息，每次都去Session服务器取数据。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。对于有状态的Session服务器，一种比较简单的方式是利用分布式缓存、数据库等。
4. 高可用的服务
可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，是无状态的，因此可以使用类似负载均衡的失效转移策略实效高可用的服务。
除此之外，在实践中，还有一些几点高可用的服务策略。
分级管理
超时设置
异步调用
服务降级，网站高峰期间，可以关闭一些不重要的服务，如评论。
5. 高可用的数据
保证数据存储高可用的手段主要是数据备份和失效转移机制。
CAP原理：即数据持久性、数据可访问性、数据一致性。
6. 高可用的网站质量保证
这里主要说下网站发布流程吧。看图即可：
7. 网站运行监控
“不允许没有监控的系统上线”。网站运行监控对于网站运维和架构设计优化至关重要，运维没有监控的网站，犹如驾驶没有仪表的飞机。
具体到监控哪些数据，主要有：
用户行为日志收集（服务器端和浏览器端）
服务器性能监控（CPU、内存等）
运行数据监控（缓存命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等）
监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。
网站系统的伸缩性架构最重要的技术手段就是使用服务器集群功能，通过不断地向集群中添加服务器来增强整个集群的处理能力。“伸”即网站的规模和服务器的规模总是在不断扩大。
1. 网站架构的伸缩性设计
网站的伸缩性设计可以分成两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的 功能；后者是集群内的多台服务器部署相同的服务，提供相关的功能。
1.1 不同功能进行物理分离实现伸缩
纵向分离：即分层后分离，将业务处理流程上的不同部分分离部署，实现系统伸缩性。
横向分离：即分割业务后分离，将不同的业务模块分离部署，实现系统伸缩性。
1.2 单一功能通过你集群规模实现伸缩
当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。
集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。数据服务器集群也可分为缓存数据服务器集群和存储数据服务器集群。
2. 应用服务器集群的伸缩性设计
所谓应用服务器的伸缩性即：HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求 ，停止向已下线的服务器分发请求。这个HTTP请求分发装置被称为负载均衡服务器。
负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性，可谓网站的杀手锏之一。具体的技术实现也多种多样，从硬件实现到软件实现， 从商业产品到开源，应有尽有，但实现负载均衡的基础技术不外以下几种。
2.1 HTTP重定向负载均衡
HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的服务器地址，并将真实的服务器地址写入HTTP重定向响应中（响应状态吗302）返回给浏览器，然后浏览器再自动请求真实的服务器。
这种负载均衡方案的优点是比较简单，缺点是浏览器需要每次请求两次服务器才能拿完成一次访问，性能较差；使用HTTP302响应吗重定向，可能是搜索引擎判断为SEO作弊，降低搜索排名。重定向服务器自身的处理能力有可能成为瓶颈。因此这种方案在实际使用中并不见多。
2.2 DNS域名解析负载均衡
利用DNS处理域名解析请求的同时进行负载均衡是另一种常用的方案。在DNS服务器中配置多个A记录，如：www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.
每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。
DNS域名解析负载均衡的优点是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录，不受网站控制。
事实上，大型网站总是部分使用DNS域名解析，作为第一级负载均衡手段，然后再在内部做第二级负载均衡。
2.3 反向代理负载均衡
前面我们已经讲过，反向代理可以缓存资源，改善网站性能，事实上，反向代理业可以做负载均衡，如图所示。
由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。优点是部署简单，缺点是可能成功系统的瓶颈。
2.4 IP负载均衡
IP负载均衡：即在网络层通过修改请求目标地址进行负载均衡。
用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进行获取网络数据包，根据负载均衡算法计算得到一台真实的WEB服务器地址，然后将数据包的IP地址修改为真实的WEB服务器地址，不需要通过用户进程处理。真实的WEB服务器处理完毕后，相应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。
这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。
IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。
2.5 数据链路层负载均衡
顾名思义：数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡，如下图：
这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样，从而达到负载均衡，这种负载均衡方式又称为直接路由方式（DR）。
在上图中，用户请求到达负载均衡服务器后，负载均衡服务器将请求数据的目的mac地址修改为真是WEB服务器的mac地址，并不修改数据包目标IP地址，因此数据可以正常到达目标WEB服务器，该服务器在处理完数据后可以经过网管服务器而不是负载均衡服务器直接到达用户浏览器。
使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。
2.6 负载均衡算法
负载均衡服务器的实现可以分成两个部分：
根据负载均衡算法和WEB服务器列表计算得到集群中一台WEB服务器的地址；
将请求数据发送到改地址对应的WEB服务器上。
常用的负载均衡算法如下几种：
轮询：即将请求依次分发到每台应用服务器上。
加权轮询：根据应用服务器硬件性能情况，在轮询的基础上，安装配置的权重将请求分发到每个服务器。
随机：将请求随机分配到各个应用服务器。
最少连接：记录每个服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上。
原地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址请求总在同一个服务器上处理。
3. 分布式缓存集群的伸缩性设计
分布式缓存服务器集群中不同服务器中缓存的数据不相同，缓存访问请求不可用在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。 这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
分布式缓存集群伸缩性设计的最主要目标即：必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据 尽可能还被访问到。
3.1 memcached分布式缓存集群访问模型
3.2 分布式缓存的一致性Hash算法
一致性hash算法通过一个叫做一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射，如下图：
如果使用上面数据结构的话，那么当新添加一台缓存服务器时，只是影响到了其中一台缓存服务器，其他两头缓存服务器的压力并没有得到缓解，因此此方案还是存在问题。 一种替代的方案就是增加一个虚拟层，即把每台缓存服务器虚拟为一组服务器（比如3个虚拟网元）平均放到上面的环里面。这样当新增加缓存服务器时，把新增加的虚拟网元平均分配 到环中，这样就能缓解每台缓存服务器，达到分布式缓存集群高伸缩性。
4. 数据存储服务器集群的伸缩性设计
和缓存服务器集群的伸缩性设计不同，数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。具体来说，又可分为关系数据库集群的伸缩性设计和NoSQL数据库的伸缩性设计。
4.1 关系数据库集群的伸缩性设计
主要的关系数据库都支持数据复制功能，使用这个功能可以对数据库进行简单伸缩。
另外除了利用数据库主从读写分离外，也可以利用业务分隔模式使不同业务的数据表部署在不同的数据库集群上，即俗称的数据分库。但是这种方式的制约条件时跨库不能进行join操作。
在大型网站的实际应用中，即使使用了分库和主从复制，对一些单表数据任然很大的表还需要进行分片，将一张表拆开分别存储在多个数据库中。
目前支持分布式数据分片的关系数据库产品主要有开源的Amoeba和Cobar（阿里巴巴），下图为Cobar部署模型。
Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同 的数据库实例上执行（每个MySQL实例都部署为主/从结构，保证数据高可用）。
Cobar系统组件模型如下图：
前端通信模块负责和应用程序通信，接搜到SQL请求（select * from users where userid in (12,22,23)）后转交给SQL解析模块，SQL解析模块解析获得SQL中的路由规则查询条件（userid in （12,22,23））再转交给 SQL路由模块，SQL路由模块根据路由规则配置（userid为偶数路由至数据库A，奇数则路由至数据库B）将应用程序提交的SQL分解成两条SQL(select * from users where userid in (12,22)；select * from users where userid in (23))转交给SQL执行代理模块，发送至数据库A和数据库B分别执行。 数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并模块将两个返回结果集合并成一个结果集，最终返回该应用程序，完成在分布式关系数据库中的一次访问请求。
Cobar的伸缩有两点：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
Cobar服务器可以看做是无状态的应用服务器，因此其集群伸缩可以简单实用负载均衡的手段实现。而MySQL中存储着数据，要保证集群扩容后数据一致负载均衡，必须要做数据迁移，如下图（利用数据同步功能进行数据迁移）。
4.2 NoSQL数据库的伸缩设计
NoSQL主要是指非关系的、分布式的数据库设计模式。一般而言，NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事物一致性保证（ACID），而强化了高可用性和可伸缩性。目前应用最广泛的是Apache Hbase。
