跳至主要內容

SLB(负载均衡)

Kinger2026/7/23大约 5 分钟AI基础设施

在大模型与分布式云原生架构中，SLB（Server Load Balancer，负载均衡） 是一项至关重要的核心流量调度与分发底座。

一句话道破本质：SLB 就像是一个拥有上帝视角的“超级流量交警”。它物理驻留在你的服务器集群最外层，负责统一接收来自全网的用户请求（如成千上万个 Agent 发起的并发推理请求），然后根据各台算力服务器（Pod/Node）当前的健康状况与算力水位，将这些请求精准、均匀地分发（Load Balance）给后端的不同机器，从而防止单机被大流量瞬间冲垮，确保整个 AI 系统的高可用与丝滑响应。

一、 核心物理工作流：SLB 是如何工作的？

当一个外部应用要访问你部署在 K8s 集群里的 AI 智能体（Agent）服务时，数据包会经历以下物理流转：

 【 全网并发用户 / Agent 客户端 】
             │ (通过同一个统一的公开公网 IP / 域名发起请求)
             ▼
 ┌────────────────────────────────────────────────────────┐
 │            SLB 负载均衡器 (流量网关层)                 │
 │  - 负责 SSL 证书卸载、高防清洗                         │
 │  - 24小时不间断高频“健康检查” (Health Check)           │
 └───────────┬────────────────────────────────────────────┘
             │
             ├──────────────────────┬──────────────────────┐ (根据算法调度分流)
             ▼                      ▼                      ▼
 ┌──────────────────────┐┌──────────────────────┐┌──────────────────────┐
 │ 8卡服务器 A (Pod 1)  ││ 8卡服务器 B (Pod 2)  ││ 8卡服务器 C (Pod 3)  │
 │ [ 算力富余，正常接单 ]││ [ 算力吃紧，少分流量 ]││ [ 硬件故障，物理隔离 ]│
 └──────────────────────┘└──────────────────────┘└──────────────────────┘
  1. 统一门禁，阻断直连：所有外部客户端都不需要、也无法知道后端具体某台 8 卡服务器的真实物理 IP。它们统一访问 SLB 提供的虚拟 IP（VIP）。
  2. 高频体检，故障熔断（Health Check）：SLB 会以秒级频率向后端的每台机器发送心跳包（比如嗅探 /healthz 接口）。如果服务器 C 突然因为我们前文聊过的“显卡掉线/XID报错”而导致服务挂掉，SLB 会在毫秒级内将其物理隔离，并把随后的新流量全部转给 A 和 B，对终端用户做到完全零感知的故障自愈。
  3. 算法分流，压榨集群：SLB 拿着流量表，根据特定算法（如轮询 Round Robin、最小连接数 Least Connections、加权轮询等）把并发请求打散到后端机器。

二、 工业界两大物理级别：四层 SLB vs. 七层 SLB

在云厂商（如阿里云、腾讯云或 AWS）的架构中，SLB 通常被物理切分为两个维度：

1. 四层负载均衡（Layer 4 - 网络传输层 —— 代表：阿里云 NLB / CLB）

  • 物理原理：它只看数据包的 IP 地址和端口号（TCP/UDP）。它不拆开包裹看里面的具体内容，直接像转交快递一样把数据包转发到后端。
  • 物理红利：性能强到爆炸，吞吐量极高，延迟近乎为零。因为它不做复杂的应用层文本解析。
  • 大模型场景：非常适合用来做分布式训练节点之间、或者是大模型底座暴露出来的标准 TCP 通信流的骨干转发。

2. 七层负载均衡（Layer 7 - 应用层 —— 代表：阿里云 ALB / Ingress 网关）

  • 物理原理：它会把数据包拆开，深度解析应用层协议（如 HTTP、HTTPS、gRPC）。它可以根据你请求的 URL 路径、Header 头、甚至是 Cookie 来决定转发给谁。
  • 物理红利：极度智能。例如可以实现 SSL 证书一键卸载（在 SLB 上把 HTTPS 解密成普通的 HTTP，免去后端 GPU 服务器去耗费算力解密）。
  • 大模型场景：
  • 自回归推理分流：根据 HTTP 路径分流。如果请求是 /v1/chat/completions（文字对话），转给 Llama 3 算力池；如果是 /v1/images/generations（生图），转给 Stable Diffusion 算力池。
  • 智能体路由：根据用户 Header 里的 Token，把高价值 VIP 客户的 Agent 请求优先路由到配备了 NVIDIA B200 的极致高性能队列中。

三、 联动闭环：SLB 与 K8s、Volcano 的化学反应

在现代云原生 AI 算力底座中，SLB 通常不会由工程师手动去云控制台一行行配置，而是通过 K8s 的 Service 机制实现完全自动化编排。

当你用 Pulumi 或 YAML 部署好你的推理 Agent 容器群时，你会创建一个类型为 type: LoadBalancer 的 Service：

apiVersion: v1
kind: Service
metadata:
  name: claudecode-agent-service
  annotations:
    # 🌟 声明式注射：通知阿里云/AWS，直接在后台为我自动购买并物理绑定一个七层高性能 SLB
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s3.medium"
spec:
  ports:
    - port: 80        # SLB 监听的外部端口
      targetPort: 8080 # 后端 Agent 容器真实的业务端口
      protocol: TCP
  selector:
    app: claudecode-agent # 自动抓取带有这个标签的所有 Pod
  type: LoadBalancer # 核心：直接向云厂商索要 SLB

底层联动过程：

  1. K8s 控制器监测到这个 YAML，自动调用云厂商 API 创建一个真实的物理 SLB。
  2. 随后，无论是由于业务激增导致你的容器弹性扩容（比如从 2 台变 10 台），还是 Volcano 调度器动态把 Pod 搬迁到了另一台物理机上，K8s 内部的 Endpoints 控制器都会实时、自动地把最新的 Pod 真实 IP 同步给 SLB 的后端转发列表（Target Group）。
  3. 整个过程没有任何人工介入，智能体（Agent）的算力通路在 SLB 的护航下实现无限弹性和绝对的高可用。