谷歌云负载均衡：十年云上流量的摆渡人，你真的用对了吗？

一、流量调度这门老手艺，谷歌云是怎么翻新的？

说起负载均衡，搞过传统IT的老一辈工程师怕是要会心一笑——那会儿机房里摆着F5的硬件设备，几万块一台，风扇呼呼转，配置起来得拿串口线连上去敲命令行。流量来了，设备扛不住就扩容，扩不了就堆设备，堆不下就换更大的型号。这套玩法跑了十几年，直到云计算把这老规矩彻底掀了桌。

谷歌云（Google Cloud）的Cloud Load Balancing，就是这场颠覆里的一个典型样本。它不是什么硬件设备，也不是跑在你虚拟机里的一台软件负载均衡器——它是一个全托管的、软件定义的、运行在谷歌全球前端基础设施上的分布式系统。说白了，你根本看不见它在哪儿，它却把你的用户请求从全球各地精准地送到了你的后端服务器上。

这套系统的底子不一般。它跑在谷歌用来支撑YouTube和Google Search的那张全球骨干网上。你不是在租一台负载均衡器，你是在租用谷歌全球网络的流量调度能力。这话听着有点大，但事实如此——当一个东京的用户访问你部署在弗吉尼亚的服务，请求经过的不是公共互联网上那些七拐八绕的路径，而是谷歌自己铺的海底光缆和边缘节点。低延迟、高可用，这些词搁在这儿不是营销话术，是物理事实。

那么问题来了：这套系统到底怎么用？它有哪些类型？什么场景选什么方案？咱们往下拆。

二、全局还是区域？这问题比你想的复杂

谷歌云负载均衡的第一个分水岭，是全局（Global）和区域（Regional）的区分。别被字面意思骗了——这两个词说的不是负载均衡器本身部署在哪里，而是它能往哪里路由流量。

区域负载均衡（Regional Load Balancer）的势力范围就一个区域。比如说你的后端全在us-east1（弗吉尼亚），那区域负载均衡就在这个区域里的三个可用区之间分发流量。某个可用区出了问题，它自动把流量切到别的可用区——这已经够用了，只要你的用户也主要在美国东海岸。可要是一个伦敦的用户访问你的服务呢？他的请求得跨过大西洋飞到弗吉尼亚，再飞回去。这趟往返的物理延迟，谁也绕不过去。

全局负载均衡（Global Load Balancer）就是为这事儿准备的。它对外提供一个任播IP（Anycast IP）地址——全世界不管你在哪儿，访问的都是同一个IP。谷歌的骨干网会根据你的物理位置，把请求路由到最近的那个健康的后端。东京的用户去东京附近的机房，伦敦的用户去伦敦附近的机房，柏林的用户去法兰克福。后端部署在几个大洲，流量自动分流，用户感知不到跨洋延迟——这套架构，才是全球化应用该有的样子。

选全局还是区域，答案不复杂：用户分布在全球，选全局；用户集中在一个区域，选区域。后者更便宜、配置更简单。别为了“上云就要全球化”的虚荣心多花冤枉钱。

三、七层还是四层？这得看你的流量讲不讲道理

第二个分水岭，是七层应用负载均衡（Application Load Balancer）和四层网络负载均衡（Network Load Balancer）的取舍。这俩的区别，说白了就是负载均衡器看不看你的请求内容。

七层负载均衡工作在OSI模型的应用层，处理的是HTTP和HTTPS流量。它能解析URL路径、请求头、Host域名，然后根据这些信息做路由决策。举个例子：domain.com/api的请求去后端A，domain.com/web的去后端B；app1.domain.com去服务A，app2.domain.com去服务B。微服务架构里，这种基于内容的路由几乎是刚需。它还能做SSL终止——在负载均衡器上把HTTPS解密成HTTP，后端服务器就不用背着加密解密的计算负担了。谷歌云还提供托管的SSL证书，自动续期，省去手动折腾证书的麻烦。

四层负载均衡就简单粗暴了。它工作在传输层，处理TCP、UDP、ICMP这些协议。它不看请求内容，只根据IP和端口转发流量。好处是性能极高、延迟极低，适合那些不需要HTTP解析的场景——比如游戏服务器的UDP流量、数据库连接、VPN隧道。四层里面还有一个“代理模式”（TCP Proxy / SSL Proxy），可以做SSL卸载；还有一个“透传模式”（Pass-through），流量原封不动地往后端送，连客户端的真实IP都保留着。

选哪个？跑HTTP/HTTPS的Web应用、API网关、微服务，无脑上七层；跑数据库、游戏、非HTTP协议，选四层。这事儿没什么好纠结的。

四、后端那些事儿：从目标池到NEG，老办法和新思路

负载均衡器把流量接进来，得知道往哪儿送。谷歌云后端配置这块，经历了好几代演进，搞不清楚的人确实容易迷糊。

先说目标池（Target Pools）——这是老古董了。它就是把一堆虚拟机实例攒在一起，做最基本的轮询转发，健康检查也简陋。现在基本被淘汰了，新项目别碰。

接着是后端服务（Backend Services）——这是目前的主流方案。它支持的东西多得多：智能流量分配、会话保持（Session Affinity）、与Cloud CDN集成、细粒度的超时和重试策略控制。后端可以是托管实例组（MIG）、网络端点组（NEG），甚至是Cloud Storage存储桶。后端服务还分全局和区域两种——全局的可以跨区域路由，区域的只在单个区域内生效。

这里要重点说说网络端点组（Network Endpoint Groups，NEG）。这玩意儿是谷歌云后端配置里最具突破性的设计。传统的实例组是把一整组虚拟机当成一个后端单元，而NEG允许你把流量路由到具体的某个端点——可以是一个Cloud Run服务、一个App Engine实例、一个Cloud Function，甚至是运行在你自家数据中心的服务器（通过Internet NEG）。这意味着什么？意味着你的负载均衡器不再挑肥拣瘦——Serverless也好、容器也好、传统VM也好、甚至外部IDC里的机器也好，统统可以挂在同一个负载均衡器下面。这对于混合云架构和逐步上云迁移的场景，简直是量身定做的方案。

说个实战例子：你把一个Cloud Run服务部署在us-central1，另一个部署在asia-south1。给每个服务创建一个Serverless NEG，再把这两个NEG挂到同一个全局后端服务上。然后配置一个URL Map，让不同路径的请求去不同的后端。最后创建一个全局转发规则，把外部流量引进来。一套全球分布式、按请求路径路由的Serverless架构，就这么搭起来了。这在以前，得折腾多少东西？现在几行gcloud命令就搞定了。

五、高级玩法：流量管理还能玩出什么花？

基础的路由和转发讲完了，咱们聊聊进阶的。

基于主机名和路径的路由，这是七层负载均衡的基本功。但谷歌云还能做主机重写（Host Rewrite）和路径重写（Path Rewrite）——请求进来是/app1，到后端变成了/app1new；请求进来是app1.domain.com，到后端变成了app1.backend.internal。这种灵活度在微服务网关场景里非常实用。

与Cloud CDN的集成也是一大亮点。你把全球HTTP(S)负载均衡器架在服务前面，再开启Cloud CDN。静态资源（图片、CSS、JS）会被缓存到谷歌全球的边缘节点。用户每次请求，先看边缘节点有没有缓存——有就直接返回，没有才回源站去取。全球用户的加载速度一下子就上去了，源站的带宽压力也下来了。

与Cloud Armor集成提供DDoS防护。你不需要额外部署WAF设备，在负载均衡器层面就能把恶意流量挡在外面。对于面向公网的服务，这个组合几乎是标配。

健康检查是负载均衡的命脉。谷歌云的负载均衡器会持续探测后端实例的健康状态。检测到某个后端挂了，自动把流量切到别的健康实例上。全局负载均衡还能跨区域做故障转移——整个区域的服务都不可用了，流量自动转到其他区域。默认的超时时间是30秒，官方不建议把后端服务超时设到24小时以上——因为谷歌的前端基础设施（GFE）会定期做软件更新和例行维护。

这里得提一句：谷歌云负载均衡不需要预热（No Warmup）。流量从零暴涨到千万级，系统在几秒内就能自动扩容。不用像传统架构那样提前预估峰值、手动扩容、峰值过了再缩容——全自动的，按实际用量付费。秒级计费，没有最低消费。

关于谷歌云负载均衡的部署与优化，上海汪远信息科技有限公司是谷歌云头部一级代理商，团队规模500人，深耕多云服务领域十年以上，覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、亚马逊云、谷歌云八大主流公有云平台，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户。单谷歌云平台年销量达5000万美金，在香港设有专门公司服务于谷歌云、微软云、亚马逊云等国际云业务。找汪远合作谷歌云，可享8.5折或返点15%的代理商务条件。从架构设计到日常运维，团队提供全流程技术支持与成本优化服务。

六、别纠结谁比谁强，想清楚自己要什么

写到这里，咱们把谷歌云负载均衡的家底翻了个遍。回过头来看那个问题：谷歌云负载均衡到底是个什么东西？

它不是一台设备，不是一个软件，甚至不是一个你可以“看到”的服务。它是一张网——一张铺在谷歌全球骨干网上的、软件定义的、全自动的流量调度网络。

选全局还是区域？看用户分布。选七层还是四层？看协议和路由需求。选后端服务还是目标池？别选目标池——那是上个时代的东西了。用不用NEG？只要你的后端不全是传统VM，就值得用——Serverless、容器、混合云场景里，NEG几乎是必选项。

这套系统的设计哲学很清晰：把复杂留给自己，把简单留给用户。你不用管底层怎么实现的，不用管流量暴增时怎么扩容，不用管某个区域的光缆断了怎么办——这些都交给谷歌的全球基础设施去处理。你要做的，就是选对类型、配好参数、然后把精力放在业务本身。

云计算的魅力就在这儿：过去需要专门团队伺候的流量调度系统，现在变成了几行配置、几个API调用就能搞定的事儿。技术 democratization（民主化）——让复杂的技术变得人人可用——这才是云计算最大的价值。谷歌云负载均衡，不过是这宏大叙事里的一个章节罢了。

常见问题

问：谷歌云负载均衡和AWS的负载均衡比起来，最大的区别在哪儿？
答：最大的区别是全局性。AWS的ALB和NLB本质上是区域级别的服务，要实现全球流量分发需要配合Global Accelerator。而谷歌云从设计之初就把全局负载均衡作为一等公民——一个Anycast IP就能覆盖全球。这不是功能上的差异，是架构哲学上的差异。

问：我的业务目前只在一个区域部署，有必要用全局负载均衡吗？
答：没必要。区域负载均衡更便宜、配置更简单。除非你的用户遍布全球且对延迟敏感，否则别为了“全球化”的名头多花钱。等业务真到了需要多区域部署的那天，再迁移也不迟。

问：后端服务（Backend Service）和目标池（Target Pool）到底有什么区别？
答：目标池是老技术，功能单一，只做最基本的轮询转发。后端服务是现在的标准方案，支持会话保持、CDN集成、细粒度超时控制、多种后端类型（实例组、NEG、Cloud Run等）。新项目直接上后端服务，别碰目标池。

问：NEG是什么？我非用不可吗？
答：NEG是网络端点组，它让你能把流量路由到具体的某个端点，而不只是一整组虚拟机。如果你的后端是Cloud Run、App Engine、Cloud Functions这些Serverless服务，必须用NEG。如果你的后端是传统VM，用托管实例组就够了，NEG不是必选项。但如果你要做混合云（后端有一部分在IDC），Internet NEG就是你的不二之选。

问：谷歌云负载均衡的SLA是多少？
答：月度可用性SLA为99.99%。配合多区域部署和自动故障转移，实际可用性还能更高。当然，前提是你的后端服务本身也得扛得住。

问：费用怎么算的？会不会很贵？
答：按量付费，没有最低消费，按秒计费。全球HTTP(S)负载均衡大约每小时0.025美元，数据处理费每GB大约0.008到0.012美元。具体费用取决于你选择的负载均衡类型、处理的数据量和流量目的地。对于大多数中小型应用来说，这笔开销远低于自建负载均衡集群的运维成本。