第6章:永无止境:网站的伸缩性架构
所谓的网站的伸缩性是指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
网站架构的伸缩性设计
网站的伸缩性设计一般可以分为两类:
- 根据功能进行物理分离实现伸缩
- 单一功能能通过集群实现伸缩
不同功能进行物理分离实现伸缩
物理分离实现伸缩:
- 纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性;
- 横向分离:将不同的业务模块分离部署,实现系统的伸缩性;
单一功通过集群规模实现伸缩
使用服务器集群,即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说,集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同,技术实现也有很大的区别。
应用服务器集群的伸缩性设计
应用服务器那点必须知道的事儿
应用服务器应该被设计成无状态的,即应用服务器不存储请求上下文信息;构建集群后,每次用户的请求都可以发到集群中任意一台服务器上处理,任何一台服务器的处理结果都是相同的;
HTTP本身是一个无状态的连接协议,为了支持客户端与服务器之间的交互,我们就需要通过不同的技术为交互存储状态,而这些不同的技术就是Cookie和Session了。
HTTP请求的分发是应用服务器集群实现伸缩性的核心问题,而负载均衡服务器就是HTTP请求的分发装置,它是网站必不可少的基础手段。
负载均衡技术—网站必不可少的基础技术手段
负载均衡的实现方式多种多样,从硬件到软件,从商业产品到开源产品,应有尽有。但是,实现负载均衡的基础技术不外乎以下几种:
- HTTP重定向负载均衡
- 优点:简单易行
- 缺点:
- 浏览器需要两次请求才能完成一次访问,性能较差;
- 重定向服务器自身的处理能力有可能成为瓶颈,整个集群的伸缩性规模有限;
- 使用HTTP 302重定向有可能使搜索引擎判断为SEO作弊,降低搜索排名;
- 结论:实际上使用该方法的不多。
- 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负载均衡的控制权在域名服务商那里,网站无法对其做更多改善和管理
- 结论:大型网站总是部分使用DNS域名解析,利用域名解析作为第一级负载均衡手段,即域名解析得到的一组服务器不是实际的Web服务器,而是同样提供负载均衡的内部服务器,这组内部服务器再进行负载均衡,请求分发到真实的Web服务器上。
- 配置:要求在DNS服务器中配置多个A记录,例如
- 反向代理负载均衡
- 配置:Web服务器不需要使用外部IP地址,而反向代理服务器则需要配置双网卡和内外部两套IP地址
- 优点:和反向代理服务器功能集成在一起,部署简单
- 缺点:反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈。
- IP负载均衡
- 配置:在网络层通过修改请求目标地址进行负载均衡
- 优点:在内核进程完成数据分发,较反向代理负载均衡(在应用程序中分发数据)有更好的处理性能
- 缺点:由于所有请求响应都需要经过负载均衡服务器,集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。
- 数据链路层负载均衡
- 配置:在通信协议的数据链路层修改 mac 地址进行负载均衡
- 优点:此种方式又称作三角传输模式,负载均衡数据分发过程中不修改IP地址,只修改mac地址,由于实际处理请求的真实物理IP地址和数据请求目的IP地址一致,所以不需要通过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。
- 结论:使用三角传输模式的链路层负载均衡是目前大型网站使用最广泛的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS(Linux Virutal Server)。
负载均衡算法
负载均衡服务器的实现:
- 根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址;
- 将请求数据发送到改地址对应的 Web 服务器上。
负载均衡算法:
- 轮询
- 所有请求被以此分发到每台应用服务器上,即每台服务器需要处理的请求数目都相同,适合于所有服务器硬件都相同的场景。
- 加权轮询
- 根据应用服务器的配置性能的情况,在轮询的基础上,按照配置的权重将请求分发到每个服务器,高性能的服务器能分配更多的请求。
- 随机
- 此算法比较简单实用,请求被随机分配到各个应用服务器,因为好的随机数本身就很均衡。
- 最少连接
- 记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到最少连接的服务器上,应该说,这是最符合负载均衡定义的算法。
- 源地址散列 *根据请求来源的IP地址进行Hash计算得到应用服务器,这样来自同一个IP地址的请求总在同一个服务器上处理,该请求的上下文信息可以存储在这台服务器上,在一个会话周期内重复使用,从而实现会话粘滞。
分布式缓存集群的伸缩性设计
不同于应用服务器集群的伸缩性设计,分布式缓存集群的伸缩性不能使用简单的负载均衡手段来实现。因为:分布式缓存服务器集群中缓存的数据各不相同,缓存访问请求不可以在缓存服务器集群中的任意一台处理,必须先找到缓存有需要的数据的服务器,然后才能访问。
分布式缓存集群伸缩性设计的目标:让新上线的缓存服务器对整个分布式缓存集群影响最小,也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到。
以Memcached为代表的分布式缓存集群的访问模型
以Memcached为代表的分布式缓存集群的伸缩性挑战
分布式缓存的一致性Hash算法
数据存储服务器集群的伸缩性设计
首先,数据存储服务器必须保证数据的可靠存储,任何情况下都必须保证数据的可用性和正确性。因此,缓存服务器集群的伸缩性架构方案不能直接适用于数据库等存储服务器。
关系数据库集群的伸缩性设计
NoSQL数据库的伸缩性设计
文章来源
- 作者:李智慧
- 来源:《大型网站技术架构》