大型网站技术架构-6 永无止境：网站的伸缩性架构

读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》

---

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

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

大型网站的“大型”，在用户层面可以理解为大量用户及大量访问，如Facebook有超过10亿用户；在功能方面可以理解为功能庞杂、产品众多，如腾讯有超过1600种产品；在技术层面可以理解为网站需要部署大量的服务器，如Google大约有近100万台服务器。

网站一开始不可能规划出自己的规模，也不可能有那么多钱去开发一个大型系统，更不可能到了某个阶段再重新打造一个系统，只能摸着石头过河，从一台廉价的PC服务器开始自己的大型系统演化之路。

在这个渐进式的演化过程中，最重要的技术手段就是使用服务器集群，通过不断地向集群中添加服务器来增强整个集群的处理能力。这就是网站系统的伸缩性架构，只要技术上能做到向集群中加入服务器的数量和集群的处理能力成线性关系，那么网站就可以以此手段不断提升自己的规模

向服务器集群中加入更多服务器（及向网络服务商租借更多的网络带宽）以满足用户访问，活动结束后又将这些服务器下线以节约成本。

但遗憾的是，有些传统企业将自己的管理模式和经营理念也照搬到互联网领域——在技术方面的表现就是一开始就企图打造一个大型网站。

6.1 网站架构的伸缩性设计

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

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

网站发展早期——通过增加服务器提高网站处理能力时，新增服务器总是从现有服务器中分离出部分功能和服务

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

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

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

使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。

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

计算一个服务的集群规模，需要同时考虑其对可用性、性能的影响及关联服务集群的影响。

集群伸缩性又可分为应用服务器集群伸缩性和数据服务器集群伸缩性。

数据服务器集群也可分为缓存数据服务器集群和存储数据服务器集群，这两种集群的伸缩性设计也不大相同。

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

HTTP请求分发装置被称作负载均衡服务器。负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性，可谓网站的杀手锏之一。

6.2.1 HTTP重定向负载均衡

将该Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。

这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多见。

6.2.2 DNS域名解析负载均衡

这是利用DNS处理域名解析请求的同时进行负载均衡处理的一种方案

DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。但是DNS域名解析负载均衡也有缺点，就是目前的DNS是多级解析

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

6.2.3 反向代理负载均衡

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

6.2.4 IP负载均衡

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

数据吞吐量不得不受制于负载均衡服务器网卡带宽。对于提供下载服务或者视频服务等需要传输大量数据的网站而言，难以满足需求

6.2.5 数据链路层负载均衡

顾名思义，数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡

这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式（DR）。

三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS（Linux Virtual Server）。

6.2.6 负载均衡算法

轮询（Round Robin，RR）

加权轮询（Weighted Round Robin，WRR）

随机（Random）

最少连接（Least Connections）

源地址散列（Source Hashing）

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

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

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

新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。

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

HashCode具有随机性

数据库的负载能力是以有缓存为前提而设计的。

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

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

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

当缓存服务器集群需要扩容的时候，只需要将新加入的节点名称（NODE3）的Hash值放入一致性Hash环中，由于KEY是顺时针查找距离其最近的节点，因此新加入的节点只影响整个环中的一小段

具体应用中，这个长度为2$^{32}$的一致性Hash环通常使用二叉查找树实现，Hash查找过程实际上是在二叉查找树中查找不小于查找数的最小数值。当然这个二叉树的最右边叶子节点和最左边的叶子节点相连接，构成环。

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

这样新加入物理服务器节点时，是将一组虚拟节点加入环中，如果虚拟节点的数目足够多，这组虚拟节点将会影响同样多数目的已经在环上存在的虚拟节点，这些已经存在的虚拟节点又对应不同的物理节点。最终的结果是：新加入一台缓存服务器，将会较为均匀地影响原来集群中已经存在的所有服务器，也就是说分摊原有缓存服务器集群中所有服务器的一小部分负载，其总的影响范围和上面讨论过的相同。

显然每个物理节点对应的虚拟节点越多，各个物理节点之间的负载越均衡，新加入物理服务器对原有的物理服务器的影响越保持一致（这就是一致性Hash这个名称的由来）。那么在实践中，一台物理服务器虚拟为多少个虚拟服务器节点合适呢？太多会影响性能，太少又会导致负载不均衡，一般说来，经验值是150，当然根据集群规模和负载均衡的精度需求，这个值应该根据具体情况具体对待。

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

缓存的目的是加速数据读取的速度并减轻数据存储服务器的负载压力，因此部分缓存数据的丢失不影响业务的正常处理，因为数据还可以从数据库等存储服务器上获取。

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

数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。

除了数据库主从读写分离，前面提到的业务分割模式也可以用在数据库，不同业务数据表部署在不同的数据库集群上，即俗称的数据分库。这种方式的制约条件是跨库的表不能进行Join操作。

目前网站在线业务应用中比较成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba（http://sourceforge.net/projects/amoeba/）和Cobar（http://code.alibabatech.com/wiki/display/cobar/Home）。

应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个MySQL实例都部署为主/从结构，保证数据高可用）。

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

需要解决迁移过程中数据的一致性、可访问性、迁移过程中服务器宕机时的可用性等诸多问题。

数据迁移不是以数据为单位，而是以Schema为单位。

集群扩容的时候，从每个服务器中迁移部分Schema到新机器中，由于迁移以Schema为单位，迁移过程可以使用MySQL的同步机制

事实上由于Cobar代替应用程序连接数据库，数据库只需要维护更少的连接，减少不必要的资源消耗，改善性能。

但由于Cobar路由后只能在单一数据库实例上处理查询请求，因此无法执行跨库的JOIN操作，当然更不能执行跨库的事务处理。

必须从业务上回避分布式关系数据库的各种缺点：避免事务或利用事务补偿机制代替数据库事务；分解数据访问逻辑避免JOIN操作等。

GreenPlum。但是这类数据库的访问延迟比较大（可以想象，JOIN操作需要在服务器间传输大量的数据），因此一般使用在数据仓库等非实时业务中。

6.4.2 NoSQL数据库的伸缩性设计

先设计数据库然后设计程序，从而导致关系模型绑架对象模型，并由此引申出旷日持久的业务对象贫血模型与充血模型之争。

NoSQL，主要指非关系的、分布式的数据库设计模式。也有许多专家将NoSQL解读为Not Only SQL，表示NoSQL只是关系数据库的补充，而不是替代方案。

强化其他一些大型网站更关注的特性：高可用性和可伸缩性。开源社区有各种NoSQL产品，其支持的数据结构和伸缩特性也各不相同，目前看来，应用最广泛的是Apache HBase。HBase为可伸缩海量数据储存而设计，实现面向在线业务的实时数据访问延迟。HBase的伸缩性主要依赖其可分裂的HRe-gion及可伸缩的分布式文件系统HDFS实现。

HBase为可伸缩海量数据储存而设计，实现面向在线业务的实时数据访问延迟。HBase的伸缩性主要依赖其可分裂的HRe-gion及可伸缩的分布式文件系统HDFS实现。

当一个HRegion中写入的数据太多，达到配置的阈值时，HRe-gion会分裂成两个HRegion，并将HRegion在整个集群中进行

迁移，以使HregionServer的负载均衡。

应用程序通过Zookeeper获得主HMaser的地址，输入Key值获得这个Key所在的HRegionServer地址，然后请求HRegion-Server上的HRegion，获得需要的数据。

如果集群中有新加入的服务器，也就是说有了新的HRegionServer，由于其负载较低，也会把HRegion迁移过去并记录到HMaster，从而实现HBase的线性伸缩。

6.5 小结

然而伸缩性设计又是复杂的，没有通用的、完美的解决方案和产品，网站伸缩性往往和可用性、正确性、性能等耦合在一起，改善伸缩性可能会影响一些网站的其他特性，网站架构师必须对网站的商业目标、历史演化、技术路线了然于胸，甚至还需要综合考虑技术团队的知识储备和结构、管理层的战略愿景和规划，才能最终做出对网站伸缩性架构最合适的决策。一个具有良好伸缩性架构设计的网站，其设计总是走在业务发展的前面，在业务需要处理更多访问和服务之前，就已经做好充足准备，当业务需要时，只需要购买或者租用服务器简单部署实施就可以了，技术团队亦可高枕无忧。

架构师对网站伸缩性的把握，一线之间，天堂和地狱。

救世主定律：遇到问题，分析问题，最后总能解决问题。如果遇到问题就急匆匆地从外面挖一个高手，然后指望高手如探囊取物般轻松搞定，最后怕是只有彼此抱怨和伤害。

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls