6 永无止境：网站的伸缩性架构

6 永无止境：网站的伸缩性架构

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

6.1 网站架构的伸缩性设计

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

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

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

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

当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，二是用两头牛来拉车。

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

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

这里，这个HTTP请求分发装置被称作负载均衡服务器。

实现负载均衡的基础技术有以下几种：

6.2.1 HTTP重定向负载均衡

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。

优点是简单，缺点是浏览器需要两次请求服务器才能完成一次访问。

6.2.2 DNS域名解析负载均衡

每次域名解析请求都会根据负载均衡算法计算一个不同的ＩＰ地址返回，这样Ａ记录中配置的多个服务器就构成了一个集群，并可以实现负载均衡。

优点是省掉了网站管理维护负载均衡服务器的麻烦，缺点是ＤＮＳ是多级解析，且控制权在域名服务商那里。

6.2.3反向代理负载均衡

反向代理服务器缓存资源，同时提供负载均衡的功能，管理一组Ｗｅｂ服务器，将请求根据负载均衡算法转发到不同Ｗｅｂ服务器上。

也叫应用层负载均衡。优点是和反向代理服务器功能集成在一起，部署简单，缺点是反向代理服务器性能可能成为瓶颈。

6.2.4 IP负载均衡

在网络层通过修改请求目标地址进行负载均衡。

6.2.5数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改ｍａｃ地址进行负载均衡。

在Ｌｉｎｕｘ平台上最好的链路层负载均衡开源产品是ＬＶＳ（Ｌｉｎｕｘ　Ｖｉｒｔｕａｌ　Server）

6.2.6负载均衡算法

轮询

加权轮询

随机

最少连接

源地址散列

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

和所有服务器都部署相同应用的服务器集群不同，分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。

6.3.1 Memcached分布式缓存集群的访问模型

6.3.2 Memcached分布式缓存集群的伸缩性挑战

6.3.3 分布式缓存的一致性Hash算法

计算机的任何问题都可以通过增加一个虚拟层来解决。

6.4 数据存储服务器集群的伸缩性设计

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

市场上主要的关系数据都支持数据复制功能，使用这个功能可以对数据库进行简单伸缩。

数据库主从读写分离：

多台服务器部署MySQL实例，但是它们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。

数据分库：

不同业务数据表部署在不同的数据库集集群上。

数据分片：

将一张表拆开分别存储在多个数据库中。

支持数据分片的分布式关系数据库产品主要有开源的Amoebe和Cobar.

Cobar如何做集群的伸缩呢？

Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。

6.4.2 NoSQL数据库的伸缩性设计

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

应用最广泛的NOSQL产品是Apache HBase。

6.5 小结

高手定律：这个世界上只有遇不到的问题，没有解决不了的问题。