GCP身份核验 谷歌云负载均衡实测

话说那天我盯着GCP控制台里那个「Global HTTP(S) Load Balancer」按钮，手悬在半空，像极了第一次相亲前反复修改微信签名的自己——既期待又怕被拒，还担心它突然弹出一句：「抱歉，您的项目未启用Compute Engine API」。

别笑，这真不是段子。我踩的第一个坑，就栽在API没开全上。GCP不像AWS点点鼠标就完事，它讲究「权限最小化+服务显式启用」，你得手动开三个API：Compute Engine、Resource Manager、and yes——Identity and Access Management (IAM) API。漏一个？控制台连「新建后端服务」按钮都是灰色的，安静得像凌晨三点的办公室茶水间。

好了，API齐了，开始搭链路。GCP的LB不是「配个IP就完事」的单体结构，它是一套乐高：Backend Service → Instance Group / NEG → Health Check → URL Map → Target Proxy → Forwarding Rule。名字多得像奶茶店配料表——珍珠、椰果、寒天、脆波波……但每一块都得严丝合缝。我第一次配，把健康检查路径设成/healthz，结果后端Node.js服务返回200，LB却持续标红。查日志才发现：GCP健康检查默认不带Host头，而我的Express中间件写了if (req.headers.host !== 'api.example.com') return res.status(403).end()……对，它连403都不给，直接超时。改法？加一条req.headers.host = 'api.example.com';在健康检查路由里，或者——更优雅地，在健康检查配置里勾选「发送Host头」（对，这个选项藏在高级设置里，小字，灰底，需要你主动点开「Show advanced options」才露脸）。

接着是证书。GCP支持Google-managed SSL证书，自动申请+自动续期，听着像AI管家。但实测发现：它只认DNS验证，且要求你域名解析必须指向LB的任一IP（哪怕你还没正式切流量）。我卡在这儿整整半天，因为本地dig example.com看到的是旧CDN IP，而GCP后台一直显示「Pending validation」。解决？临时加一条CNAME记录：example.com → gcp-lb-123456789.us-central1.https.lb.goog（注意！不是IP，是那个长得像乱码的域名），等15分钟，状态秒变绿色。续期？真自动，去年12月签发的证书，今年11月底悄悄更新了，我在GCP日志里翻到一条Certificate renewed successfully，比我妈提醒我交水电费还准时。

最刺激的是压测环节。我用hey -z 5m -c 200 https://example.com/api/v1/status模拟流量，同时开着Cloud Monitoring看延迟曲线。预期是「全球用户就近接入，P95延迟≤150ms」，结果东南亚用户P95飙到892ms。抓包一看：请求全被路由到了美国俄亥俄节点！为啥？因为我的后端实例组只部署在us-central1，而GCP LB的「就近路由」逻辑是：先按Anycast找最近的边缘POP，再查该POP能连通的后端——没后端？它就往上兜，直奔最近的有后端的区域。解决方案？在asia-east1和europe-west1也建两个Managed Instance Group（MIG），哪怕只放一台小机器跑curl -s http://metadata.google.internal/computeMetadata/v1/instance/zone -H 'Metadata-Flavor: Google'返回自身区域名，LB立马学会「分区域打烊」：东京用户走东京后端，法兰克福用户走法兰克福后端，延迟瞬间回落至92ms。

还有个隐藏彩蛋：缓存控制。默认情况下，GCP LB自带CDN，会缓存GET响应（除非响应头含Cache-Control: private或Set-Cookie）。我有个接口返回实时股票价格，本想加Cache-Control: no-cache, must-revalidate，结果发现LB根本不认must-revalidate，只认private或no-store。最终方案是在URL Map里加一条cacheKeyPolicy，把/api/quote路径的缓存键强制包含query string和host，再配合maxTtl: 0，彻底关掉缓存。顺手还发现：如果你用curl -H 'Cache-Control: max-age=0' https://...，LB会把它当普通请求头忽略，完全不影响缓存行为——它只认后端返回的响应头，或者你在URL Map里硬编码的策略。

GCP身份核验 最后说故障转移。我故意停掉us-central1的所有后端实例，等3分钟（健康检查间隔×2），监控面板果然亮起红灯。此时，亚洲和欧洲的请求毫秒级切到备用区域，P99延迟仅增加17ms。但有个细节很多人忽略：GCP LB的「failover」不是「主备切换」，而是「全局重路由」。它不会等主区全挂才动，只要某个区域健康检查失败率＞阈值（默认10%），就会动态降低该区域权重。我做过实验：把us-central1健康检查失败率调到12%，亚太用户立刻有30%流量被悄悄分到asia-east1，毫无感知——这才是真正的「静默弹性」。

写完这篇，我删掉了本地所有AWS ALB配置脚本。不是因为GCP更好，而是它逼着你理解网络每一层：从Anycast BGP宣告，到HTTP/2优先级协商，再到TLS 1.3 0-RTT握手是否开启。它不给你「一键高可用」的幻觉，只给你一张清晰的拓扑图和一份诚实的延迟报告。当你看着latency分布图从双峰变成单峰，当东南亚用户说「这次加载快得像点了外卖闪送」，你会觉得——那几个小时折腾API权限、健康检查头、DNS验证的深夜，值了。

附赠一句血泪口诀：
「证书要CNAME，健康检查带Host，后端得铺满三大洲，缓存策略写URL Map，故障转移看权重不看开关。」
背下来，下次面试官问「GCP LB和ALB区别」，你可以笑着递上这张纸条。