当前位置：首页 > 尘凡 > 正文内容

一文搞懂应用集群负载不均问题

满纸空言2年前 (2023-05-04)尘凡18340

转自：一文搞懂应用集群负载不均问题_zlzlzl100的博客-CSDN博客

负载均衡原理

负载均衡设备的原理就是把大量的客户端访问请求通过网络技术分散到一组服务器集群中的可用服务器上，降低单台服务器的资源压力，提升整体服务性能。它提供了一种有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

金融行业多是使用的产品级的硬件负载均衡，其稳定性高、性能强、适用性广，对于强调稳定运行的业务系统来说是不错的选择。然而，即使采用这么专业的设备，依然避免不了发生负载不均衡的情况，这还要从负载均衡负载的原理说起。

负载均衡设备是基于网络层TCP连接进行负载分配的，这也是部分企业负载均衡设备由网络部门运维的原因。当客户端将TCP建链请求发送到负载均衡设备后，负载均衡会根据负载均衡算法（轮询、最小连接数、比率等），将连接分配到后端服务器，实现TCP连接分配的均衡。

从负载均衡原理可以看出来，负载的最小单位应该是TCP连接。开头的案例中，应用管理员评价服务器是否均衡使用了“业务量”这个词，“业务量”在应用系统上通常表现为交易请求数量，或者对于BS类应用可以更简化一点，约等于HTTP请求数量，当且仅当每个TCP连接只进行一笔交易的时候，连接数和交易量才是相等的。

所以当我们考量服务器集群的服务器是否均衡的时候，网络层面和应用层面首先要做的是首先使用统一的语言和衡量单位，下面我会从连接数和交易量两个维度来讲解负载不均衡的问题。

一、连接数不均衡

会话保持原因引起不均衡

现象：负载均衡设备上统计数据显示服务器连接不均衡。

分析：这是最常见的一种不均衡情况，90%是因为会话保持参数引起的。在此先解释一下负载均衡的会话保持机制。某些要求登录状态的情景下，要求客户端和服务器之间保持一个会话以记录客户端的各种信息。比如在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时往往需要了解上一次或上几次的交互过程处理结果，这就要求所有这些相关的交互过程都由同一台服务器完成。会话保持机制就是实现将相同客户端的请求转发到同一个后台服务器的一种机制。可以预见的，使用了会话保持机制后，负载均衡设备不再依据负载均衡算法来进行均衡的连接分配，而是优先判断是否为同一客户端的请求，当客户端数量较少，且个别客户端连接请求数特别多的时候，就会造成会话保持到的目标服务器连接数远大于其他服务器。

解决：会话保持机制的使用将影响负载均衡连接分配的均衡性，此时如果使用“轮询算法”（依次给后端服务器分配连接）或者“随机算法”（随机给后端服务器分配连接）将会加重负载不均的情况，建议使用“最小连接数”作为负载算法（优先给连接数最少的服务器分配连接）。强烈建议服务器之间同步会话或者使用会话服务器来实现系统的无状态化，充分发挥负载均衡的能力。
健康检查结果不稳定原因导致不均衡

现象：负载均衡设备上统计数据显示现在的服务器连接均衡，但是某台服务器的交易日志明显变少

分析：为了监测服务器状态，让机器能自动理解判断后端应用的可用状态，负载均衡一般引入了健康检查机制，负载均衡会定期对服务器的操作系统或服务端口或者应用页面进行访问，如果健康检查失败，负载均衡设备会将该设备状态标记为不可用状态，并停止给其分配新连接。如果健康检查结果时好时坏，那负载均衡只会在健康检查状态好的时候给其分配的连接，服务器上的总体交易量就会减少，造成负载不均衡的现象。

解决：需要从服务器上查明原因，是什么导致了负载均衡健康检查失败，如果确认服务器不存在故障，可以考虑以下几个方面：
- 服务器设置了某种连接数限制，或者某些计数器已经触达了上限值；
- 服务器存在某些安全机制拦截了健康检查请求；
- 是否存在性能原因，CPU、内存、连接数、带宽到达容量上限。
其他连接不均衡情况

现象：负载均衡上观察后端服务器连接分布比较均衡，服务器上直接观察出现连接数不均衡的情况。

分析：当使用“最小连接数”算法时，负载均衡通过统计经过自身访问后端的连接数来判断后端服务器的连接数，由于各系统连接拆除的机制很复杂，无法保证负载均衡统计值和后端服务器的统计数是一致的，但正常情况下还是可以做到基本均衡，出现不均衡考虑以下两种情况：

（1）检查服务器连接表，是否存在有绕过负载均衡虚拟VS地址，有用户直接访问后端服务器实地址的情况，检查是否为IT管理类、监控类或其它批量类连接导致服务器连接统计值增加；

（2）服务器是否存在连接回收慢的情况，通常一笔查询访问或业务交易完成后，“客户端–>防火墙–>负载均衡设备–>应用服务器设备”交易路径上各类设备连接应该及时关闭或回收，避免堆积提升网络处理性能；若后端应用没有快速关闭连接，而是长期停留在FIN_WAIT状态（TCP半关闭状态），而负载均衡端认为连接已经正常回收，可能出现服务器连接数很多（主要是半关闭状态的连接），但是负载均衡认为这台服务器连接数最少，继续给其分配连接的情况。

解决：针对第二种情况，半关闭状态是由于TCP关闭的四次握手没有正常完成引起的，具体原因比较复杂，比如双方断链的机制不同，操作系统TCP参数设置的问题等，建议通过网络流量抓包分析，具体问题具体分析调优。

二、交易量不均衡

长连接导致交易量不均衡

现象：负载均衡上观察后端服务器连接分布比较均衡，服务器连接数均衡，交易量不均衡。

分析：为充分利用网络资源，一个TCP连接通常会进行多笔交易，甚至为了最大化降低网络开销，应用会长期维持一个TCP连接，用于传递交易数据。显而易见，对于一个长连接，负载均衡一旦进行负载分配后，交易量将长期产生在长连接的目标服务器，而因为没有新的连接请求，其他服务器则无法通过负载均衡获得新的交易量。交易量自然就无法均衡。

解决：负载均衡不建议部署长连接应用，短连接、无状态化的应用系统更适合部署负载均衡设备。
集中式重客户端导致交易量不均衡

现象：整体连接数较少，负载均衡和服务器上连接数都均衡，交易量不均衡。

分析：由于整体连接数不多，建议将明细连接表打印出来逐个分析，可能存在集中式重客户端（多为代理服务器），相较于其他客户端，其一个客户端发起的交易量占总体交易量相当大的比重，导致该客户端所连的服务器交易量远大于集群内其他服务器。

解决：有时从交易日志中统计每笔交易的源IP也可以得到此结论。服务器性能足够的话可以继续观察，随着客户端数量增多，该现象将会缓解。
服务器处理能力差别导致交易量不均衡

现象：连接数较多，负载均衡上和服务器上观察到的连接数也均衡，交易量不均衡。

分析：秘密就在服务器处理能力上。不同性能的服务器处理一个交易的时间是有差别的，当面临一个高频交易的业务，而服务器集群的服务器性能又不一致，比如虚拟机和高性能物理机混合使用，那么计算性能返回快的服务器会快速做完交易后拆连接，负载均衡如果使用“最小连接数算法”（连接优先分配给连接数最小的服务器）的话，就会快速分配新的连接给高性能服务器，而不管在哪个时间点看，所有服务器上的连接数又都是均衡的，其实是一种动态的平衡。

解决：出现这个现象是由于不同性能的服务器组成集群，如果条件允许，建议更换为相同性能的服务器，或者使用“带权重的负载均衡算法”（全手工设置服务器权重，权重高的服务器将获得更多的连接），当然由于高性能服务器拆除连接更快，本身就可以处理更多的交易量，不做任何调整也是可以接受的。

三、无状态化

希望最大限度地降低负载均衡不均发生的可能性，就不得不提服务器的无状态化，从网络层面简单理解，判断一个应用服务器是否无状态化的方法是有两个基本方法：（1）两个来自相同发起者的请求在服务器端是否具备上下文关系；（2）一个应用服务异常需要启动是否和其他应用有依赖关系。状态化请求：服务器端一般都要保存请求的相关信息，每个请求可以默认地使用以前的请求信息。无状态请求：服务器端所能够处理的过程必须全部来自于请求所携带的信息，以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息。从这个定义上看，有状态的服务器要部署负载均衡，必然要使用长连接或者会话保持技术，引起负载的不均衡化。

另外要提到的就是容器云原生的ingress控制器就是一个极其简单的负载均衡器，几乎不具备长连接、会话保持等能力，其设计思路其实建立在无状态化的系统架构基础之上，作为一个透明的容器业务入口而存在。但是在很多业务转向微服务化时并没有同步实现系统无状态化的改造，导致容器云ingress无法适应系统部署需求，最终还是将ingress替换成了传统负载均衡设备，因为状态的存在，微服务化的应用系统也变得更为复杂，虽然采用传统负载均衡的技术解决问题稳态部署，但也存在无法发挥云平台整体资源灵活调度和故障自愈能力的问题。