4. 使用Cloud Load Balancing实现南北向流量治理

南北向流量指的是从集群外部进入、或从集群内部出去访问外部服务的流量。在微服务架构中,南北向流量治理的核心目标是:让外部用户以稳定、低延迟的方式访问服务,同时把流量按业务规则分发到不同版本、不同区域或不同后端。Google Cloud 的 Cloud Load Balancing 提供了多种负载均衡器,其中与南北向治理最相关的是全局外部应用负载均衡器和区域内部负载均衡器。理解它们的适用边界和流量分配机制,是设计可靠入口层的前提。

全局外部负载均衡:面向公网用户的统一入口

全局外部应用负载均衡器(Global External Application Load Balancer)工作在 OSI 第七层,使用 HTTP/HTTPS 协议,通过一个任播(Anycast)全局 IP 地址对外提供服务。用户无论从哪个地区访问,都会被 Google 的边缘网络就近接入,再经由 Google 的私有骨干网转发到最近且健康的后端。这一特性使它在跨区域部署场景中天然具备低延迟和故障切换能力。

它的核心组件包括:全局转发规则(Forwarding Rule)、目标 HTTP(S) 代理、URL 映射(URL Map)、后端服务(Backend Service)以及健康检查。URL 映射决定了“什么路径转发到哪个后端服务”,这是实现基于路径的流量治理的关键。例如,可以把 /api/v1/* 指向 v1 后端,把 /api/v2/* 指向 v2 后端,从而在不改变域名的情况下完成版本路由。

后端服务中最重要的参数是容量(Capacity)。对于实例组后端,容量以“每个实例的最大 RPS”表示;对于 NEG(Network Endpoint Group)后端,容量以“每个端点的最大 RPS”表示。负载均衡器会根据各后端的容量比例分配流量。假设后端 A 的容量为 100 RPS,后端 B 的容量为 300 RPS,则流量大致按 1:3 分配。这一机制是后续流量分配策略的基础。

区域内部负载均衡:集群内部的东西向与南北向边界

区域内部负载均衡器(Regional Internal Application Load Balancer 或 Regional Internal Proxy Network Load Balancer)使用仅限 VPC 内部访问的 IP 地址,不暴露到公网。它通常用于以下场景:内部微服务之间的调用、混合云中本地服务访问云端服务、以及多层架构中前端层访问后端层。虽然它承载的是内部流量,但当它作为外部入口的后端时,也参与南北向链路。

区域内部负载均衡器的后端可以是实例组、NEG 或混合连接。它的健康检查同样基于 HTTP/HTTPS/TCP,但作用范围限定在单个区域。与全局负载均衡器不同,它不具备跨区域任播能力,因此更适合对延迟敏感、且调用方与被调用方处于同一区域或同一 VPC 的场景。

流量分配策略:从权重到会话保持

Cloud Load Balancing 提供了多种流量分配手段,实际使用时通常组合使用:

  • 容量权重:通过设置后端服务的容量值,控制不同后端接收流量的比例。这是最基础的分配方式。
  • 会话亲和性:可选 NONE、CLIENT_IP、GENERATED_COOKIE、HEADER_FIELD 等。对于需要保持登录状态的服务,使用 GENERATED_COOKIE 可以把同一用户的请求固定到同一后端。
  • URL 映射:基于主机名、路径或请求头进行路由,实现灰度发布、A/B 测试和多版本共存。
  • 故障转移:当某个后端健康检查失败时,负载均衡器自动将其移出流量池,把请求转发到健康后端。

下面这张图展示了一个典型的南北向流量治理链路:外部用户通过全局外部负载均衡器进入,经过 URL 映射分流到两个后端服务,其中一个后端服务再通过区域内部负载均衡器访问内部服务。

外部用户 公网客户端 全局外部负载均衡器 Global External ALB 任播全局 IP · HTTP/HTTPS URL 映射 · 健康检查 容量权重 · 会话亲和 HTTPS URL 映射分流 /api/v1/* → 后端 A 后端服务 A 容量: 100 RPS v1 实例组 后端服务 B 容量: 300 RPS v2 实例组 1:3 区域内部负载均衡器 Regional Internal ALB VPC 内部 IP 仅限内部访问 内部调用 内部微服务 订单 / 库存 / 支付 健康检查 HTTP GET /healthz · 每 10s 流量分配逻辑:后端 A 容量 100 RPS,后端 B 容量 300 RPS → 按 1:3 比例分配;健康检查失败的后端自动移出流量池。 南北向链路:外部用户 → 全局外部 ALB → 后端服务 → 区域内部 ALB → 内部微服务。

配置要点与参数示例

下面给出一个全局外部负载均衡器的后端服务配置片段,用于说明容量权重和健康检查的实际写法。示例参数为教学假设值,并非实测结果。

# 创建后端服务(全局)
gcloud compute backend-services create web-backend \
  --global \
  --protocol=HTTP \
  --health-checks=http-health-check \
  --load-balancing-scheme=EXTERNAL_MANAGED

# 添加后端 A,容量 100 RPS
gcloud compute backend-services add-backend web-backend \
  --global \
  --instance-group=ig-v1 \
  --instance-group-zone=asia-east1-a \
  --capacity-scaler=1.0 \
  --max-utilization=0.8

# 添加后端 B,容量 300 RPS
gcloud compute backend-services add-backend web-backend \
  --global \
  --instance-group=ig-v2 \
  --instance-group-zone=asia-east1-b \
  --capacity-scaler=1.0 \
  --max-utilization=0.8

其中 --capacity-scaler 控制后端组的整体容量缩放比例,--max-utilization 定义目标利用率。负载均衡器会结合实例数量和单实例容量计算总容量,再按比例分配流量。若希望实现灰度发布,可以把 v2 后端的容量暂时设为较低值(例如 10 RPS),观察错误率和延迟后再逐步提升。

实践提示:全局外部负载均衡器的后端服务必须使用全局健康检查;区域内部负载均衡器使用区域健康检查。两者不能混用,否则后端会被标记为不健康。

如何判断流量分配是否符合预期

配置完成后,可以通过以下方式观察流量分布:在 Cloud Monitoring 中查看 backend_service/request_count 指标,按后端分组对比请求数;或者在后端实例上查看访问日志,统计不同实例组接收到的请求比例。如果发现流量严重偏离容量比例,优先检查健康检查状态、会话亲和性设置以及 URL 映射是否命中了预期规则。对于灰度场景,还可以结合 GENERATED_COOKIE 亲和性,确保同一用户在版本切换过程中不会频繁跳变。

南北向流量治理不是一次性配置,而是需要根据业务负载、版本迭代和故障演练持续调整的过程。全局外部负载均衡器负责“把用户接进来并分对路”,区域内部负载均衡器负责“把内部调用管起来”,两者配合容量权重、URL 映射和健康检查,才能形成完整的入口层治理能力。