互联网常见负载均衡架构图是怎样的？负载均衡架构有哪些常见类型

在互联网架构中，负载均衡（Load Balancing, LB）是解决高并发、高可用性和高性能问题的核心组件，它通常位于客户端和后端服务器集群之间，通过特定的算法将流量分发到不同的后端节点，从而避免单点故障并优化资源利用率,以下是互联网常见负载均衡架构的详细。

负载均衡的层级划分

根据部署位置和协议不同，负载均衡架构通常分为三个主要层级,每一层解决不同的痛点：

1. L4 传输层负载均衡

   • 原理：基于 IP 地址和端口号进行转发,不解析应用层数据。
   • 特点：性能极高，延迟极低，但无法根据 URL、Cookie 或 Header 进行精细化的流量控制。
   • 典型技术：LVS (Linux Virtual Server)、Nginx (Stream 模块)、HAProxy (TCP 模式)。

2. L7 应用层负载均衡

   • 原理：能够解析 HTTP/HTTPS 协议，根据 URL 路径、域名、Header 等信息进行路由决策。
   • 特点：功能丰富，支持会话保持、SSL 卸载、WAF（Web 应用防火墙）集成，但相比 L4 消耗更多 CPU 资源。
   • 典型技术：Nginx、Apache HTTP Server、Envoy、Kong。

3. 云原生/服务网格层负载均衡

   • 原理：在微服务架构中，负载均衡逻辑下沉到 Sidecar 代理（如 Istio 中的 Envoy）或 Service Mesh 控制平面。
   • 特点：实现服务间的自动发现、熔断、限流和灰度发布,对业务代码无载入。
   • 典型技术：Istio、Linkerd、Consul Connect。

常见负载均衡架构模式

在实际生产环境中，单一层的负载均衡往往不足以应对复杂场景,因此常采用组合架构。

经典三层架构

这是最传统的互联网架构模式,流量依次经过：

• DNS 负载均衡：通过智能 DNS 解析,将用户请求分发到不同地域的入口服务器。
• L4/L7 负载均衡器：接收流量，进行初步分发和 SSL 终止。
• Web/App 服务器集群：处理具体业务逻辑。

反向代理架构

在此架构中，负载均衡器作为反向代理，隐藏后端服务器的真实 IP 和结构。

• 优势：安全性高，便于统一配置 SSL 证书,支持动静分离。
• 适用场景：大多数 Web 应用、API 网关前置层。

全局服务器负载均衡 (GSLB) + 本地负载均衡 (LSB)

• GSLB：位于数据中心之间，根据用户地理位置、数据中心负载情况,将流量引导至最近的可用数据中心。
• LSB：在每个数据中心内部,负责将流量分发到该机房内的具体服务器。
• 优势：实现多活容灾，提升用户体验（低延迟）。

核心负载均衡算法

负载均衡器的核心在于“如何决定下一个请求发给谁”,以下是几种主流算法：

高可用与容灾设计

负载均衡本身也可能成为单点故障,因此必须设计高可用架构：

1. 主备模式 (Active-Standby)

   • 使用 VRRP (Virtual Router Redundancy Protocol) 或 Keepalived 实现。
   • 主节点处理流量，备节点实时同步状态，主节点故障时，VIP (虚拟 IP) 漂移至备节点。
   • 缺点：备节点资源闲置,利用率低。

2. 双活模式 (Active-Active)

   • 多台负载均衡器同时处理流量，通过 DNS 或 GSLB 进行分发。
   • 优点：资源利用率高,故障切换速度快。
   • 挑战：需要解决会话共享问题（Session 共享至 Redis 或数据库）。

3. 健康检查 (Health Check)

   • 负载均衡器定期向后端服务器发送探测请求（HTTP GET、TCP 连接、Ping 等）。
   • 若后端节点连续多次失败，则将其从可用池中剔除,待恢复后重新加入。
   • 关键配置：检查间隔、超时时间、失败阈值、恢复阈值。

现代云环境下的负载均衡

在 Kubernetes 和云原生环境中,负载均衡架构发生了显著变化：

• Ingress Controller：作为 Kubernetes 集群的入口，将外部流量通过 Service 路由到 Pod，常见实现有 Nginx Ingress、Traefik、HAProxy Ingress。
• Service 类型：
  • ClusterIP：集群内部访问，内置 kube-proxy 的 iptables/ipvs 负载均衡。
  • NodePort：通过节点端口暴露服务,适合测试。
  • LoadBalancer：云厂商提供的云负载均衡器（如 AWS ALB/NLB, Azure LB），自动绑定弹性 IP。

• Service Mesh (Istio)：将负载均衡逻辑从基础设施层下沉到应用层，实现更细粒度的流量管理（如金丝雀发布、故障载入）。

归纳与选型建议

选择负载均衡架构时,需综合考虑以下因素：

1. 性能需求：高并发、低延迟场景优先选择 L4 负载均衡（如 LVS、F5）；需要复杂路由、SSL 卸载场景选择 L7（如 Nginx、Envoy）。
2. 高可用要求：关键业务必须采用双活或多活架构,配合健康检查和自动故障转移。
3. 运维复杂度：传统硬件负载均衡器成本高但运维简单；开源软件负载均衡器灵活但需自行维护；云托管负载均衡器省心但成本较高且绑定云厂商。

4. 扩展性：微服务架构下，建议采用服务网格或 Ingress 控制器,实现动态服务发现和自动负载均衡。

   相关问题与解答

   问题 1：在微服务架构中，为什么越来越多的公司选择使用 Service Mesh（如 Istio）而不是传统的 Nginx 网关进行服务间负载均衡？

   解答：

   传统 Nginx 网关主要解决的是南北向流量（外部用户到后端服务）的负载均衡，而 Service Mesh 更擅长处理东西向流量（服务与服务之间）的负载均衡,主要原因包括：

   1. 业务无载入：Service Mesh 通过 Sidecar 代理（如 Envoy）接管流量，业务代码无需修改即可实现负载均衡、熔断、重试等功能。
   2. 动态服务发现：Kubernetes 中 Pod 的 IP 和端口频繁变化，Service Mesh 能实时感知并更新路由表,而传统网关可能需要手动配置或依赖复杂的注册中心集成。
   3. 细粒度流量控制：Service Mesh 支持基于 Header、权重、延迟等维度的精细化流量切分（如金丝雀发布、A/B 测试）,这是传统网关难以高效实现的。
   4. 统一治理：所有服务共享同一套控制平面，策略配置一致,避免了每个服务单独配置负载均衡规则的复杂性。

   问题 2：当后端服务器出现“热节点”问题（即某些节点负载过高，而其他节点空闲）时，除了调整加权轮询算法，还有哪些技术手段可以缓解？

   解答：

   “热节点”通常由请求分布不均或后端处理速度差异引起，除了调整加权轮询,还可以采取以下措施：

   1. 启用最少连接数算法 (Least Connections)：该算法会将新请求分配给当前活跃连接最少的节点，自动平衡负载,特别适合处理时间不一致的场景。
   2. 实现会话亲和性 (Session Affinity) 的优化：如果会话数据存储在集中式缓存（如 Redis）而非本地内存，可以移除 IP Hash，改用轮询或最少连接算法,避免固定节点过载。
   3. 后端应用层限流与降级：在应用内部实现令牌桶或漏桶算法，限制单个节点的处理速率，防止其被请求打满,从而保护系统整体稳定性。
   4. 引入一致性哈希 (Consistent Hashing) 的虚拟节点：在缓存场景中，通过增加虚拟节点数量，使哈希环分布更均匀，减少因节点增减或热点 Key 导致的负载倾斜。
   5. 动态权重调整：结合监控系统（如 Prometheus），根据实时 CPU、内存或响应时间动态调整负载均衡器的后端权重,实现自适应负载均衡。