大型网站技术架构，6网站的伸缩性架构之应用服务器集群的伸缩性设计

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

 

应用服务器应该设计成无状态的，这样，每次用户请求都可以发送到集群中任意一台服务器上去处理，任何一台服务器的处理结果都是相同的。

 

每个用户的每个请求都可能落在不同的服务器上，需要一个HTTP请求分发装置，可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。

 

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

 

负载均衡不但可以实现网站的伸缩性，同时还改善网站的可用性。下面具体阐述几种实现负载均衡的基础技术。

 

6.2.1 HTTP重定向负载均衡

根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中(响应状态吗302)返回给用户浏览器。

 

优点：方案简单

缺点：浏览器需要两次请求服务器才能完成一次访问，性能较差；

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

使用HTTP302响应吗重定向，有可能使搜索引起判断为SEO作弊，降低搜索排名。

 

实践中很少实用这种方案。

 

6.2.2 DNS域名解析负载均衡

在DNS服务器中配置一个域名对应多个IP

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回。

 

优点：

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

 

缺点：

目前的DNS时多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败；

而且DNS负载均衡的控制权在域名解析服务商那里，网站无法对其做更多改善和更强大的管理。

 

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

 

6.2.3 反向代理负载均衡

大多数反向代理服务器提供负载均衡的功能，将请求根据负载均衡算法转发到不同的Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。

由于Web服务器不直接对外提供访问，因此Web服务器不需要使用外部IP地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。

 

反向代理服务器工作在HTTP协议层面，也叫应用层负载均衡，7层负载均衡。

 

优点：

和反向代理服务器功能集成在一起，部署简单

 

缺点：

反向代理服务器时所有请求和响应的中转站，其性能可能会成为瓶颈。

 

6.2.4 IP负载均衡

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

 

关键在于真实物理Web服务器响应数据包如何返回给负载均衡服务器。

一种方案是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址设为自身IP，即源地址转换(SNAT)，这样Web服务器的响应会再回到负载均衡服务器；

另一种方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会到达负载均衡服务器。

 

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

对于提供下载服务或者视频服务等需要传输大量数据的网站而言，难以满足需求。能不能让负载均衡服务器只分发请求，而使响应数据从真实物理服务器直接返回给用户呢？

 

6.2.5 数据链路层负载均衡

指在通信协议的数据链路层修改mac地址进行负载均衡

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

 

使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。

在Linux平台上最好的链路层负载均衡开源产品时LVS(Linux Virtual Server)。

 

6.2.6 负载均衡算法

负载均衡服务器的实现可以分为两个部分：

1. 根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。

2.将请求数据发送到该地址对应的Web服务器上。

 

前面描述了如何将请求数据发送到Web服务器，而具体的负载均衡算法通常有以下几种。

 

轮训(Round Robin ,RR)

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

 

加权轮询(Weighted Round Robin,WRR)

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

 

随机(Random)

请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以使用加权随机算法。

 

最少连接(Least Connections)

记录每个应用服务器正在处理的连接数(请求数)，将新的请求分发到最少连接的服务器上，应该说，这时最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最少连接。

 

源地址散列(Source Hashing)

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

 

总结：

应用服务器集群的伸缩性设计，主要就是用负载均衡。本节讲了如何将请求数据发送到Web服务器，也讲了具体的算法。

这一节，需要对网络的基础知识有所了解，对于具体的负载均衡算法了解即可，当然能够自己手写更好，可以加深理解。

 

对于本节的知识点需要了解到什么程度，就是你能够自己讲出来，真正理解就可以了。

 

而理解本身，可能需要通过实践，自己架设网络、手写算法，才能够真正理解，或者单纯的牢记重要的负载均衡方案和算法。只要你可以理解负载均衡方案和算法，别人问你时，你可以说的很清楚，举例子将也好，对比优缺点也好，手写关键伪代码也好。