Google Cloud HTTPS负载均衡会话亲和性异常问题问询

这种会话亲和性莫名失效的问题确实挺棘手的，尤其是你已经确认GCLB Cookie没变化的情况下——结合我对GCP负载均衡的经验，有几个可能的原因值得排查：

1. 边缘节点的亲和性缓存过期或不一致 #

GCLB的会话亲和性是靠每个边缘节点本地维护的缓存条目来匹配Cookie和后端实例的，而非全局统一缓存。哪怕你设置了affinityCookieTtlSec（Cookie的过期时间），边缘节点的亲和性缓存条目可能有独立的超时逻辑，或者不同节点的缓存同步存在微小延迟。

举个例子：如果你的第一个POST请求打到了节点A，节点A记录了Cookie和实例X的绑定；但后续某个重定向请求打到了节点B，而节点B的缓存里还没有这个Cookie的绑定记录，它就会重新选择实例，哪怕Cookie本身还没过期。

建议检查你设置的affinityCookieTtlSec值，确保它足够覆盖你的整个业务流程（POST+6次重定向）的总时长，同时可以考虑把这个值调得比实际需要稍长一些，给缓存同步留余量。

2. 健康检查的瞬时波动（哪怕你没察觉到） #

你说所有健康检查都通过，但GCLB的健康检查是分布式执行的——不同边缘节点会独立检测后端实例的健康状态。如果某个边缘节点在某一瞬间因为网络抖动、实例短暂卡顿等原因，检测到目标实例健康检查失败，它会暂时把这个实例从可用池中移除。这时候哪怕请求带着正确的Cookie，这个节点也会把请求转发到其他健康实例。

你可以去Cloud Logging里筛选loadbalancing.googleapis.com/health_checks相关的日志，看看问题发生的时间段里有没有瞬时的健康检查失败记录——哪怕是几秒钟的波动都可能触发路由切换。

3. Apache反向代理的Cookie属性被意外修改 #

虽然你说在Apache里打印的Cookie值没变化，但要确认Cookie的属性（比如Path、Domain）有没有被Apache的配置修改。比如，如果GCLB设置的CookiePath是/api，但后续重定向的URL路径是/app，而Apache不小心把Cookie的Path改成了/之外的其他值，GCLB可能无法识别这个Cookie的亲和性绑定，从而重新路由。

检查一下你的Apache配置里的ProxyPass、ProxyPassReverse相关规则，有没有用到CookieDomain或CookiePath指令修改了GCLB Cookie的属性。

4. GCLB的负载兜底策略触发 #

当会话亲和性指向的实例出现瞬时负载过高（比如CPU突增、连接数达到阈值），GCLB会触发故障转移，把请求转发到其他健康实例，哪怕Cookie存在。这种情况属于负载均衡的兜底机制，优先保证请求能被处理，而不是严格遵循亲和性。

你可以去查看后端实例的监控指标（CPU使用率、活跃连接数、响应时间），看看问题发生的时间段里有没有负载突增的情况。

5. 实例的内部标识发生变化（无扩缩容也可能发生） #

哪怕没有自动扩缩容，实例如果因为系统补丁、重启或者底层维护导致内部标识（比如instance_id对应的后端服务注册条目）变化，GCLB的亲和性缓存是基于这个标识绑定的——一旦标识变了，哪怕Cookie没变，GCLB也找不到原来的实例，只能重新选择。

你可以去查看实例的运行日志，看看问题发生时有没有实例重启、重新注册的记录，对比一下前后的实例标识是否一致。

具体排查步骤建议 #

• 开启GCLB的请求日志：在Cloud Console里找到你的负载均衡，开启日志记录，然后筛选出亲和性失效的请求，查看请求的backend_service、instance、cookie字段，确认是不是同一边缘节点处理的请求，以及目标实例当时的状态。
• 在后端实例上加日志：记录每个请求的GCLB Cookie值和当前实例ID，对比亲和性失效的请求，确认是不是Cookie正确但实例被强制切换了。
• 临时调整affinityCookieTtlSec：把这个值调到比你的业务流程时长更长（比如300秒），观察问题是否缓解，这能帮你验证是不是缓存过期导致的。

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