全球外部负载均衡器未按地理就近路由请求的原因排查

架构配置梳理 #

• 外部全局负载均衡器（External Global Load Balancer）
• 单后端服务，包含3个Serverless NEG（对应Cloud Run服务）：
  • Backend 1：us-central1 区域
  • Backend 2：us-east1 区域
  • Backend 3：me-central1 区域
• 路由规则：默认简单路径/主机规则
• 无会话亲和性
• 负载均衡策略：最少请求（Least Request）
• 未启用CDN

路由异常的可能原因 #

1. 最少请求策略优先级高于就近路由
   Global LB的「最少请求」模式核心逻辑是根据后端实例当前正在处理的请求数分配流量，而非优先选择地理距离最近的后端。如果me-central1区域的Cloud Run实例当时的在处理请求数比us-east1多，哪怕你在约旦离me-central1更近，LB也会把请求转发到请求负载更低的us-east1实例。

2. me-central1区域的Cloud Run实例处于未就绪状态
   如果me-central1的Cloud Run服务当时没有运行中的实例（比如冷启动阶段），或者实例正在初始化尚未完成就绪检查，LB会自动跳过这个后端，转而选择已经处于就绪状态的us-east1实例。这种情况下控制台可能不会显示明显错误，因为冷启动是Cloud Run的正常行为。

3. 后端权重配置（隐性因素）
   虽然你提到用了默认配置，但如果me-central1后端的流量分配权重被意外设置为低于其他后端（比如权重1 vs 其他后端权重更高），结合最少请求策略，也会导致流量更倾向于权重高且请求数少的后端。可以检查下后端服务中各NEG的权重设置是否一致。

4. 健康检查的隐性阈值问题
   哪怕控制台没有显示健康异常，也可能存在健康检查的阈值配置导致的临时排除。比如健康检查要求连续N次成功才会将后端纳入可用池，如果me-central1的实例刚通过健康检查不久，还没达到阈值，可能暂时不会被分配流量。

内容的提问来源于stack exchange，提问作者Omar Dulaimi