分布式知识

一、大型网站架构演化发展历程

1.初始阶段的网站架构

大型网站都是从小型网站发展来的，网站架构也是一样，从小型网站架构逐步演化而来的。小型网站最开始没有多少人访问，只需要一台服务器就绰绰有余。应用程序、数据库、文件等所有资源都在一台服务器上。

2.应用服务和数据服务分离

随着业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。这时候就需要将应用和数据分离。应用和数据分离后整个网站使用三台服务：应用服务器、文件服务器和数据库服务器，三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更大的CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的磁盘和更大的内存；文件服务器需要大量的用户上传的文件，因此需要更大的磁盘。

3.使用缓存改善网站性能

网站的访问特点一样遵循二八定律:80%的业务访问集中在20%的数据上。只需要将这20%的数据缓存在内存中就能减少数据库的访问压力，提高网站的访问速度。

网站使用的缓存可分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地的访问要更快一些，但是受应用服务器内存的限制，其缓存数据量有限，而且会出现和应用服务器争内存的情况。远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论 上做到不受内存容量限制的缓存服务。

4.使用应用服务器集群改善网站的并发处理能力

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有的服务器的访问及存储压力。

5.数据库读写分离

网站在使用缓存后，使绝大部分数据读写操作访问都可以不通过数据库就能完成，但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库，在网站的用户达到一定的规模之后，数据库因为负载压力过高而成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库的读写分离，从而改善数据库负载压力。

应用服务器在写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获取数据。

6.使用反向代理和CDN加速网站响应

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则是部署在网络的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

使用CDN和反向代理的目的都是尽早的返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

7.使用分布式文件系统和分布式数据库系统

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

8.使用NoSQL和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。

NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

9.业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成了不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

10.分布式服务

随着业务拆分的越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有的应用和所有的数据库连接，在数万台服务器规模的网站中，这些连接数目是服务器规模的平方，导致数据连接资源不足，拒绝服务。

既然每个应用系统都要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可以复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用业务服务完成具体业务操作。

二、大型网站的架构模式

每个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。即针对典型问题的解决方案。

1.分层

分层是企业应用系统中最常见的架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

在大型网站架构中采用分层的结构，将网站软件系统分为应用层、服务层、数据层。应用层，负责具体业务和视图展示，如网站首页及搜索输入和结果展示。服务层，为应用层提供服务支持，如用户管理服务，购物车服务等。数据层，提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。

分层架构是逻辑上的，在物理部署上，三层结构可以部署在同一个物理机器上，但是随着网站业务发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，使网站拥有更多的计算机资源以应对越来越多的用户访问。

虽然分层架构模式最初的目的是规划软件清晰的逻辑结构便于开发维护，但是在网站的发展中，分层结构对网站支持高并发向分布式方向发展至关重要。因此在网站规模还很小时，就应该采用分层的架构，这样将来网站做大时才能更好的应对。

2.分割

如果说分层是将软件在横向上切割，那么分割就是在纵向上对软件进行切分。

网站越大，功能越复杂，服务和数据处理的种类也就越多，将这些不同功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面便于不同模块的分布式部署，提高网站的并发能力和功能扩展能力。

3.分布式

对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同的模块部署在不同的服务器上，通过远程协调工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

分布式在解决网站高并发的问题的同时也带来了其他的问题。首先，分布式意味着服务调用 必须通过网络，这可能会对性能造成比较严重的影响；其次服务器越多服务器宕机的概率也就越大，一台服务器宕机造成的服务不可用会导致很多应用不可访问，使网站的可用性降低；另外，数据在分布式的环境中保持数据一致性也非常困难，分布式事务也很难保证，这对网站业务正确性和业务流程有可能造成很大的影响。因此分布式设计要根据具体情况量力而行，切莫为了分布式而分布式。

常用的分布式方案有以下几种:

分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；还可以使不同应用的服务复用共同的服务，便于业务功能扩展。

分布式静态资源:网站的静态资源如JS、CSS，Logo图片等资源独立分布式部署，并采用独立的域名，动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。

分布式数据和存储:大型网站需要处理P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据需要分布式存储。除了对传统的关系数据库进行分布式部署外，为网站应用而生的各种NoSQL产品几乎都是分布式的。

分布式计算:网站除了要处理应用、服务这些在线业务，还有一部分用户没有直观感受的后台业务要处理，包括搜索引擎的索引构建、数据仓库的数据分析统计等。这些业务的计算规模非常庞大，目前用Hadoop及其MapReduce分布式计算框架进行此类批处理计算，将计算程序分发到数据所在的位置以加速计算和分布式计算。

4.集群

分布式指将不同的业务分布在不同的地方，而集群指的是将几台服务器集中在一起，实现同一个业务。

使用分布式虽然将分层和分割后的模块独立部署，但对于用户访问集中的模块，还需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。

因为服务器集群有更多服务器提供相同的服务，因此可以提供很好的并发特性，当更多的用户访问时，需要向集群中加入新的机器即可。同时因为一个应用由于多台服务器提供，当某台服务器发生故障时，负载均衡设备或者系统失效转移机制会将请求转发到集群中其他服务器上，使服务器故障不影响用户使用。

5.缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站构架设计在很多方面使用了缓存设计。

CDN:即内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商那里，在这里缓存网站的一些静态资源，可以就近以最快的速度返回到用户，如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN。

反向代理:反向代理属于网站前端框架的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问的是反向代理服务器，这里缓存网站的静态资源，无需将请求继续转发应用服务就能返回给用户。

本地缓存:在应用服务器本地缓存着热点数据，应用程序可以在本地内存中直接访问数据，而无需访问数据库。

分布式缓存:大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单机能承受的，所以除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

使用缓存有两个前提条件，一是数据访问热点不均衡，某些数据会更频繁的访问，这些数据应该放在缓存中；二是数据在某一个时间段内有效，不会很快过期，否则缓存的数据就会因失效而产生脏读，影响结果的正确性。

6.异步

同步：是所有的操作都做完，才返回给用户结果。

异步：不用等所有操作等做完，就相应用户请求。

大型网站构架中，系统解耦合的手段除了前面提到的分层、分割、分布等，还有个重要的手段就是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段通过共享数据的方式异步执行进行协作。

在单一的服务器内部可通过多线程共享内存队列的方式实现异步，处于业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；在分布式系统中，多个服务器集群通过消息队列实现异步，分布式消息队列可以看成内存队列的分布式部署。

异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构的不练，彼此功能实现可以随意的变化互不影响，这对网站扩展新功能非常便利。

7.冗余

访问和负载很小的服务也必须要部署至少两台的服务器构成集群，其目的就是通过冗余实现服务高可用。数据库除了定期备份，存档保存，实现冷备份之外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。

三、大型网站核心架构要素

一般来说，除了当前的系统功能需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素，架构设计过程中需要平衡这5个要素之间的关系以实现需求和架构目标。

1.网站的高性能架构

性能优化分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化。

(1)Web前端优化

Web前端优化又可分为优化浏览器访问、CDN、使用反向代理等。

浏览器访问优化：

1.减少http请求: HTTP协议是无状态的应用层协议，意味着每次HTTP请求需要建立通信链路、进行数据传输，而在服务器端，每个HTTP都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵，减少HTTP请求的数目课有效提高访问性能。**减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。**将浏览器一次访问需要的JavaScript、CSS合并成一个文件，这样浏览器就只需要一次请求。图片也可以合并，多张图片合并成一张，如果每张图片都有一个不同的超链接，可以通过CSS偏移响应鼠标点击操作，构造不同的URL。

2.**使用浏览器缓存 **:通过设计HTTP头中的Cache-Control和Expires的属性，可以设定浏览器中的缓存。在某些时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况，可通过改变文件名实现。

3.启用压缩:在服务端对文件进行压缩，在浏览器端对文件解压缩，可有效减少通信传输的数据量。文本的文件的压缩效率可达80%以上，因此HTML、CSS、JavaScript文件启用GZip压缩可达到较好的效果。但是压缩对服务器和浏览器产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑。

4.CSS放在页面最上面、JavaScript放页面最下面:浏览器在下载完全部的CSS之后才对整个页面进行渲染，因此最好的做法就是将CSS放在页面最上面，让浏览器尽快下载CSS。JavaScript则相反，浏览器在加载JavaScript后立即执行，可能会阻塞整个页面，造成页面显示缓慢，因此JavaScript最好放在页面最下面。但如果页面解析时，需要用JavaScript，这时放在底部就不合适了。

5.减少Cookie传输:一方面Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输，因此尽量减少Cookie中传输的数据量。另一方面，对于某些静态资源的访问，如CSS、JavaScript等，发送Cookie没有意义，可以考虑静态资源使用独立域名访问，避免请求资源时，发送Cookie，减少Cookie传输的次数。

CDN加速：

CDN的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户最快速度获取数据，即所谓网络访问第一跳。由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，因此用户请求路由的第一跳就到达了CDN服务器，当CDN中存在浏览器请求的资源时，从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度，减少数据中心负载压力。CDN能够缓存的一般是静态资源，如图片、文件、CSS、Script脚本、静态网页。但是这些文件访问频度很高，将其缓存在CDN可以极大的改善网页的打开速度。

反向代理：

传统代理服务器位于浏览器一侧，代理服务器将HTTP请求发送到互联网上，而反向代理位于网站机房一侧，代理网站Web服务器接收HTTP请求。

和传统代理服务器可以保护浏览器安全一样**，反向代理服务器可具有保护网站完全的作用**，来自互联网的访问请求必须经过代理服务器，相当于Web服务器和可能的网络攻击之间建立了一个屏障。

除了安全功能，代理服务器也可以通过配置缓存功能加速Web请求。当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器返回，加速Web请求响应速度，减轻Web服务器负载压力。事实上，有些网站会把动态内容缓存在代理服务器上，比如维基百科及某些博客论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速用户访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的内容再次缓存起来。

此外，反向代理还可以实现负载均衡的功能，而通过负载均衡的应用集群可以提高系统总体处理能力，进而改善网站高并发的情况下的性能。

(2)应用服务器性能优化：

应用服务器优化手段主要有：缓存、集群、异步等。

缓存：

网站性能优化第一定律：优先考虑使用缓存优化性能。

分布式缓存指：部署在多个服务器组成的集群中，以集群的方式提供缓存服务，其架构的方式有两种，一种以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Mencached为代表的不相互通信的分布式缓存。

JBoss Cache的分布式缓存在集群中所有服务器上保存相同的缓存数据，当某台服务器有缓存数据更新时，会通知集群中其他机器更新缓存数据或者清除缓存数据，如果本地快速获取缓存数据，但是这种方式带来的问题是缓存数据的数量受限于单一服务器的内存空间，而且当集群规模较大的时候，缓存更新信息需要同步到集群的所有机器，其代价惊人。因此很少在大型网站使用。

Mencached采用一种集中式的缓存集群管理，也被称为互不通信的分布式架构方式。缓存和应用分离部署，缓存系统部署在一组专门的服务器上，应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模可以很容易地实现扩容，具有良好的可收缩性。

集群：

在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，并将并发访问请求分发带多台服务器上处理，使用户请求具有更好的响应延迟特征。

异步：

消息队列具有很好地削峰作用——及通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。

2.网站的高可用架构

网站的可用性描述网站可有效访问的特性。

高可用的架构：

大型网站的分层架构及物理服务器的分布式部署使得不同层次的服务器具有不同的可用性特点。关闭服务或者服务器宕机时产生的影响也不相同，高可用的解决方案也差异甚大。

位于应用层的服务器通常是为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用。

位于服务层的服务器情况和应用层的服务器类似，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测，发现有服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用的服务器。

位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器宕机时，数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。

下面会对这三层的具体情况进一步解释：

高可用的应用：

1.通过负载均衡进行无状态服务的失效转移

负载均衡在应用层实际上起到了系统高可用的作用，因此即使某个应用访问量非常少，只用一台服务器提供服务就绰绰有余，但如果需要保证该服务的高可用，也必须至少部署两台服务器，使用负载均衡技术构建一个小型的集群。

2.应用服务器集群的Session管理

应用服务器的高可用架构设计主要基于服务这无状态这一特性，但事实上，业务总是有状态的，在交易类的电子商务网站，需要购物车记录用户的购买信息。Web应用中将这些多次请求修改使用的上下文对象称作会话，单机情况下，Session可由部署在服务器上的Web容器管理。在使用负载均衡的集群环境之中，由于负载均衡服务器可能会将请求分发到集群中的任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。

集群环境下，Session管理主要有以下几种手段。

1.Session复制：

Session复制是早期企业应用系统应用比较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息。而大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此并不适用这种方案。

2.Session绑定

Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取，这种方法又被称为会话粘滞。但是Session绑定的方案不符合我们对系统高可用的需求。

3.利用Cookie记录Session

可以利用浏览器支持的Cookie记录Session。但是会有一些缺点，比如Cookie大小限制，能记录的信息有限；每次请求响应都需要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常。许多网站或多或少地使用Cookie记录Session。

4.Session 服务器

利用独立部署的Session服务器统一管理Session，应用服务器每次读写Session时，都访问Session服务器。这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。

对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存，数据库等，在这些产品的基础上进行包装，使其符合Session的存储和访问要求**(未进行包装的一般是存入服务器所在机器的内存中，我们可以将其存入Redis集群中)**。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录、用户服务等功能，则需要开发专门的Session服务管理平台。

高可用的服务：

可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体的应用调用。可复用的服务和应用一样，也是无状态的服务，因此可以使用类似负载均和的失效转移策略实现实现高可用的服务。除此之外，以下还有几点高可用的服务策略。

1.分级管理：

将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。

2.超时设置：

在应用程序中设置服务调用的超时时间，一旦超过，通信框架就抛出异常。应用程序根据服务调度策略，可选择继续重试或者请求转移到提供相同的服务的其他服务器上。

3.异步调用：

应用对服务器的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

4.服务降级：

在网站访问的高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。

拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用，或者随机拒绝部分请求调用，节约资源。

关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。

5.幂等性设计：

服务重复调用是无法避免的，应用层也不需要关心服务是否真的失败，只要没有收到调用成功的响应，就可以认为是调用失败，并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果是相同的，即服务具有幂等性。

高可用的数据：

保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。而数据转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统的可用性。

关于缓存服务的高可用，在实践中争议很大，一种观点认为缓存已经成为网站数据服务的重要组成部分，事实上承担了业务中绝大多数的数据读取访问服务，缓存服务失效可能会导致数据库负载过高而宕机，进而影响整个网站的可用性，因此缓存服务需要实现和数据存储服务同样的高可用。另一种观点则认为缓存服务不是数据存储的服务，缓存服务器宕机引起缓存数据丢失导致服务器负载压力过高应该通过其他手段解决，而不是提高缓存服务本身的高可用。

CAP原理：

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)
、数据可用性(Availability)、分区耐受性(Partition Tolerance，系统具有跨网络分区的伸缩性)这三个条件。

3.网站的收缩性架构

所谓网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。

一般来说，网站的伸缩性设计可以分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能；后者是集群内多台服务器部署相同的服务，提供相同的功能。

不同的功能进行物理分离实现伸缩：

网站发展早期——通过增加服务器 提高网站处理能力时，新增服务器总是从现有的服务器中分离出部分功能和服务。每次分离总会有更多的服务器加入网站，使用新增的服务器处理某种特定服务，通过物理上分离不同的网站功能，实现网站伸缩性的手段，不仅可以在网站发展早期使用，而且可以在网站发展的任何结点使用。具体又可分为如下两种情况：

纵向分离(分层后分离)：将业务处理流程上的不同部分分离部署，实现系统伸缩性。

横向分离(业务分割后分离)：将不同的业务模块分离部署，实现系统伸缩性。

单一功能通过集群规模实现伸缩：

集群伸缩性又可分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群由于数据状态管理的不同，技术实现也有非常大的区别。而数据服务器集群分为缓存数据服务器集群和存储数据服务器集群，这两种集群的伸缩性设计也不大相同。

应用服务器集群的伸缩性设计：

如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或者下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。这个HTTP请求的分发装置被称作负载均衡服务器。

实现负载均衡的技术不外以下几种：

1.HTTP重定向负载均衡：

HTTP重定向服务器是一台普通的服务器，其唯一的功能是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中返回给用户浏览器。例：浏览器访问域名www.mysite.com,DNS解析得到IP地址是114.100.80.10，即HTTP重定向服务器的IP地址。然后浏览器通过IP地址114.100.80.10访问HTTP重定向负载均衡服务器后，服务器根据某种负载均衡算法计算获得一台实际物理服务器的地址(114.100.80.3)，构造一个包含该实际物理服务器地址的重定向响应返回给浏览器，浏览器重新请求实际物理服务器的IP地址114.100.80.3，完成访问。

这种负载均衡方案的优点是比较简单，缺点是浏览器需要两次请求浏览器服务器才能完成一次访问，性能比较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限。

2.DNS域名解析负载均衡：

利用DNS处理域名解析请求的同时进行负载均衡处理的一种方案。每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回。DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省下了网站的管理维护负载均衡服务器的麻烦。

事实上，大型网站总是部分使用DNS域名解析，利用域名解析为第一级负载均衡手段，即域名解析得到的一组服务器并不是提供Web服务物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真实的Web服务器中。

3.反向代理负载均衡(应用层负载均衡)：

由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能会成为瓶颈。

4.IP负载均衡：

在网络层通过修改请求目标地址进行负载均衡。IP负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。所有的请求响应数据都会到达负载均衡服务器。

5.数据链路层负载均衡：

数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。用户的请求到负载均衡服务器后，负载均衡服务器将请求mac地址改为应用服务器中的一台，Web服务器集群中的所有服务器虚拟IP和负载均衡服务器的IP地址相同，因此数据可以正常传输到mac地址对应的服务器中，改服务器处理完之后会发生响应数据到网站的网关服务器，网关服务器直接将该数据包发送到用户浏览器，响应数据不需要负载均衡。

负载均衡算法：

负载均衡服务器的实现可以分为两个部分：

1.根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。

2.将请求数据发送到数据发送到Web服务器，而具体的负载均衡算法通常有以下几种：

（1）轮询：将所有的请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务硬件都相同的场景。

（2）加权轮询：在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多的请求。

（3）随机：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以使用加权随机算法。

（4）最少连接：记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最少连接。

（5）源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会化周期内重复使用，从而实现会话黏滞。

分布式缓存集群的伸缩性设计

本来加入新的缓存服务器是为了降低数据库的负载压力，但操作不当却导致了数据库的崩溃。

一种解决方法是在网站访问量最少的时候扩容缓存服务器集群，这时候对数据库的负载冲击最小。然后通过模拟请求的方法逐渐预热缓存，使缓存服务器中的数据重新分布。这种方案对业务场景有要求。

还有一种就是一致性Hash算法。一致性Hash算法通过一个叫作一致性Hash环的数据结构实现KEY到缓存服务器的映射。

具体算法过程为:先构造一个长度为2的32次的整数环(这个环被称作一致性Hash环)，根据结点名称的Hash值将缓存服务器结点放置在这个Hash环上。然后根据需要缓存的数据的KEY值计算得到其Hash值，然后在Hash上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点完成KEY到服务器的Hash映射查找。

还有一个问题就是一致性Hash算法带来的负载不均衡的问题，可以通过虚拟层的手段来解决。 将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值放置在Hash环上，KEY在环上先找到虚拟服务器节点，再得到物理服务器的信息。

关系型数据库集群的伸缩性设计

数据库主从分离，业务分割(不同业务数据表部署在不同的数据库集群上，即俗称的数据分库，这种制约的条件是跨库的表不能进行Join操作)。对一些单表数据仍然很大的表，还需要分片，将一张表拆开分别存储在多个数据库中。

目前网站在线业务应用中比较成熟的支持数据分片的分布式关系数据库产品主要有:开源的Amoeba和Cobar。这两个产品有类似的架构设计。

Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间的。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群的不同的数据库实例上执行。

Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。Cobar服务器可以看作无状态的应用服务器，因此其集群伸缩可以简单使用负载均衡的手段实现。而MySQL中存储着数据，想保证集群扩容后数据一致负载均衡，必须要做数据迁移。

数据迁移可以利用Hash一致性算法。Cobar实践中利用了MySQL的数据同步功能进行数据迁移。数据迁移不是以数据为单位，而是以Schema为单位。同步完成后，修改Cobar服务器的路由配置，将这些Schema的IP修改成为新机器的IP，然后删除原机器中的相关Schema，完成MySQL集群的扩容。

NoSQL数据库的伸缩性

NoSQL，主要指非关系的、分布式的数据库设计模式。NoSQL放弃了关系型数据库的两大重要基础：以关系代数为基础的结构化查询语言和事务一致性保证。而强化了其他一些大型网站更加关注的特性：高可用性和可伸缩性。

4.网站的可扩展架构

指对现有的系统影响最小的情况下，系统功能可持续扩展或者提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间的依赖和耦合，对需求变更可以敏捷响应。