站点系统的伸缩性架构最重要的技术手段就是使用server集群功能。通过不断地向集群中加入server来增强整个集群的处理能力。
“伸”即站点的规模和server的规模总是在不断扩大。
1、站点架构的伸缩性设计
站点的伸缩性设计能够分成两类，一类是依据功能进行物理分离实现伸缩。一类是单一功能通过集群实现伸缩。
前者是不同的server部署不同的服务，提供不同的 功能；后者是集群内的多台server部署同样的服务，提供相关的功能。
1.1 不同功能进行物理分离实现伸缩
纵向分离：即分层后分离。将业务处理流程上的不同部分分离部署，实现系统伸缩性。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvTUlORVpIQU5HSEFP/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
横向分离：即切割业务后分离。将不同的业务模块分离部署，实现系统伸缩性。
1.2 单一功能通过你集群规模实现伸缩
当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。
集群伸缩性又分为应用server集群伸缩性和数据server集群伸缩性。
数据server集群也可分为缓存数据server集群和存储数据server集群。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvTUlORVpIQU5HSEFP/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
2、 应用server集群的伸缩性设计
所谓应用server的伸缩性即：HTTP请求分发装置能够感知或者能够配置集群的server数量。能够及时发现集群中新上线或下线的server，并能向新上线的server分发请求 ，停止向已下线的server分发请求。这个HTTP请求分发装置被称为负载均衡server。
负载均衡是站点不可缺少的基础技术手段，不但能够实现站点的伸缩性，同一时候还改善站点的可用性，可谓站点的杀手锏之中的一个。
详细的技术实现也多种多样，从硬件实现到软件实现， 从商业产品到开源，应有尽有，但实现负载均衡的基础技术不外下面几种。
2.1 HTTP重定向负载均衡
HTTP重定向server是一台普通的应用server，其唯一的功能就是依据用户的HTTP请求计算一台真实的server地址。并将真实的server地址写入HTTP重定向响应中（响应状态吗302）返回给浏览器，然后浏览器再自己主动请求真实的server。
这样的负载均衡方案的长处是比較简单。缺点是浏览器须要每次请求两次server才干拿完毕一次訪问，性能较差。使用HTTP302响应吗重定向，可能是搜索引擎推断为SEO作弊，减少搜索排名。重定向server自身的处理能力有可能成为瓶颈。
因此这样的方案在实际使用中并不见多。
2.2 DNS域名解析负载均衡
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2hhb2ZhbndlaQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
利用DNS处理域名解析请求的同一时候进行负载均衡是还有一种经常使用的方案。在DNSserver中配置多个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记录中配置的多个server就构成一个集群，并能够实现负载均衡。
DNS域名解析负载均衡的长处是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录。不受站点控制。
其实，大型站点总是部分使用DNS域名解析。作为第一级负载均衡手段，然后再在内部做第二级负载均衡。
2.3 反向代理负载均衡
前面我们已经讲过，反向代理能够缓存资源，改善站点性能。其实，反向代理业能够做负载均衡，如图所看到的。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2hhb2ZhbndlaQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
因为反向代理server转发请求在HTTP协议层面，因此也叫应用层负载均衡。长处是部署简单，缺点是可能成功系统的瓶颈。
2.4 IP负载均衡
IP负载均衡：即在网络层通过改动请求目标地址进行负载均衡。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2hhb2ZhbndlaQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
用户请求数据包到达负载均衡server后。负载均衡server在操作系统内核进行获取网络数据包，依据负载均衡算法计算得到一台真实的WEBserver地址，然后将数据包的IP地址改动为真实的WEBserver地址，不须要通过用户进程处理。真实的WEBserver处理完成后，对应数据包回到负载均衡server，负载均衡server再将数据包源地址改动为自身的IP地址发送给用户浏览器。
这里的关键在于真实WEBserver对应数据包怎样返回给负载均衡server，一种是负载均衡server在改动目的IP地址的同一时候改动源地址。将数据包源地址改为自身的IP。即源地址转换（SNAT），还有一种方案是将负载均衡server同一时候作为真实物理server的网关server。这样全部的数据都会到达负载均衡server。
IP负载均衡在内核进程完毕数据分发，较反向代理均衡有更好的处理性能。但因为全部请求响应的数据包都须要经过负载均衡server。因此负载均衡的网卡带宽成为系统的瓶颈。
2.5 数据链路层负载均衡
顾名思义：数据链路层负载均衡是指在通信协议的数据链路层改动mac地址进行负载均衡，例如以下图：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2hhb2ZhbndlaQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">
这样的传输数据方式又称作三角传输模式，负载均衡数据分发过程中不改动IP地址。仅仅改动目的的mac地址，通过配置真实物理server集群全部机器虚拟IP和负载均衡serverIP地址一样。从而达到负载均衡。这样的负载均衡方式又称为直接路由方式（DR）.
在上图中。用户请求到达负载均衡server后。负载均衡server将请求数据的目的mac地址改动为真是WEBserver的mac地址。并不改动数据包目标IP地址。因此数据能够正常到达目标WEBserver，该server在处理完数据后能够经过网管server而不是负载均衡server直接到达用户浏览器。
使用三角传输模式的链路层负载均衡是眼下大型站点所使用的最广的一种负载均衡手段。
在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。
2.6 负载均衡算法
负载均衡server的实现能够分成两个部分：
1、依据负载均衡算法和WEBserver列表计算得到集群中一台WEBserver的地址；
2、将请求数据发送到改地址相应的WEBserver上。
经常使用的负载均衡算法例如以下几种：
1、轮询：即将请求依次分发到每台应用server上。
2、加权轮询：依据应用server硬件性能情况，在轮询的基础上。安装配置的权重将请求分发到每一个server。
3、随机：将请求随机分配到各个应用server。
4、最少连接：记录每一个server正在处理的连接数。将新到的请求分发到最少连接的server上。
5、原地址散列：依据请求来源的IP地址进行Hash计算，得到应用server，这样来自同一个IP地址请求总在同一个server上处理。
3、分布式缓存集群的伸缩性设计
分布式缓存server集群中不同server中缓存的数据不同样。缓存訪问请求不可用在缓存server集群中的随意一台处理，必须先找到缓存有须要数据的server，然后才干訪问。 这个特点会严重制约分布式缓存集群的伸缩性设计，由于新上线的缓存server没有缓存数据，而已下线的缓存server还缓存着站点的很多热点数据。
分布式缓存集群伸缩性设计的最主要目标即：必须让新上线的缓存server对整个分布式缓存集群影响最小，也就是说新增加缓存server后应使整个缓存server集群中已经缓存的数据 尽可能还被訪问到。
3.1 memcached分布式缓存集群訪问模型
3.2 分布式缓存的一致性Hash算法
一致性hash算法通过一个叫做一致性hash环的数据结构实现KEY到缓存server的Hash映射，例如以下图：
假设使用上面数据结构的话，那么当新加入一台缓存server时，仅仅是影响到了当中一台缓存server。其它两头缓存server的压力并没有得到缓解，因此此方案还是存在问题。 一种替代的方案就是添加一个虚拟层，即把每台缓存server虚拟为一组server（比方3个虚拟网元）平均放到上面的环里面。这样当新添加缓存server时。把新添加的虚拟网元平均分配 到环中，这样就能缓解每台缓存server，达到分布式缓存集群高伸缩性。
4、数据存储server集群的伸缩性设计
和缓存server集群的伸缩性设计不同。数据存储server集群的伸缩性对数据的持久性和可用性提出了更高的要求。详细来说。又可分为关系数据库集群的伸缩性设计和NoSql数据库的伸缩性设计。
4.1 关系数据库集群的伸缩性设计
基本的关系数据库都支持数据复制功能，使用这个功能能够对数据库进行简单伸缩。
另外除了利用数据库主从读写分离外，也能够利用业务分隔模式使不同业务的数据表部署在不同的数据库集群上。即俗称的数据分库。
可是这样的方式的制约条件时跨库不能进行join操作。
在大型站点的实际应用中，即使使用了分库和主从复制，对一些单表数据任然非常大的表还须要进行分片。将一张表拆开分别存储在多个数据库中。
眼下支持分布式数据分片的关系数据库产品主要有开源的Amoeba和Cobar（阿里巴巴）。下图为Cobar部署模型。
Cobar是一个分布式关系数据库訪问代理，介于应用server和数据库server之间。应用程序通过JDBC驱动訪问Cobar集群。Cobarserver依据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的伸缩有两点：Cobarserver集群的伸缩和MySQLserver集群的伸缩。
Cobarserver能够看做是无状态的应用server，因此其集群伸缩能够简单有用负载均衡的手段实现。
而MySQL中存储着数据，要保证集群扩容后数据一致负载均衡。必需要做数据迁移，例如以下图（利用数据同步功能进行数据迁移）。
4.2 NoSQL数据库的伸缩设计
NoSQL主要是指非关系的、分布式的数据库设计模式。
一般而言，NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事物一致性保证（ACID），而强化了高可用性和可伸缩性。
眼下应用最广泛的是Apache HBase。