网站架构演化

 

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.一、www.mysite.com IN A 114.100.80.二、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。