所谓网站的伸缩性架构是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务器处理能力。
大型网站不是一开始就是大型网站，而是从小型网站逐步演化而来的。在这个渐进式的演化过程中，最重要的技术手段就是使用服务器集群，通过不断地向集群中添加服务器来增强集群的处理能力。这个演化过程总体来说是渐进式的，而且总是在伸，网站的规模和服务器规模总是在不断扩大，但是这个过程也可能因运营上的需要出现脉冲，比如促销活动：在某个短时间内，网站的访问量和交易规模暴增，然后又回归正常。这时就需要网站的技术架构具有极好的伸缩性--活动期间向服务器集群中加入更多服务器以满足用户访问，活动结束后又将这些服务器下线以节约成本。
6.1网站架构的伸缩性设计
网站架构发展史就是一部不断向网站添加服务器的历史。只要新添加的服务器能线性提高网站的整体服务处理能力，网站就无需为不断增长的用户和访问而焦虑。
一般来说，网站的伸缩性设计可分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能，后者是集群内的多台服务器部署相同的服务，提供相同功能。
6.1.1不同功能进行物理分离实现伸缩
网站发展早期，通过增加服务器提高网站处理能力时，新增服务器总是从现有服务器中分离出部分功能和服务。
每次分离都会有更多的服务器加入网站，使用新增的服务器处理某种特定服务。事实上，通过物理上分离不同的网站功能，实现网站伸缩性的手段，不仅可以用在网站发展早期，而且可以在网站发展的任何阶段使用。
纵向分离：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
横向分离：将不同的业务模块分离部署，实现系统伸缩性。
横向分离的粒度可以非常小，甚至可以是一个关键网页部署一个独立服务，比如对于电商网站非常重要的产品详情页面，商铺页面搜索列表页面，每个页面都可以独立部署，专门维护。
6.1.2单一功能通过集群规模实现伸缩
将不同功能分离部署可以实现一定程度的伸缩性，但是随着网站访问量的逐步增大，即时分离到最小粒度的独立部署，单一服务器也不能满足业务规模的要求。因此必须使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。即：当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。
具体来说，集群伸缩性又可以分为应用服务器集群伸缩性和数据服务器集群伸缩性。
6.2应用服务器集群伸缩性
应用服务器应该设计成无状态的，即应用服务器不存储请求上下文信息，如果将部署有相同应用的服务器组成一个集群，每次用户请求都可以发生到集群中任意一台服务器上处理，任何一台服务器的处理结果都是相同的。这样只要能将用户请求按照某种规则分发到集群的不同服务器上，就可以构成一个应用服务器集群。
如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。
这个HTTP请求分发装置被称为负载均衡服务器。
负载均衡是网站必不可少的基础技术手段。不但可以实现网站的伸缩性，同时还可以改善网站饿可用性，可谓网站的杀手锏之一。 实现负载均衡的技术主要有以下几种：
6.2.1 HTTP重定向负载均衡
利用HTTP重定向实现负载均衡
HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将web服务器地址写入HTTP重定向响应中返回给用户浏览器。
这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多。
6.2.2DNS域名解析负载均衡
这是利用DNS处理域名解析请求的同时进行负载均衡处理的一种方案。
在DNS服务器中配置多个A记录，如：www.xxx.com IN A 114.100.80.1,www.vvv.com IN A 114.100.80.2
每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成了一个集群，并可以实现负载均衡。
DNS域名·解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS服务器支持地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可以加快用户访问速度，改善性能。但是DNS域名解析负载均衡也有缺点，就是目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败。而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供wed服务的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真实的Web服务器上。
6.2.3反向代理负载均衡
利用反向代理服务器进行负载均衡。
前面我们提到利用反向代理缓存资源，以改善网站性能。实际上，在部署位置上，反向代理服务器位于Web服务器前面（这样才可能缓存Web响应，加速访问），这个位置正好也是负载均衡服务器的位置，所以大多数反向代理服务器同时提供负载均衡的功能，管理一组web服务器，将请求根据负载均衡算法转发到不同web服务器上。web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于Web服务器不直接对外提供访问，因此Web服务器不需要使用外部IP地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
由于反向代理服务器转发在HTTP协议层面，因此也叫应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。确定是反向代理服务器是所有请求和响应的中转站，性能可能会成为瓶颈。
6.2.4IP负载均衡
在网络层通过修改请求目标地址进行负载均衡。
用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实Web服务器，然后将数据目的IP地址修改为10.0.0.1，不需要通过用户进程处理。真实Web应用服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身IP地址发送给用户浏览器。
这里的关键在于真实物理服务器web服务器响应数据包如何返回该负载均衡服务器，一种方案是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址设为自身IP，即源地址转换，这样Web服务器的响应会再回到负载均衡服务器；另一种方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会达到负载均衡服务器。
IP负载均衡在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的最大影响数据吞吐量不得不受制于负载均衡服务器网卡带宽。对于提供下载服务或者视频服务等需要传输大量数据的网站来说，难以满足需求。
6.2.5数据链路层负载均衡
数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称为直接路由方式（DR）。
使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS。
6.2.6负载均衡算法
负载均衡服务器的实现可以分为两个部分：
1.根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器地址。
2.将请求数据发送到该地址对应的Web服务器上。
前面描述了如何将数据请求发送到Web服务器，而具体的负载均衡算法通常有：
轮询（Round Robin，RR）
所有请求被依次分发到每台服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。
加权轮询（Weighted Round Robin，WRR）
感觉服务器硬件性能情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多请求。
随机（Random）
请求被随机分配到各个应用服务器，在许多场合下，这种方案都简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以使用加权随机算法。
最少连接（Least Connections）
记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最少连接。
源地址散列（Source Hashing）
根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址地请求总在同一个服务器上处理，该轻轻地上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话黏滞
6.3分布式缓存集群的伸缩性设计
分布式缓存不同于应用服务器集群的伸缩性设计，分布式缓存集群的伸缩性不能使用简单的负载均衡手段来实现。分布式缓存服务器集群中不同服务器中数据各不相同，缓存访问请求不可以在缓存服务器集群中任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。
6.3.1Memcached分布式缓存集群的访问模型
应用程序输入需要写缓存的数据，API将KEY输入路由算法模块，路由算法根据KEY和Memcached集群服务器列表计算得到一台服务器编号，进而得到该机器IP地址和端口。API调用通信模块和编号为NODE1的服务器通信，将数据写入该服务器。完成一次分布式缓存的写操作。读操作与此类似。
6.3.2Memcached分布式缓存集群的伸缩性挑战
简单的路由算法可以使用余数hash，用服务器数目除以缓存数据KEY的Hash值，余数为服务器列表下标编号。由于HashCode具有随机性，因此使用余数Hash路由算法可保证缓存数据在整个Memcached服务器集群中比较均衡地分布。对余数Hash路由算法稍加改进，就可以实现和负载均衡算法中加权负载均衡一样的加权路由。事实上，如果不需要考虑缓存服务器集群伸缩性，余数Hash几乎可以满足绝大多数的缓存路由需求。
但是，当分布式缓存集群需要扩容时，就麻烦了。
假设由于雨雾发展，网站需要将3台服务器扩容成4台。更改服务器列表，仍旧使用余数Hash，这就导致了hash值的计算错误，导致读取到了错误的服务器，缓存没有命中。 很容易计算出，3台服务器扩容至4台服务器，大约有75%(3/4)被缓存了的数据不能正确命中，随着服务器集群规模的增大，这个比例线性上升。当100台服务器的集群中加入一台新服务器，不能命中的概率是99%。 这样必然是不能被接受的，在网站业务中，大部分的业务数据读操作请求事实上都是通过缓存获取的，只有少量读操作会访问数据库，因此数据库的负载能力是以有缓存为前提而设计的。这样会导致数据库压力大大增加，甚至宕机。
6.3.3分布式缓存的一致性Hash算法
具体算法为：先构造一个长度为0-2的32次方的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（范围同上）将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的key值计算得到其Hash值（范围同上），然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找。
当缓存服务器需要扩容时，只需要将新加入的节点名称的Hash值放入一致性Hash环中，由于KEY是顺时针查找距离其最近的节点，因此新加入的节点只影响环中的一小段。
如上图，加入NODE3后，原来的KEY大部分还能继续计算到原来的节点，这有KEY0,KEY3从原来的NODE1重新计算到NODE3，这样就保证大部分被缓存的数据还可以继续命中。3台到4台服务器扩容后，可以继续命中原有缓存数据的概率是75%，远高于余数Hash的25%，而且随着集群规模越大，继续命中原有缓存数据的概率也逐渐增大，100台服务器扩容增加1台服务器，继续命中的最低概率为99%，仍有小部分数据缓存在服务器中不能被读取到，但是这个比例足够小，通过访问数据库获取也不会对数据库造成致命的负载压力。
具体应用中，这个一致性Hash环通常使用二叉查找树实现，Hash查找过程实际上是在二叉树中查找不小于查找数的最小数值。当然这个二叉树的最右边叶子节点和最左边的叶子节点相连，构成环。
但是，这种算法还存在一个小问题。
新加入的NODE3只影响了原来的NODE1节点，也就是说一部分原来需要访问NODE1的缓存数据现在需要访问NODE3（50%的概率）。但是原来的节点NODE0和NODE2不受影响，这就意味着NODE0和NODE2缓存数据量和负载压力是NODE1与NODE3的两倍。如果4台机器的性能是一样的，那这种结果显然不是我们需要的。
怎么办？
计算机领域有句话：计算机的任何问题都可以通过增加一个虚拟层来解决。计算机硬件、计算机网络、计算机软件都莫不如此。计算机网络的7层协议，每一层都可以看做是操作系统的虚拟层；分层的计算机软件架构事实上也是利用虚拟层的概念。
解决上述一致性Hash算法带来的负载不均衡问题，也可以使用虚拟层的手段：将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值放置在Hash环上，KEY在环上先找到虚拟机服务器节点，再得到物理服务器信息。
这样新加入物理服务器节点时，是将一组虚拟节点加入环中，如果虚拟节点的数目足够多这组虚拟节点将会影响同样多数目的已经已经在环上存在的虚拟节点，这些已经存在的虚拟节点有对应不同的物理节点。最终的结果是：新加入一台缓存服务器，将会较为均匀地影响原来集群中已经存在的所有服务器，也就是说分摊原有缓存服务器集群中所有服务器的一小部分负载，总的影响范围和上面的相同。
如上图，新加入节点NODE3对应的一组虚拟节点V30,V31,V32，加入到一致性hash环后，影响V01,V12,V22三个虚拟节点，而这三个虚拟节点分别对应NODE0,NODE1,NODE2三个物理节点。最终Memcached集群中加入一个节点，但是同时影响到集群中已存在的三个物理节点，在理想情况下，每个物理节点受影响的数据量为其及节点缓存数据量的1/4(X/(n+x))，N为原有物理节点数，X为新加入物理节点数，也就是集群中已经被缓存的数据有75%可以被继续命中。
显然每个物理节点对应的虚拟节点越多，各个物理节点之间的负载越均衡，新加入物理服务器对原有的物理服务器的影响越保存一致（这就是一致性Hash这个名称的由来）。那么实践中，一台物理服务器虚拟为多少个虚拟服务器节点合适呢？太多会影响性能，太少又会导致负载不均衡，一般来说，经验值是150，当然根据集群规模和负载均衡的精度需求，这个值应该根据具体情况对峙。
6.4数据存储服务器集群的伸缩性设计
和缓存服务器集群的伸缩性设计不同，数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。
缓存的目的是加速数据读取的速度并减轻数据存储服务器的负载压力，因此部分缓存数据的丢失不影响业务的正常处理，因此数据还可以从数据库等存储服务器获取。
而数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性。因此缓存服务器集群的伸缩性架构方案不能直接适用于数据库等存储服务器。 存储服务器集群的伸缩性设计相对更复杂一些，具体说，又可以分为关系数据库集群的伸缩性设计和NoSQL数据库的伸缩性设计。
6.4.1关系数据库集群的伸缩性设计
关系数据库凭借简单强大的SQL和众多成熟的商业数据库产品，占据了从企业应用到网站系统的大部分业务数据存储服务。市场上主要的关系数据都支持数据复制功能，使用这个功能可以对数据库进行简单伸缩
这种架构中，虽然多台服务器部署MySQL实例，但是它们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。
除了数据库主从读写分离，前面提到的业务分割模式也可以用在数据库，不同业务数据库表部署在不同的数据库集群上，即俗称的数据分库。这种方式的制约条件是跨库的表不能进行join操作。
在大型网站的实际应用中，即使进行了分库和主从复制，对一些单表数据仍然很大的表，比如Facebook的用户数据库等，还需要进行分片，将一张表拆开分别存储在多个数据库中。
目前网站在线业务应用中比较成熟的支持数据分片分库的分布式关系数据库产品主要有开源的Amoeba和Cobar。这两个产品有相似的架构设计，以Cobar为例，部署模型如下：
cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间（Cobar也支持非独立部署，以lib的方式和应用程序部署在一起）。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个Mysql实例部署都为主从结构，保证数据高可用）。
前端通信模块负责和应用程序通信，接收到SQL请求（select * from users where userid in (12,22,23) ）后转交给SQL解析模块，SQL解析模块解析获得SQL中的路由规则查询条件为userid in(12,22,23)再转交给SQL路由模块，SQL路由模块根据路由规则配置（userid 为偶数路由至数据库A，userid为奇数路由至数据库B）将应用程序提交的SQL分解成两条SQL,转交给SQL执行代理模块，发送至数据库A和数据库B分别执行。
数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并模块将两个返回结果合并为一个结果集，最终返回给应用程序，完成在分布式数据库中的一次访问请求。
那么Cobar如何实现集群的伸缩呢？
Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
Cobar服务器可以看做无状态的应用服务器，因此其集群伸缩可以简单使用负载均衡手段实现。而Mysql中存储着数据，要想保证集群扩容后数据一致负载均衡，必须要做数据迁移，将集群中原来机器中的数据迁移到新添加的机器中。
具体迁移哪些数据可以利用一致性Hash算法（即路由模块使用一致性Hash算法进行路由），尽量使需要迁移的数据最少。但是迁移数据需要遍历数据库中每条记录，需要进行路由计算确定其是否需要迁移，这会对数据库访问造成一定压力。并且需要解决迁移过程中数据的一致性，可访问性，迁移过程中服务器宕机时的可用性等诸多问题。
实践中，Cobar利用了MySQL的数据同步功能进行数据迁移。数据迁移不是以数据为单位，而是以Schema为单位。在Cobar集群初始化时，在每个MySQL实例创建多个Schame（如集群最大规模为1000台数据库服务器，那么总的初始Schema数 大于等于 1000），集群扩容时，从每个服务器中迁移部分Schema到新机器中，由于迁移以Schema为单位，迁移过程可以使用Mysql的同步机制。
同步完成时，即新机器中Schema数据和原机器中Schema数据一致时，修改Cobar服务器的路由配置，将这些Schema的IP修改为新机器的IP，然后删除原机器中的相关Schema，完成MySQL集群扩容。
在整个分布式关系数据库的访问请求过程中，Cobar服务器处理消耗的时间是很少的，时间花费主要还是在MySQL数据库端，因此应用程序通过Cobar访问分布式关系数据库，性能基本上和直接访问关系数据库相当，可以满足网站在线业务的实时处理需求。事实上由于Cobar代替应用程序连接数据库，数据库只需要维护更少的连接，减少不必要的资源消耗，改善性能。
但由于Cobar路由后只能在单一数据库实例上处理查询请求，因此无法执行跨库的JOIN操作，当然更不能执行跨库的事务处理。
相比关系数据库本身功能上的优雅强大，目前各类分布式关系数据库解决方案都显得非常简陋，限制了关系数据库某些功能的使用。但是当网站业务面临不停增长的海量业务数据存储压力时，又不得不利用分布式关系数据库的集群伸缩能力，这时就必须从业务上回避分布式关系数据库的各种缺点：避免事务或利用事务补偿机制代替数据库事务；分解数据访问逻辑变JOIN操作等。
除了上面提到的分布式数据库，还有一类分布式数据库可以支持JOIN操作执行复杂的SQL查询，如GreenPlum，但是这类数据库的访问延迟比较大（可以想象JOIN操作需要在服务器间传输大量的数据），因此一般使用在数据仓库等非实时业务中。
6.5小结
伸缩性架构设计能力是网站架构师必备的能力。
伸缩性架构设计是简单的，因为几乎所有稍有规模的网站都必须是可伸缩的，有很多案例可供借鉴，同时又有大量商业的、开源的提供伸缩性能力的软硬件产品可供选择。然而伸缩性设计又是复杂的，没有通用的、完美的解决方案和产品，网站伸缩性往往和可用性、正确性、性能等耦合在一起，改善伸缩性可能会影响一些网站的其他特性，网站架构师必须对网站的商业目标，历史演化，技术路线了然于胸，甚至还需要总和考虑技术团队的知识储备和结构，管理层的战略愿景和规划，才能最终做出对网站伸缩性架构最合适的决策。