面经策

负载均衡的实现方式有哪些？ ​

  • 标签：Spring Cloud、微服务、负载均衡、后端

🏛 业务架构师 ​

负载均衡的实现方式按"在哪一层做"分类：

1. 硬件负载均衡：F5、A10——性能最强（百万级并发）、L4-L7 全覆盖，价格昂贵。今天基本只剩金融/运营商核心链路在用，互联网公司已被软件方案替代。

2. 软件/代理型（服务端集中式 LB）：

  • L4（传输层）：LVS、云 SLB——转发 TCP/UDP，性能高、不解析应用协议；
  • L7（应用层）：Nginx（HTTP/HTTPS 路由、静态资源、缓存）、HAProxy——能按 URL/Header/Cookie 做内容路由，灰度、路径分流的执行点；
  • K8s Service / kube-proxy（iptables/IPVS 模式）：平台原生 LB——云原生时代的默认形态。

3. 客户端负载均衡（进程内）：Spring Cloud LoadBalancer、Dubbo 内置 LB——微服务间调用的主流：从注册中心拿实例列表，调用方本地按策略选节点。优点：少一跳、无代理单点、摘除故障实例更敏捷；代价：策略散在每个客户端、语言绑定。

4. DNS 负载均衡：域名解析多 IP——全局/地域级第一层分流（多机房、CDN 调度），粒度粗（DNS 缓存导致摘除延迟），只做入口的第一跳。

架构师视角的分工实践：完整的流量链路是组合拳——DNS（地域分流）→ 云 SLB/LVS（四层入口）→ Nginx/Gateway（七层路由与灰度）→ 客户端 LB（服务间）。每层职责不同，不是替代关系而是分层协作；选型依据是流量规模、团队能力与已有平台，避免为小流量堆全套架构。

🏗 系统架构师 ​

按架构层级列谱系：

  • 硬件：F5/NetScaler——性能极限、昂贵，金融存量；
  • 软件 L4：LVS（DR/NAT 模式）、云厂商 SLB、K8s kube-proxy（iptables/IPVS，eBPF 新方案绕过 conntrack 提升吞吐）；
  • 软件 L7/反向代理：Nginx、Envoy、HAProxy——协议感知，路由/改写/限流；
  • 网关层：Spring Cloud Gateway、APISIX——带业务语义的入口 LB；
  • 客户端 LB：服务发现加消费方本地选实例（Spring Cloud LoadBalancer、Dubbo 内置）——少一跳网络、每个消费方独立重试与熔断，微服务东西向主流；
  • Service Mesh：sidecar 接管，LB 逻辑下沉基础设施。

选型逻辑：入口流量「DNS/云 LB（L4）→ 网关（L7）」两级；东西向「客户端 LB 或 mesh」。

核心权衡：每加一跳代理增加 RTT 与故障面——微服务内部调用加一层集中 proxy 通常不划算。这是客户端 LB 在 JVM 生态长盛的原因，也是 mesh 向 sidecar-less（Ambient、Cilium eBPF）演进的动因。

💻 全栈开发专家 ​

按位置分四类：

  1. 硬件：F5、A10——性能最强价格最贵，银行/电信存量
  2. 软件集中式（服务端）：
    • LVS：四层内核转发，性能极高，扛大流量入口
    • Nginx：七层反向代理，upstream 配置即集群
    • K8s Service/Ingress：kube-proxy iptables/IPVS，云原生标配
  3. 网关层：Spring Cloud Gateway/Kong/APISIX，API 层路由 + LB + 治理
  4. 客户端（进程内）：Spring Cloud LoadBalancer/Ribbon——Feign 调用前从实例快照里选，少一跳、去中心化

真实架构是组合：外部 DNS → LVS/F5 → Nginx/网关 → 服务间客户端 LB → 数据库中间件 LB（ProxySQL）。分工依据：四层快、七层活（按 path/header 路由）。

客户端 LB 的独特价值：与服务发现联动后实例变化秒级感知、可按调用方自定义策略（灰度标签路由、同机房优先）、无集中单点——这就是 LoadBalancer 在微服务里生命力所在。