Google Cloud HTTP(S) Load Balancer 怎么配置，网站流量如何分配到不同实例

很多网站从一台服务器扩展到两台、十台甚至跨区域部署以后，最先遇到的问题并不是“服务器够不够快”，而是用户访问同一个域名以后，到底应该由哪一台服务器处理请求。如果把所有用户都直接指向某一台虚拟机，这台机器一旦出现故障，整个网站就可能中断；如果增加多台服务器，却没有统一的流量入口，又无法有效利用这些机器。

Google Cloud 的 External Application Load Balancer，就是解决这个问题的核心组件。它位于用户和后端服务器之间，对外提供统一的 IP 地址和 HTTP/HTTPS 服务入口，再根据 URL 路由、后端健康状态、容量以及负载均衡策略，把请求交给合适的后端实例。Google 当前的文档已经将这一体系明确归入 Application Load Balancer，而不是过去简单理解的“一个公网 IP 加几台 VM”。

一、先理解负载均衡器到底在做什么

一个典型的网站可以有多台 Compute Engine 虚拟机，例如服务器 A、服务器 B 和服务器 C，它们都运行相同的网站程序。

用户访问 example.com 时，并不是 DNS 把用户随机指向 A、B、C 中的一台。DNS 通常把域名解析到负载均衡器使用的公网地址，真正决定请求交给哪个后端的，是 Google Cloud Load Balancing。

在 External Application Load Balancer 中，前端通常包括公网 IP、80/443 端口以及 HTTP 或 HTTPS 代理。HTTPS 网站可以在负载均衡器这一层完成 TLS 终止，然后由负载均衡器通过 HTTP 或 HTTPS 与后端通信。Google 官方的配置流程也是先建立健康检查、Backend Service，再配置 URL Map、Target HTTP/HTTPS Proxy 和 Forwarding Rule。

这里有一个很容易产生误解的地方：前端使用 443，并不意味着后端必须使用 443；同样，前端使用 80，也不意味着后端必须使用 8080。

后端到底监听哪个端口，由后端服务、实例组的 named port、NEG endpoint 等配置共同决定。前端的 443 和后端的 80 完全可以同时存在。Google 官方示例就可以让 HTTPS Load Balancer 接收用户的 443 请求，然后把请求发送给监听 HTTP 80 的后端实例。

所以，“前端和后端不能使用相同端口，否则无法路由”是错误的。端口是否相同并不是负载均衡是否工作的判断标准。

二、Backend Service 才是流量分配的核心

真正决定流量如何进入后端体系的，是 Backend Service。

一个 Backend Service 可以关联一个或多个后端，例如 Managed Instance Group、Network Endpoint Group 等。Google Cloud 会根据 Backend Service 的配置决定应该把请求发送到哪个后端，同时利用健康检查判断哪些后端可以接收流量。

如果网站只有一组 Compute Engine 实例，可以创建一个 Managed Instance Group，然后把这个实例组加入 Backend Service。

例如你有三台网站服务器，它们都运行 PHP、Nginx 或 Apache，并且应用部署完全一致，那么可以把它们放入同一个 Managed Instance Group。负载均衡器看到的并不是三个完全独立的“公网服务器”，而是一组能够处理同一种业务的后端资源。

更大型的网站则可能拥有多个区域。例如北美有一组实例，欧洲有一组实例，亚洲还有一组实例。这些后端可以加入相应的 Backend Service，由全球 External Application Load Balancer 根据用户位置、后端健康状态和容量等因素进行选择。

Google 的全球 External Application Load Balancer 可以在多个区域之间进行流量分配。官方示例中，如果北美、欧洲和亚洲都有健康并且具有足够容量的后端，请求通常会被发送到距离用户更合适的区域；如果最近区域没有健康后端或者容量不足，系统可以把请求转移到其他可用区域。

三、健康检查决定哪台服务器“有资格”接流量

负载均衡最重要的功能之一，就是不要把请求发送给已经坏掉的服务器。

因此必须配置 Health Check。

例如可以让 Google Cloud 定期请求后端服务器的 /healthz。如果服务器能够正常返回符合要求的 HTTP 响应，就被认为是健康的；如果持续失败，负载均衡器就会停止向它发送新的请求。

这里不能简单写成“默认每5秒检查一次、失败两次就标记为不健康”。Google Cloud 的健康检查存在不同类型和配置选项，具体参数应该按照当前控制台或 API 配置确定，而不能把某一版本、某一种配置的数值当成所有负载均衡器的固定默认值。

健康检查真正重要的是检查内容是否能够代表应用可用性。

例如 /healthz 如果只是返回一个静态的 HTTP 200，即使数据库已经彻底无法连接，它仍然可能被判断为健康。因此生产环境经常会把健康检查设计成能够反映关键依赖状态，但又不能让每一次健康检查都执行过重的数据库查询。

同时，Google Cloud 的健康检查流量必须能够到达后端，这就涉及 VPC 防火墙规则。如果防火墙阻止健康检查，即使网站程序本身完全正常，Backend Service 也可能把实例判断为不健康。

四、网站流量并不是简单的“平均轮询”

这是原稿中最需要修正的地方。

很多人以为负载均衡就是：

服务器 A → 一个请求
服务器 B → 下一个请求
服务器 C → 再下一个请求

然后循环往复。

实际的 Google Cloud Application Load Balancer 比这个复杂得多。

当前 Google Cloud 文档把 Backend Service 的流量分配分成多个层次。首先，Backend Service 根据 backend 的 balancing mode 决定应该向哪些后端资源分配多少流量；确定后端之后，再根据 locality policy 在具体区域、实例或 endpoint 之间进行选择。

在支持的 locality policy 中，ROUND_ROBIN 是默认策略之一，它按照轮询方式选择健康后端；LEAST_REQUEST 会从随机选择的健康主机中比较正在处理的请求数量；RING_HASH 和 MAGLEV 则可以用于一致性哈希等场景；此外还有 RANDOM 等策略。

因此，“Google Cloud 默认使用最少连接”并不准确。

更重要的是，即使使用 Round Robin，也不能理解为所有服务器最终一定收到完全相同数量的请求。后端的容量、区域、健康状态、负载均衡模式以及 locality policy 都会影响最终结果。

例如服务器 A 是高规格 VM，服务器 B 是低规格 VM，就不应该简单要求两台机器各承担50%的流量。Backend Service 可以通过 balancing mode 等机制反映后端容量差异。

五、跨区域部署时，Google Cloud 并不是简单按地理距离分配

假设你的网站在加拿大、美国、德国各部署了一组服务器。

用户从加拿大访问网站，负载均衡器通常会优先考虑距离用户较近并且健康、有容量的后端；但这并不是简单的“加拿大用户永远去加拿大服务器”。

如果加拿大区域的后端全部异常，或者已经达到配置的容量，流量可以被转移到其他可用区域。

这也是全球负载均衡真正有价值的地方：它解决的不只是“把请求平均分给三台服务器”，而是把后端健康状态、区域位置和容量结合起来进行流量调度。

因此，如果网站只有一两个 Compute Engine 实例，而且用户主要来自加拿大，那么一开始就部署复杂的跨洲架构未必有意义。对于普通网站，更重要的是先建立稳定的单区域高可用架构，再根据访问量和用户分布考虑跨区域。

六、URL 路径路由其实是 Application Load Balancer 的重要功能

原稿称 HTTP(S) Load Balancer 不支持根据 URL 路径进行分发，这一点已经明显过时。

Google Cloud 的 URL Map 本身就是用来决定 HTTP/HTTPS 请求应该发送到哪个 Backend Service 的。

例如：

example.com/video 可以发送到视频服务；

example.com/api 可以发送到 API 服务；

example.com/images 可以发送到 Cloud Storage backend bucket；

其他请求则进入默认 Backend Service。

Google 官方文档明确说明，URL Map 可以根据 host 和 path 等规则，把请求发送到不同的 backend service 或 backend bucket。

所以，一个大型网站完全可以只使用一个公网入口，却在后端运行多个不同的业务系统。

这也是 Application Load Balancer 与简单的四层 Network Load Balancer 在应用场景上的重要区别之一。

七、Session Affinity 并不是所有网站都应该打开

会话保持，也就是 Session Affinity，是另一个经常被误解的功能。

假设用户第一次访问被送到服务器 A，下一次请求又被送到服务器 B。如果网站把登录状态、购物车或者临时会话全部存在 A 的本地内存里，那么用户就可能突然“掉线”。

但解决方法并不一定是打开 Session Affinity。

更成熟的架构通常会把会话状态放在共享存储中，例如数据库、Redis 或其他集中式服务。这样用户下一次请求无论进入哪台应用服务器，都能够取得相同的数据。

Session Affinity 更适合那些确实需要短时间内尽量让同一个用户继续访问同一后端的场景。Google Cloud 支持多种 affinity 方式，包括 HTTP Cookie、HTTP Header、Client IP 等，但它属于 best-effort 机制，并不是“绝对保证用户永远访问同一台服务器”。同时，相关 affinity 能力还受到 locality policy 的限制。

因此，“金融交易系统必须使用 IP Hash”也不是通用规则。金融系统更应该依靠数据库事务、幂等设计、分布式状态管理和可靠的身份认证保证交易一致性，而不是把交易安全寄托在用户 IP 与某台服务器绑定上。

八、SSL 卸载到底解决什么问题

如果网站使用 HTTPS，可以让 Google Cloud Load Balancer 在前端完成 TLS 终止。

用户与负载均衡器之间建立 HTTPS 连接，负载均衡器验证并处理证书，然后再按照 Backend Service 的配置把请求发送给后端。

这可以减少应用服务器直接面对大量 TLS 连接管理的压力，也让证书管理集中在负载均衡层。

如果业务要求负载均衡器到后端之间也使用 HTTPS，则需要另外配置后端协议和相关证书、信任关系。不能简单理解成“只要前端有 HTTPS，后端证书链就必须完整配置”——具体要求取决于所采用的后端连接方式和验证配置。

九、Traffic Mirroring 和 Rate Limiting 不应该混在一起

原稿把 Traffic Mirroring 描述成“复制部分流量到监控系统或日志服务”，这个表述过于简单。

Traffic Mirroring 的核心是复制符合条件的网络流量，用于安全分析、故障排查等场景，它不是普通的网站访问日志系统。

而网站的请求限流，也不是简单在 Load Balancer 上填一个 rate-limit 参数就结束了。

如果网站需要针对 IP、请求特征、规则或者应用层请求进行防护，Cloud Armor 等安全与策略组件可以参与处理。负载均衡负责把请求正确送到后端，安全策略、WAF、DDoS 防护和限流属于更完整的流量管理体系。

这几个功能可以组合使用，但不能把它们理解成同一个功能。

十、真正需要配置的核心组件有哪些

一个典型的 Google Cloud HTTPS 网站，实际配置时通常需要考虑这些资源：

首先是公网 IP 和 Forwarding Rule，它们提供用户访问网站的入口。

然后是 Target HTTPS Proxy，它负责处理 HTTPS 请求。

接下来是 URL Map，它决定不同域名、路径的请求应该进入哪个 Backend Service。

Backend Service 再负责连接具体的后端资源，并定义健康检查、协议、超时、会话保持、负载均衡等策略。

后端可以是 Managed Instance Group，也可以根据架构选择不同类型的 Network Endpoint Group 等资源。Google 当前的 External Application Load Balancer 支持多种后端类型，并不是只有传统 Compute Engine 实例组。

最后是 Health Check，它持续判断后端是否具备接收流量的能力。

这些组件共同组成完整的应用层负载均衡架构。

十一、最常见的错误不是“算法选错”，而是后端根本不健康

实际部署中，最常见的问题往往非常基础。

例如实例上的 Nginx 只监听 127.0.0.1，而不是能够接受来自负载均衡器的连接；防火墙阻止健康检查；健康检查路径返回404；实例组的 named port 配置错误；应用虽然可以从浏览器访问，但 /healthz 返回500；或者后端服务器运行正常，却没有正确加入 Backend Service。

这时候你在控制台看到的可能是“所有后端 unhealthy”。

这种情况下继续调整 Round Robin、Least Request 或 Session Affinity 都没有意义。

正确的排查顺序应该是先确认实例本身能正常提供服务，再确认健康检查能够从 Google Cloud 的健康检查系统访问该服务，然后检查 Backend Service 的健康状态，最后再分析流量分配是否符合预期。

十二、监控时不要只看 CPU

判断负载均衡是否正常，不能只看 VM 的 CPU 使用率。

应该同时观察后端健康状态、请求数量、延迟、错误率、连接情况以及不同 Backend Service 的流量变化。

如果服务器 A CPU 90%，服务器 B CPU 20%，并不一定意味着负载均衡器坏了。两台机器可能配置了不同的容量，也可能处于不同区域，或者 Backend Service 的 balancing mode 本身就在根据容量进行调整。

对于全球部署，还应该观察不同区域的请求量和延迟。当某个区域出现故障时，最重要的不是“每台服务器是不是50%流量”，而是用户请求能不能继续到达健康后端。

十三、普通网站应该怎么部署

如果只是一个普通企业网站、电商网站或者内容网站，没有必要一开始就把 Google Cloud 所有高级功能全部打开。

比较合理的起点，是准备一个 Managed Instance Group，至少运行两台应用服务器，然后建立 HTTP Health Check 和 Backend Service，再通过 URL Map、HTTPS Proxy 和 Forwarding Rule 建立公网 HTTPS 入口。

网站状态不要依赖某一台服务器的本地内存。用户登录、购物车等需要持久化的数据应该放到共享的数据层。这样即使一次请求从服务器 A 转移到服务器 B，用户也不会因此丢失状态。

随着访问量增长，再考虑 Managed Instance Group 自动扩容、跨区域部署、Cloud CDN、Cloud Armor、更加复杂的 URL 路由和流量管理。

Google Cloud 的全球 External Application Load Balancer 已经可以处理多区域后端，并根据后端健康状况和容量进行流量调度，因此它并不是简单意义上的“把访问量平均分成几份”。

对于网站架构来说，负载均衡器真正解决的是“统一入口、健康后端、流量调度和故障转移”这几个问题。服务器数量增加以后，最重要的不是追求某一种所谓最先进的负载均衡算法，而是让应用本身具备无状态化、可扩展和可故障转移的能力。负载均衡器能够把请求从一台服务器转移到另一台服务器，但它无法替一个设计糟糕的应用解决数据库一致性、会话状态、文件存储和应用本身的故障。因此，Google Cloud Load Balancer 应该被看成整个网站架构的一层，而不是孤立的一个网络设备。