非等同负载均衡是什么，工作原理和应用场景有哪些？

什么是非等同负载均衡

非等同负载均衡是指在后端服务器集群中,不将每台服务器视为同等能力的处理单元，而是根据其实际处理能力、当前负载状态、硬件配置或业务优先级等因素，将请求按不同比例分发给不同节点的策略，与传统的轮询（Round Robin）或随机分配等等同负载均衡不同，非等同方案更贴近真实场景，能有效避免“木桶效应”，提升整体资源利用率。

核心设计思想

• 权重（Weight）：为每台服务器分配一个权值，权值越大，被分配到的请求比例越高。
• 动态调整：可根据实时指标（如CPU、内存、连接数、响应时间）动态修正权重，实现自适应负载均衡。
• 差异化服务：允许高性能机器承担更多流量，低性能机器处理轻量任务，同时支持主备、灰度发布等场景。

常见实现算法

加权轮询（Weighted Round Robin）

每台服务器拥有一个静态或动态权重,调度器按权重比例依次分配请求，例如三台服务器A（权重5）、B（权重3）、C（权重2），则每10个请求中A处理5个，B处理3个，C处理2个。

优点：实现简单，无需实时状态，适用于请求处理时间相对均匀的场景。

缺点：无法感知节点实时负载，当权重设置不合理时仍可能导致部分节点过载。

加权最少连接（Weighted Least Connections）

在传统最少连接算法基础上引入权重,调度器优先选择当前活跃连接数与权重比值最小的节点，公式通常为：连接数 / 权重，比值越小越优先。

优点：能动态响应负载变化，适合长连接或请求处理时间差异大的应用。

缺点：需要维护连接计数，增加调度开销；权重设定不当仍可能失衡。

动态权重算法（如基于CPU/内存的反馈）

定期采集服务器的CPU使用率、内存占用、响应时间等指标，通过算法实时计算出一个动态权重，并以此为基础进行调度，例如Nginx的ngx_http_upstream_dynamic_module或云原生网关的智能路由。

优点：高度自适应，能应对突发流量和节点故障。

缺点：引入监控和反馈延迟，控制逻辑复杂，可能产生振荡。

对比表格：等同 vs 非等同负载均衡

典型应用场景

1. 异构集群：不同代际的服务器混合部署，老机器权重低，新机器权重高。
2. 主备架构：主节点权重100，备用节点权重0或低值，实现故障切换。
3. 灰度发布：新版本实例权重设为0.1，仅引流少量用户测试。
4. 云原生环境：容器化部署中，根据Pod的CPU/内存请求值自动分配权重，配合HPA（水平自动扩缩）。

优势与注意事项

优势

• 提升资源利用率：避免高性能节点闲置，低性能节点过载。
• 支持差异化服务：满足特殊业务需求（如VIP通道、付费优先）。
• 动态响应：结合实时监控可自动规避故障节点。

注意事项

• 权重设置需基于准确的性能基准测试,否则可能适得其反。
• 动态算法需考虑反馈延迟,避免权重频繁抖动导致调度不稳定。
• 需搭配健康检查机制,防止权重为0的节点仍被错误分配请求。

相关问题与解答

问题1：非等同负载均衡中的权重应该如何设定？是否可以用响应时间作为唯一指标？

解答：权重的设定通常需要综合考虑多种因素，不建议仅依赖响应时间，主要原因如下：

• 响应时间受网络抖动、后端缓存命中率、客户端分布等影响，波动较大，单一指标容易导致误判。
• 静态权重可基于硬件配置（CPU核数、内存大小、磁盘IOPS）进行基准测试后设定；动态权重可以融合CPU使用率、连接数、错误率等多项指标，通过加权公式计算，例如经典方案：动态权重 = 基础权重 × (1 CPU使用率) × (1 内存使用率)，实际生产中，常采用最小响应时间 + 加权最小连接的组合策略，但需辅以滑动窗口平均来平滑数据。

问题2：在Kubernetes环境中，Service默认的负载均衡策略是什么？如何实现非等同负载均衡？

解答：Kubernetes Service默认使用基于iptables/IPVS的轮询（等同）模式，所有Pod按相等概率被选中，要实现非等同负载均衡，有两种常见方法：

• 使用Service的sessionAffinity：仅能实现基于客户端IP的会话保持，并非真正的加权。
• 引入Ingress Controller或Service Mesh：例如Nginx Ingress Controller支持weight字段，通过nginx.ingress.kubernetes.io/weight注解为后端Pod设定权重，更灵活的方式是采用Istio或Linkerd等Service Mesh，通过DestinationRule里的loadBalancer字段设置simple: LEAST_CONN或consistentHash，并配合subset和weight实现灰度发布与流量比例控制。