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

左手的ㄟ右手 2023-01-20 08:10 80阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]  
前面提到，应用服务器应该设计成无状态的，即应用服务器不存储请 求上下文信息，如果将部署有相同应用的服务器组成一个集群，每次用户请求都可以发 送到集群中任意一台服务器上去处理，任何一台服务器的处理结果都是相同的。这样只 要能将用户请求按照某种规则分发到集群的不同服务器上，就可以构成一个应用服务器 集群，每个用户的每个请求都可能落在不同的服务器上。如图6.4所示。

如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现 集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务 器分发请求，那么就实现了应用服务器集群的伸缩性。

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

负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改 善网站的可用性，可谓网站的杀手铜之一。具体的技术实现也多种多样，从硬件实现到软 件实现，从商业产品到开源软件，应有尽有，但是实现负载均衡的基础技术不外以下几种。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]

--------------------

### 1 HTTP重定向负载均衡 ###

利用HTTP重定向协议实现负载均衡。如图6.5所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP 请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中 （响应状态码302 ）返回给用户浏览器。在图6.5中，浏览器请求访问域名 www.mysite.com, DNS服务器解析得到IP地址是114.100.80.10,即HTTP重定向服务 器的IP地址。然后浏览器通过IP地址114.100.80.10访问HTTP重定向负载均衡服务器 后，服务器根据某种负载均衡算法计算获得一台实际物理服务器的地址(114.100.80.3 ), 构造一个包含该实际物理服务器地址的重定向响应返回给浏览器，浏览器自动重新请求 实际物理服务器的IP地址114.100.80.3,完成访问。

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

--------------------

### 2 DNS域名解析负载均衡 ###

这是利用DNS处理域名解析请求的同时进行负载均衡处理的一种方案  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]

在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。

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。图6.6中的浏览器请求解析 域名www.mysite.com, DNS根据A记录和负载均衡算法计算得到一个IP地址114.100.80.3,并返回给浏览器；浏览器根据该IP地址，访问真实物理服务器H4.100.80.3o

DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS,省掉了网站管理维 护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名 解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。但 是DNS域名解析负载均衡也有缺点，就是目前的DNS是多级解析，每一级DNS都可能 缓存A记录，当下线某台服务器后，即使修改了 DNS的A记录，要使其生效也需要较长 时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败；而 且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。

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

--------------------

### 3 反向代理负载均衡 ###

利用反向代理服务器进行负载均衡  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]

前面我们提到利用反向代理缓存资源，以改善网站性能。实际上，在部署位置上， 反向代理服务器处于Web服务器前面（这样才可能缓存Web响应，加速访问），这个位 置也正好是负载均衡服务器的位置，所以大多数反向代理服务器同时提供负载均衡的功能，管理一组Web服务器，将请求根据负载均衡算法转发到不同Web服务器上。Web服 务器处理完成的响应也需要通过反向代理服务器返回给用户。由于Web服务器不直接对 外提供访问，因此Web服务器不需要使用外部IP地址，而反向代理服务器则需要配置双 网卡和内部外部两套IP地址。

图6.7中，浏览器访问请求的地址是反向代理服务器的地址114.100.80.10,反向代理 服务器收到请求后，根据负载均衡算法计算得到一台真实物理服务器的地址10.0.0.3,并 将请求转发给服务器。10.0.0.3处理完请求后将响应返回给反向代理服务器，反向代理服 务器再将该响应返回给用户。

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

--------------------

### 4 IP负载均衡 ###

在网络层通过修改请求目标地址进行负载均衡，如图6.8所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]

用户请求数据包到达负载均衡服务器114.100.80.10后，负载均衡服务器在操作系统 内核进程获取网络数据包，根据负载均衡算法计算得到一台真实Web服务器10.0.0.1,然 后将数据目的IP地址修改为10.0.0.1,不需要通过用户进程处理。真实Web应用服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改 为自身的IP地址（114.100.80.10）发送给用户浏览器。

这里的关键在于真实物理Web服务器响应数据包如何返回给负载均衡服务器。一种 方案是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址设为自身 IP,即源地址转换（SNAT ）,这样Web服务器的响应会再回到负载均衡服务器；另一种 方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数 据都会到达负载均衡服务器。

IP负载均衡在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的最 大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。对于提供下载服务或者视频 服务等需要传输大量数据的网站而言，难以满足需求。能不能让负载均衡服务器只分发 请求，而使响应数据从真实物理服务器直接返回给用户呢?

--------------------

### 5 数据链路层负载均衡 ###

顾名思义，数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负 载均衡，如图6.9所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]

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

在图6.9中，用户请求到达负载均衡服务器114.100.80.10后，负载均衡服务器将请求 数据的目的mac地址修改为00:0c:29:d2,并不修改数目包目标IP地址，由于Web服务器 集群所有服务器的虚拟IP地址都和负载均服务器的IP地址相同，因此数据可以正常传输 到达mac地址00:0c:29:d2对应的服务器，该服务器处理完成后发送响应数据到网站的网 关服务器，网关服务器直接将该数据包发送到用户浏览器(通过互联网)，响应数据不需 要通过负载均衡服务器。

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

--------------------

### 6 负载均衡算法 ###

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

1.  根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。
2.  将请求数据发送到该地址对应的Web服务器上。

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

**轮询(Round Robin, RR)**

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

**加权轮询(Weighted Round Robin, WRR)**

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

**随机（Random）**

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

**最少连接(Least Connections)**

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

**源地址散列（Source Hashing）**

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]: /images/20221021/3ff47ec4af454bc1800ec63e2384a134.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]: /images/20221021/d6a38876f043468a82955d7b15a2a47f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]: /images/20221021/fbaffbc632db4b65bb2eaa66576af47c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]: /images/20221021/0537ef9049184525b6f06fdfc9892917.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]: /images/20221021/3261972983c048c99842a414ab7c0e6e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]: /images/20221021/2a900437be624ac1964bc006f69c9448.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]: /images/20221021/0612a03dbf2647db92b1cc704a52c9ae.png