《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴，点击访问该目录可获取更多内容。

首先，所谓网站的伸缩性，指不须要改变网站的软硬件设计，仅仅经过改变部署的服务器数量就能够扩大或者缩小网站的服务处理能力。在整个互联网行业的发展渐进演化中，最重要的技术就是服务器集群，经过不断地向集群中添加服务器来加强整个集群的处理能力。

1、网站架构的伸缩性设计

1.1 不一样功能进行物理分离实现伸缩

　　（1）纵向分离：将业务处理流程上得不一样部分分离部署，实现系统的伸缩性；

　　（2）横向分离：将不一样的业务模块分离部署，实现系统的伸缩性；

1.2 单一功经过集群规模实现伸缩

　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群总体对外提供服务。具体来讲，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不一样，技术实现也有很大的区别。

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

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

2.1 应用服务器那点必须知道的事儿

　　（1）应用服务器应该被设计成无状态的，即应用服务器不存储请求上下文信息；构建集群后，每次用户的请求均可以发到集群中任意一台服务器上处理，任何一台服务器的处理结果都是相同的；

　　（2）HTTP自己是一个无状态的链接协议，为了支持客户端与服务器之间的交互，咱们就须要经过不一样的技术为交互存储状态，而这些不一样的技术就是Cookie和Session了。

　　（3）HTTP请求的分发是应用服务器集群实现伸缩性的核心问题，而负载均衡服务器就是HTTP请求的分发装置，它是网站必不可少的基础手段，也被称为网站的杀手锏之一。

2.2 负载均衡技术—网站必不可少的基础技术手段

　　负载均衡的实现方式多种多样，从硬件到软件，从商业产品到开源产品，应有尽有。可是，实现负载均衡的基础技术不外乎如下几种：

　　（1）HTTP重定向负载均衡　　评价：★★

　　此方案的优势是简单易行，缺点是：

　　①浏览器须要两次请求才能完成一次访问，性能较差；

　　②重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；

　　③使用HTTP 302重定向有可能使搜索引擎判断为SEO做弊，下降搜索排名；

　　（2）DNS域名解析负载均衡　　评价：★★★

　　此方案要求在DNS服务器中配置多个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

　　此方案的优势是将负载均衡的工做转交给了DNS，省掉了网站管理维护负载均衡服务器的麻烦。而缺点是：

　　①目前的DNS是多级解析，每一级DNS均可能缓存A记录，当某台服务器下线后，即便修改了DNS的A记录，要使其生效仍然须要较长时间。这段期间，会致使用户访问已经下线的服务器形成访问失败。

　　②DNS负载均衡的控制权在域名服务商那里，网站没法对其作更多改善和管理；

TIPS：事实上，大型网站老是部分使用DNS域名解析，利用域名解析做为第一级负载均很手段，即域名解析获得的一组服务器不是实际的Web服务器，而是一样提供负载均衡的内部服务器，这组内部服务器再进行负载均衡，请求分发到真实的Web服务器上。

　　（3）反向代理负载均衡　　评价：★★★★

　　Web服务器不须要使用外部IP地址，而反向代理服务器则须要配置双网卡和内外部两套IP地址。

　　此方案的优势是和反向代理服务器功能集成在一块儿，部署简单。缺点是反向代理服务器是全部请求和响应的中转站，其性能可能会成为瓶颈。

　　（4）IP负载均衡　　评价：★★★★

　　此方案优势在于在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。缺点是因为全部请求响应都须要通过负载均衡服务器，集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。

　　（5）数据链路层负载均衡　　评价：★★★★★

　　此种方式又称做三角传输模式，负载均衡数据分发过程当中不修改IP地址，只修改mac地址，因为实际处理请求的真实物理IP地址和数据请求目的IP地址一致，因此不须要经过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称做直接路由方式（DR）。

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

2.3 负载均衡算法—负载均衡技术赖以生存的核心

　　前面的方法解决了负载均衡经过何种方式实现，而更为重要的则是如何从Web服务器列表中计算获得一台Web服务器的地址，而这正是负载均衡的核心—算法。这里简单介绍一下一般的集中负载均衡计算的算法，若是须要深刻了解请自行百度。

　　（1）轮询

　　全部请求被以此分发到每台应用服务器上，即每台服务器须要处理的请求数目都相同，适合于全部服务器硬件都相同的场景。

　　（2）加权轮询

　　根据应用服务器的配置性能的状况，在轮询的基础上，按照配置的权重将请求分发到每一个服务器，高性能的服务器能分配更多的请求。

　　（3）随机

　　此算法比较简单实用，请求被随机分配到各个应用服务器，由于好的随机数自己就很均衡。

　　（4）最少链接

　　记录每一个应用服务器正在处理的链接数（请求数），将新到的请求分发到最少链接的服务器上，应该说，这是最符合负载均衡定义的算法。

　　（5）源地址散列

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

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

　　不一样于应用服务器集群的伸缩性设计，分布式缓存集群的伸缩性不能使用简单的负载均衡手段来实现。由于：分布式缓存服务器集群中缓存的数据各不相同，缓存访问请求不能够在缓存服务器集群中的任意一台处理，必须先找到缓存有须要的数据的服务器，而后才能访问。

　　分布式缓存集群伸缩性设计的目标：让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽量还被访问到。

　　（1）以Memcached为表明的分布式缓存集群的访问模型

　　以上图片展现了一个典型的缓存写操做，应用程序须要写缓存数据<'CHENGDU',DATA>，API将KEY（'CHENGDU'）输入路由算法模块，路由算法根据KEY和Memcached服务器集群列表计算获得一台服务器编号（如Node1），进而获得该机器的IP地址和端口（10.0.0.1:91000）。而后，API调用通讯模块和编号为Node1的Memcached服务器进行通讯，将数据<'CHENGDU',DATA>写入该服务器，至此便完成了一次分布式缓存的写操做。

　　而读操做和写操做同样，使用一样的路由算法和服务器列表，只要提供相同的KEY（如上面提到的'CHENGDU'），Memcached客户端老是访问相通的服务器（如上面计算获得的Node1）去读取数据。

　　（2）以Memcached为表明的分布式缓存集群的伸缩性挑战

　　简单的路由算法（经过使用余数Hash）没法知足业务发展时服务器扩容的须要：缓存命中率降低。例如：当3台服务器扩容至4台时，采用普通的余数Hash算法会致使大约75%（3/4）被缓存了的数据没法正确命中，随着服务器集群规模的增大，这个比例会线性地上升。那么，能够想象，当100台服务器的急群众加入一台服务器，不能命中的几率大概是99%（N/N+1），这个结果显然是没法接受的。

　　那么，可否经过改进路由算法，使得新加入的服务器不影响大部分缓存数据的正确性呢？请看下面的一致性Hash算法。

　　（3）分布式缓存的一致性Hash算法

说明：一致性Hash算法是分布式缓存的核心理论，这里只是简单介绍一下，后续有空我会单独写一篇文章来详细介绍一致性Hash算法，以及用C#实现一致性Hash算法。

　　一致性Hash算法经过一个叫作一致性Hash还的数据结构实现KEY到缓存服务器的Hash映射，以下图所示：

　　具体算法过程是：

　　①先构造一个长度为0~2^32（2的32次幂）个的整数环（又称：一致性Hash环），根据节点名称的Hash值将缓存服务器节点防置在这个Hash环中，如上图中的node1，node2等；

　　②根据须要缓存的数据的KEY值计算获得其Hash值，如上图中右半部分的“键”，计算其Hash值后离node2很近；

　　③在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找，如上图中离右边这个键的Hash值最近的顺时针方向的服务器节点是node2，所以这个KEY会到node2中读取数据；

　　当缓存服务器集群须要扩容的时候，只须要将新加入的节点名称（如node5）的Hash值放入一致性Hash环中，因为KEY老是顺时针查找距离其最近的节点，所以新加入的节点只影响整个环中的一部分。以下图中所示，添加node5后，只影响右边逆时针方向的三个Key/Value对数据，只占整个Hash环中的一小部分。

　　所以，咱们能够与以前的普通余数Hash做对比：采用一直性Hash算法时，当3台服务器扩容到4台时，能够继续命中原有缓存数据的几率为75%，远高于普通余数Hash的25%，并且随着集群规模越大，继续命中原有缓存数据的几率也会随之增大。当100台服务器增长1台时，继续命中的几率是99%。虽然，仍有小部分数据缓存在服务器中没法被读取到，可是这个比例足够小，经过访问数据库也不会对数据库形成致命的负载压力。

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

　　首先，数据存储服务器必须保证数据的可靠存储，任何状况下都必须保证数据的可用性和正确性。所以，缓存服务器集群的伸缩性架构方案不能直接适用于数据库等存储服务器。

　　（1）关系数据库集群的伸缩性设计

　　①市场上主要的关系数据库都支持数据复制功能，使用这个功能能够对数据库进行简单伸缩。下图显示了使用数据复制的MySQL集群伸缩性方案：多台MySQL的角色有主从之分，写操做都在主服务器上，由主服务器将数据同步到集群中其余从服务器。而读操做及数据分析等离线操做都会在从服务器上完成。

　　②前面提到的业务分割模式也能够用在数据库，不一样业务数据表部署在不一样的数据库集群上，这就是所谓的“数据分库”；可是其有一个制约条件：跨库的表没法进行Join操做；

　　③在实际运维中，对一些单表数据仍然很大的表，例如Facebook的用户数据库、淘宝的商品数据库等，还须要进行分片，将一张表拆分开分别存储在多个数据库中，这就是所谓的“数据分片”；

　　（2）NoSQL数据库的伸缩性设计

　　首先，NoSQL主要指非关系的、分布式的数据库设计模式。也有许多专家将NoSQL解读为Not Only SQL，表示NoSQL是关系数据库的补充，而不是替代方案。通常而言，NoSQL数据库产品都放弃了关系数据库的两大重要基础：①以关系代数为基础的结构化查询语言（SQL）②事务的一致性保证（ACID）；与之对应的是强化一些大型网站更关注的特性：高可用性和可伸缩性；

　　开源社区的NoSQL产品不尽其数，其支持的数据结构和伸缩性特性也各不相同。目前看来，应用最普遍的是Apache HBase。HBase的伸缩性主要依赖于其可分裂的HRegion及可伸缩的分布式文件系统HDFS（若是您不知道HDFS又对HDFS有兴趣，能够阅读个人另外一篇博文《不怕故障的海量存储—HDFS基础入门》）实现。

　　上图是HBase的总体架构图：

　　①HBase中数据以HRegion为单位进行管理，也就是说应用程序若是想要访问一个数据，必须先找到HRegion，而后将数据读写操做提交给HRegion，由HRegion完成存储层面的数据操做。

　　②每一个HRegion中存储一段Key区间（例如：[Key1,Key2)）的数据，HRegionServer是物理服务器，每一个HRegionServer上能够启动多个HRegion实例。当一个HRegion中写入的数据太多，达到配置的阀值时，HRegion会分裂成两个HRegion，并将HRegion在整个集群中进行迁移，以使HRegionServer的负载均衡。

　　③全部的HRegion的信息都（例如：存储的Key值区间、所在HRegionServer的IP地址和端口号等）记录在HMaster服务器上。同时为了保证高可用，HBase启动了多个HMaster，并经过ZooKeeper（一个支持分布式一致性的数据管理服务）选举出一个主服务器，经过这个主HMaster服务器得到Key值所在的HRegionServer，最后请求该HRegionServer上的HRegion实例，得到须要的数据。其具体的数据寻址访问流程以下图所示：

5、学习小结

　　在本章的学习中，咱们了解到要实现网站的可伸缩性，关键技术就在于如何构建“良好”的服务器集群。要达到良好的目标，就要求每次扩容和减小服务器时，对整个网站的影响是最小的，甚至无影响的。伸缩性是复杂的，没有通用的、完美的解决方案和产品。一个具备良好伸缩性的网站，其设计老是走在业务发展的前面，在业务须要处理更多访问和处理以前，就已经作好了充分的准备，当业务须要时，只须要增长服务器并简单部署就能够了，技术团队即可轻松应对了。

　　在本篇的介绍中，有些核心的内容好比一致性Hash算法只是进行了简单的介绍，并无深刻的分析，这个源于我目前对其的理解还只是皮毛。等待我深刻学习以后，我会抽空写一篇单独介绍一致性Hash算法的博文，并使用C#进行一个粗略的实现，有兴趣的朋友敬请期待吧。

　　另外，前面几篇博文中有些园友提出介绍一些实践性质的东西，我在这里表示抱歉，由于本书只是单纯地讲解理论，并且也没有深刻地去讲解这些理论，只是单纯地扩展知识面，管中窥豹，一览大型网站的技术体系。而我本人也仍是一个即将求职和毕业的学生，在理论和实践上都缺少相应的经验，但我会在精读完本书后去作一些相应场景的具体实践，好比使用Memcached或Redis构建分布式缓存集群，使用Mono在Linux下搭建ASP.NET MVC应用环境，使用高性能的Nginx或Jexus服务器构建反向代理负载均衡服务器环境，使用发布订阅模式实现MS SQL的读写分离实践等等，若是园友有兴趣的话，也能够自行找资料去作相关实践。若是以为喜欢个人博文，那我只能说敬请期待了（如今时间宝贵啊，立刻要找工做了，还得复习复习，再过段时间毕业论文的鸭梨又要来了，我勒个去），么么嗒。

参考文献

　　（1）李智慧，《大型网站技术架构-核心原理与案例分析》，http://item.jd.com/11322972.html

　　（2）老徐的私房菜，《HTTP无状态协议和Session原理》，http://laoxu.blog.51cto.com/4120547/1219699

　　（3）百度百科，《一致性Hash算法》，http://baike.baidu.com/view/1588037.htm

　　（4）charlee，《Memcached彻底剖析》，http://kb.cnblogs.com/page/42731/

　　（5）bluishglc，《数据库Sharding的基本思想和切分策略》，http://blog.csdn.net/bluishglc/article/details/6161475

本章思惟导图

 

做者：周旭龙

出处：http://www.cnblogs.com/edisonchou/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文连接。