Google Cloud Load Balancing 是什么，多台服务器如何共同处理访问请求

一台服务器能撑住多少访问量，往往不是网站上线时最先考虑的问题。真正麻烦的是，当一个网站从每天几百个访问者突然变成几十万甚至几百万个请求时，单台服务器即使配置再高，也很容易遇到 CPU、内存、网络连接数或者应用本身的处理能力瓶颈。更棘手的是，服务器一旦宕机，所有请求都会一起失去落脚点。

Google Cloud Load Balancing 解决的就是这个问题。它不是简单地在几台服务器之间“轮流分配访问”，而是一套由 Google Cloud 托管的流量调度系统。用户看到的可以只是一个 IP 地址，但这个 IP 地址背后可能连接着不同区域、不同实例、不同类型的后端服务。Google Cloud 根据流量、后端健康状态、网络位置和容量等因素决定请求应该送往哪里。对于全球化应用来说，这意味着用户不必知道服务器到底在哪个数据中心，系统负责把请求送到合适的后端。

这也是负载均衡最容易被初学者误解的地方。Load Balancer 并不是“服务器 A 收到一半请求，服务器 B 收到另一半请求”这么简单。现代云平台面对的是动态变化的网络环境：有的服务器正在正常运行，有的服务器可能已经过载，有的区域网络可能出现问题，还有的后端虽然在线，却已经没有足够容量继续接收新请求。因此，负载均衡实际上更接近一个持续运行的交通调度系统。

假设一个网站部署了三台服务器，分别是 Server A、Server B 和 Server C。用户访问 example.com 时，DNS、网络路由和 Google Cloud 的前端基础设施最终把请求带到负载均衡系统。对于全球外部 Application Load Balancer，Google Cloud 可以使用单一的 Anycast IP 对外提供服务，再根据请求和后端情况把流量送往合适的后端。后端可以是 Compute Engine、GKE、Cloud Run、Cloud Storage，甚至某些位于 Google Cloud 外部的后端。

接下来发生的事情，才是负载均衡的核心。

负载均衡器首先需要知道“谁能接活”。Google Cloud 会通过 Health Check 对后端进行探测。健康检查可以使用 HTTP、HTTPS、HTTP/2、TCP、SSL 或 gRPC 等协议。默认情况下，健康检查的探测间隔是 5 秒，健康和不健康阈值默认都是连续 2 次探测成功或失败，但这些参数可以根据配置调整。因此，不能简单理解成“每 5 秒检查一次，连续失败 3 次才下线”，实际阈值取决于具体健康检查配置。

假设 Server B 突然停止响应，而 Server A 和 Server C 仍然正常。健康检查发现 B 连续失败后，它就不再被视为适合接收新连接或请求的后端。流量于是可以转向 A 和 C。

这里还有一个容易被忽略的细节：负载均衡器通常并不是等服务器彻底死机后才发现问题。健康检查可以针对一个具体的 HTTP URL 进行检测。例如网站可以提供一个 /health 或 /healthz 接口，只有应用本身已经能够正常响应时才返回成功状态。这样，系统检查的就不只是“这台机器有没有开机”，而是“这个应用现在是否具备继续处理请求的能力”。

Google Cloud 的负载均衡体系也已经不能简单概括成传统意义上的“三种负载均衡器”。目前 Google Cloud 将产品体系分为 Application Load Balancers 和 Network Load Balancers 两大类。Application Load Balancer 工作在 OSI 第七层，主要处理 HTTP 和 HTTPS；Network Load Balancer 则主要工作在第四层，可以处理 TCP、UDP 以及其他 IP 协议。Network Load Balancer 又进一步分为 Proxy Network Load Balancer 和 Passthrough Network Load Balancer。

对于普通网站、Web API 和大多数互联网应用，Application Load Balancer 是更容易理解的一种。

因为它能够理解 HTTP 层面的信息，所以不仅可以把请求送给某台服务器，还可以根据 URL、主机名等信息进行路由。例如，一个公司可能把 example.com/api 交给 API 后端，把 example.com/static 交给静态资源后端，把另一个子域名交给完全不同的服务。这种能力是传统只处理 TCP 数据包的第四层负载均衡器无法直接完成的。

HTTPS 也不意味着必须再单独购买一个所谓“SSL 层负载均衡器”。在现代 Google Cloud 架构中，Application Load Balancer 本身就可以处理 HTTPS，并在负载均衡层完成 TLS/SSL 终止，再把请求转发给后端。Google Cloud 的 Proxy Network Load Balancer 也能够承担 TLS/SSL offload，但它属于 Network Load Balancing 体系，而不是一个与 Application Load Balancer 并列的简单“三选一”产品。

那么，多台服务器究竟是怎么“共同工作”的？

关键不是让几台服务器共享同一个内存，也不是让它们共同执行同一个 PHP、Java 或 Python 程序。每台后端服务器实际上都是独立运行的。负载均衡器所做的是把不同的请求分发给不同后端。

例如用户甲的请求可能进入 Server A，用户乙的请求进入 Server C，用户丙的请求又进入 Server A。对于拥有大量用户的网站来说，成千上万甚至更多的请求会被持续分布到后端资源上。

但这里不能简单说 Google Cloud 永远采用“轮询”。现代 Google Cloud 的负载分配涉及 backend service、balancing mode 和 locality policy 等多个层次，具体如何选择后端取决于负载均衡器类型和配置。Google Cloud 文档还明确区分了 backend group 与具体实例或 endpoint 的选择过程。因此，把整个系统描述成传统的 Round Robin 或 Least Connections，会把现代云负载均衡简化得过头。

如果网站部署在多个地区，情况会更加有意思。

假设公司在美国西部、美国东部和欧洲分别部署了后端。来自北美西部的用户可能更适合访问西部区域的后端，而欧洲用户则可能被送往欧洲区域。这样做并不只是为了“平均分服务器”，而是为了降低网络延迟，并让整个系统具备跨区域容灾能力。

当某个区域发生严重故障时，全球负载均衡还可以把流量转移到其他可用区域。Google Cloud 的全球负载均衡可以通过 Anycast IP 对外提供统一入口，而后端则可以分布在多个区域。对于全球业务，用户访问的是同一个服务入口，后面的基础设施却可以随着网络状况和后端健康状态动态变化。

自动扩容则是另一个重要环节。

需要特别区分的是，Load Balancing 本身并不等于 Autoscaling。负载均衡器负责把流量分配给现有的后端，而 Managed Instance Group 等自动扩缩容机制负责根据负载增加或减少实例。两者配合起来，才能形成比较完整的弹性架构。

例如正常情况下只有 5 台服务器，突然因为大型活动导致请求量暴涨，自动扩容机制可以增加新的实例。新的实例完成启动并通过健康检查后，就可以进入可接收流量的后端集合。活动结束以后，系统再缩减实例数量。Google Cloud 的负载均衡和自动扩缩容机制因此可以共同应对流量变化，而不是让网站管理员在半夜手动登录服务器加机器。

还有一个经常被误解的功能叫 Session Affinity，也就是会话亲和性。

假设用户登录购物网站以后，连续访问购物车、订单和账户页面。某些应用可能希望同一个用户尽可能继续访问同一个后端。Google Cloud 支持多种 session affinity 方式，包括基于 Cookie、HTTP Header 或客户端 IP 等机制，具体能力取决于负载均衡器和配置。

不过，Session Affinity 并不是一种绝对保证。Google Cloud 明确把它定义为 best-effort，也就是说，在后端健康状态变化、实例增加或减少、网络路径变化等情况下，原来的亲和关系可能被打破。因此，网站不应该把 session affinity 当成保存用户登录状态的唯一手段。更稳妥的架构是把会话状态放进共享的数据库、缓存或者其他独立存储中，让任何健康后端都可以继续处理用户请求。

这也是从“几台服务器组成网站”走向真正分布式系统时非常重要的一步。

如果用户登录信息、购物车、临时数据全部只保存在 Server A 的本地内存里，那么用户下一次请求如果被送到 Server B，就可能发现“咦，刚才明明已经登录了，怎么又让我登录？”负载均衡器并没有出错，真正的问题是应用本身没有做到无状态化或者没有正确设计共享状态。

同样的道理也适用于文件上传。如果用户上传的文件只保存在某一台服务器的本地磁盘，而下一次请求被分配到另一台服务器，那么应用就可能找不到之前上传的文件。现代云架构通常会把数据库、对象存储、缓存和应用服务器适当拆开，让后端实例能够相对独立地替换、扩容和故障转移。

因此，负载均衡器解决的是“请求应该去哪里”的问题，而不是替应用解决所有架构问题。

网络带宽也是如此。增加服务器数量并不意味着网站的所有瓶颈都会自动消失。如果数据库只有一个实例，而且所有服务器最终都必须访问同一个数据库，那么 Web 服务器从 5 台增加到 50 台之后，数据库反而可能先成为新的瓶颈。

缓存、数据库连接池、对象存储、CDN、网络带宽以及应用本身的代码，都可能成为系统的限制因素。一个设计糟糕的网站，即使放在云端、部署几十台服务器，也可能只是把“单服务器瓶颈”变成“数据库瓶颈”。

CDN 也不能和 Load Balancing 完全混为一谈。CDN 的核心任务是尽可能把静态内容和可缓存内容放到靠近用户的位置，而负载均衡主要负责把请求交给合适的后端。两者可以一起使用。对于图片、CSS、JavaScript、视频等大量可缓存内容，CDN 可以减少源站压力；对于动态 API、登录、订单等请求，则通常仍然需要后端服务参与处理。

从架构角度看，可以把一个现代网站理解成几层不同的系统。用户首先通过互联网访问统一入口，Google Cloud 的负载均衡系统负责接收并调度流量，然后把请求交给合适的 backend service 和具体后端。后端可能是虚拟机、容器、无服务器服务或者其他支持的资源。健康检查不断告诉系统哪些后端适合继续接收新请求，而自动扩缩容机制则根据业务压力调整后端数量。

所以，Google Cloud Load Balancing 最重要的意义并不是简单地“把访问量平均分给几台服务器”。

它改变的是网站的入口和后端之间的关系。用户只需要面对一个稳定的服务地址，而服务器可以在后面不断增加、减少、替换甚至跨区域迁移。某台服务器坏了，可以退出服务；流量上涨，可以增加实例；某个区域出现故障，可以把请求转移到其他可用区域。对于用户，这些变化最好完全不可见。

这也是现代云计算与传统“买一台更强服务器”的思维差异。传统方案往往首先考虑如何把一台机器做得更强，而云架构更关心如何让整个系统在机器不断变化的情况下仍然保持稳定。Load Balancing 只是其中的一环，但它把用户请求、网络、后端服务器、健康检查和自动扩容连接在了一起。

如果一个网站已经开始面临明显的访问量增长，与其单纯不断升级一台越来越昂贵的服务器，不如重新思考应用是否能够水平扩展。因为在真正的大规模互联网系统里，最可靠的服务器往往不是“永远不能坏的那一台”，而是“坏掉也不会让整个网站停下来的那一群服务器”。