《大型网站技术架构――核心原理与案例分析》读书笔记(6)

第六、七章 网站的伸缩性和扩展性架构

　　伸缩性（Scalability），指系统能够通过增加（或减少）自身资源规模的方式增强（或减少）自己计算事务的能力，即不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。通常使用服务器集群，不断地向集群中添加服务器来增强整个集群的处理能力。

　　扩展性（Extensibiltiy）指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。即当系统新增一个功能时，不需要对现有系统的结构和代码进行修改。

一、伸缩性架构

　　网站的伸缩性架构分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者表现为不同的服务器部署不同的服务，提供不同的功能。后者表现为集群内的多台服务器部署为相同的服务，提现相同的功能。

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

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

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

　　2. 单一功通过集群规模实现伸缩

　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。

　　（1）应用服务器集群的伸缩性设计

　　应用服务器应该被设计成无状态的，每次用户的请求都可以发到集群中任意一台服务器上处理。HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，需要通过不同的技术，比如Cookie和Session，为交互存储状态。HTTP请求的分发是应用服务器集群实现伸缩性的核心问题，而负载均衡服务器就是HTTP请求的分发装置。

　　实现负载均衡的基础技术有：

　　A. HTTP重定向负载均衡：HTTP重定向服务器将重定向IP返回给客户端，客户端再次请求。此方案的优点是简单易行，缺点是浏览器需要两次请求才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP 302重定向有可能使搜索引擎判断为SEO作弊，降低搜索排名；

　　B. DNS域名解析负载均衡：将负载均衡的工作转交给了DNS，省掉了网站管理维护负载均衡服务器的麻烦。而缺点是：DNS缓存可能导致某台服务器下线后，即使修改了DNS的，要使其生效仍然需要较长时间，这段期间，会导致用户访问已经下线的服务器造成访问失败；DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和管理。大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器不是实际的Web服务器，而是同样提供负载均衡的内部服务器，这组内部服务器再进行负载均衡，请求分发到真实的Web服务器上。

　　C. 反向代理负载均衡：是应用层负载均衡，和反向代理功能集成在一起，部署简单，缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

　　D. IP负载均衡：也称为网络层负载均衡，在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。缺点是由于所有请求响应都需要经过负载均衡服务器，集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽。

　　E. 数据链路层负载均衡：也称为三角传输模式或直接路由方式，是目前大型网站使用最广泛的一种负载均衡手段，通过修改mac地址进行负载均衡。在Linux平台上最好的链路层负载均衡开源产品是LVS（Linux Virutal Server）。

　　常见的负载均衡算法有：

　　轮询：所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。

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

　　随机：此算法比较简单实用，请求被随机分配到各个应用服务器，因为好的随机数本身就很均衡。

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

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

　　（2）分布式缓存集群的伸缩性设计

　　分布式缓存集群的伸缩性不能使用简单的负载均衡手段来实现。因为分布式缓存服务器集群中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要的数据的服务器，然后才能访问。这个特点严重制约分布式缓存集群的伸缩性，因为新加入的缓存服务器没有任何数据，而已下线的缓存服务器还缓存着大量热点数据。缓存集群伸缩性设计的主要目标，就是让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到。

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

　　一致性Hash算法通过一个叫做一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射，使得新加入的服务器不影响大部分缓存数据的正确性。但这种算法的一个小问题是，可能造成部分节点缓存的数据库是其他节点的好几倍，可以通过加一个虚拟层，Hash环上是虚拟节点的Hash值，而一个物理节点对应多个虚拟节点。

　　（3）数据存储服务器集群的伸缩性设计

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

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

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

　　数据分库：不同业务数据表部署在不同的数据库集群上，但是跨库的表无法进行Join操作；

　　数据分片：对一些单表数据仍然很大的表，例如用户数据库、商品数据库等，还需要进行分片，将一张表拆分开分别存储在多个数据库中；

　　B. NoSQL数据库的伸缩性设计

　　NoSQL是关系数据库的补充，而不是替代方案。NoSQL数据库产品放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事务的一致性保证（ACID），与之对应的是强化高可用性和可伸缩性。开源社区的NoSQL产品不尽其数，其支持的数据结构和伸缩性特性也各不相同。目前看来，应用最广泛的是Apache HBase。

二、扩展性架构

　　可扩展架构的核心思想是模块化，并在此基础之上降低模块间的耦合。在大型网站中，模块通过分布式部署的方式，独立的模块部署在独立的服务器（集群）上，从物理上分离模块之间的耦合关系，进一步降低耦合性从而提高复用性。

　　1. 使用分布式消息队列降低系统的耦合性：

　　采用事件驱动架构（Event Driven Architecture），通过在低耦合的模块之间传输消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。对于新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展设计。典型的EDA架构就是操作系统中常见的生产者消费者模式。

　　2. 使用分布式服务打造可复用的业务平台

　　分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。除了服务发现和服务调用，大型分布式服务还有如下特点：负载均衡、失效转移、高效的远程通信、整合异构系统的能力、对应用最小侵入、服务版本管理和实时监控。典型的分布式服务如阿里巴巴的Dubble。

　　3. 采用可扩展的数据结构

　　比如使用支持ColumnFamily的NoSQL数据库

　　4. 利用开放平台建设网站生态圈：

　　大型网站把网站内部的服务封装一些调用接口开放出去，供外部的第三方开发者使用，第三方开发者利用这些开放的接口开发应用程序（APP）或者网站，这样一来，网站、用户、第三方开发者相互依赖，形成一个网站的生态圈，既为用户提供更多的价值，也提高了网站和第三方开发者的竞争能力和盈利能力。

三、思维导图

来自：

http://www.cnblogs.com/edisonchou/p/3851333.html

来自：http://www.cnblogs.com/edisonchou/p/3862389.html