内部 HTTP(S) 负载平衡概览

Google Cloud 内部 HTTP(S) 负载平衡是一种基于代理的地区级第 7 层负载平衡器,可让您在内部 IP 地址后面运行和扩缩您的服务。

内部 HTTP(S) 负载平衡将 HTTP 和 HTTPS 流量分配到 Compute Engine 和 Google Kubernetes Engine (GKE) 上托管的后端。这种负载平衡器只能使用内部 IP 地址在 Virtual Private Cloud (VPC) 网络的选定地区内访问。

内部 HTTP(S) 负载平衡是基于开源 Envoy 代理的代管式服务。这样可以实现基于 HTTP(S) 参数的丰富的流量控制功能。负载平衡器配置完毕后,它会自动根据您的流量需求分配 Envoy 代理。

概括来说,内部 HTTP(S) 负载平衡器包括以下几个方面:

  • 客户端向其发送流量的内部 IP 地址。只有位于负载平衡器所在地区的客户端才能访问此 IP 地址。内部客户端请求保持在您的网络和地区内部。
  • 负载平衡器向其转发流量的一项或多项后端服务。 后端可以是 Compute Engine 虚拟机、Compute Engine 虚拟机组(通过实例组)或 GKE 节点(通过网络端点组 [NEG])。这些后端必须位于负载平衡器所在的地区。
具有基于第 7 层的负载平衡的内部服务(点击放大)
具有基于第 7 层的负载平衡的内部服务(点击可放大)

如需了解特定于内部 HTTP(S) 负载平衡的限制,请参阅“限制”部分

如需了解各种 Google Cloud 负载平衡器之间的具体区别,请参阅以下文档:

使用场景

内部 HTTP(S) 负载平衡适用于许多用例。本部分提供了几个概要示例。如需了解其他示例,请参阅流量管理使用场景

三层 Web 服务

您可以使用内部 HTTP(S) 负载平衡来支持传统的三层 Web 服务。以下示例展示了如何使用三种类型的 Google Cloud 负载平衡器来为以下三个层级调节流量。每个层级的负载平衡器类型取决于流量类型:

下图显示了流量在各层级之间的移动方式:

  1. 外部 HTTP(S) 负载平衡器将来自互联网的流量分配到多个不同地区的一组 Web 前端实例组。
  2. 这些前端会将 HTTP(S) 流量发送到一组地区内部 HTTP(S) 负载平衡器(本概览文章的主题)。
  3. 内部 HTTP(S) 负载平衡器将流量分配到中间件实例组。
  4. 这些中间件实例组将流量发送到内部 TCP/UDP 负载平衡器,进而将流量负载平衡到数据存储集群。
多层应用中内部层的基于第 7 层的路由(点击放大)
多层应用中内部层的基于第 7 层的路由

使用基于路径的路由实现负载平衡

一种常见的使用场景是在各项服务之间对流量进行负载平衡。在此示例中,内部客户端可以使用同一基准网址 mygcpservice.internal 及路径 /video/images 来请求视频和图片内容。

内部 HTTP(S) 负载平衡器的网址映射指定对路径 /video 的请求应发送到视频后端服务,而对路径 /images 的请求应发送到图片后端服务。在以下示例中,视频和图片后端服务通过 Compute Engine 虚拟机提供,但也可以通过 GKE pod 提供。

当内部客户端将请求发送到负载平衡器的内部 IP 地址时,负载平衡器会根据此逻辑评估请求,并将请求发送到正确的后端服务。

下图演示了此用例。

具有基于第 7 层的负载平衡的内部(微)服务(点击放大)
具有基于第 7 层的负载平衡的内部(微)服务

对旧式服务进行现代化改造

内部 HTTP(S) 负载平衡是用于对旧式应用进行现代化改造的有效工具。

大型单体式应用是一种旧式应用,不容易对其进行更新。在这种情况下,您可以在旧式应用的前面部署一个内部 HTTP(S) 负载平衡器。然后,您可以利用该负载平衡器的流量控制功能,将一部分流量定向到新的微服务,以取代部分旧式应用功能。

首先,您需要将负载平衡器的网址映射配置为默认将所有流量路由到旧式应用。这维持了现有行为。随着替代服务的开发,您需要更新网址映射,以将部分流量路由到这些替代服务。

假设您的旧式应用包含在内部客户端向 /video 发送请求时提供的视频处理功能。您可以将此视频服务拆分为单独的微服务,如下所示:

  1. 在旧式应用前端添加内部 HTTP(S) 负载平衡。
  2. 创建替代的视频处理微服务。
  3. 更新负载平衡器的网址映射,使对路径 /video 的所有请求都路由到新的微服务,而不是旧式应用。

在开发其他替代服务时,您需要继续更新网址映射。随着时间推移,路由到旧式应用的请求将越来越少。 最终,旧式应用提供的所有功能都存在相应的替代服务。此时,您可以停用旧式应用。

Private Service Connect

您可以使用内部 HTTP(S) 负载均衡将请求发送到受支持的区域级 Google API 和服务。如需了解详情,请参阅 Private Service Connect

GKE 应用的负载平衡

如果您在 GKE 中构建应用,我们建议您使用内置 GKE Ingress 控制器,该控制器代表 GKE 用户部署 Google Cloud 负载平衡器。它与本页上介绍的独立负载平衡基础架构相同,只不过它的生命周期由 GKE 完全自动化并进行控制。

相关 GKE 文档:

架构和资源

下图显示了内部 HTTP(S) 负载平衡器所需的 Google Cloud 资源。

内部 HTTP(S) 负载平衡组件(点击放大)
内部 HTTP(S) 负载平衡组件

每个内部 HTTP(S) 负载平衡器都使用以下 Google Cloud 配置资源:

代理专用子网

在上图中,代理专用子网提供了一组 IP 地址,供 Google 用于代表您运行 Envoy 代理。您必须在其中使用内部 HTTP(S) 负载均衡器的 VPC 网络的每个区域中创建一个代理专用子网。一个地区内的所有内部 HTTP(S) 负载平衡器与 VPC 网络中的共享相同的代理专用子网,因为该地区内的所有内部 HTTP(S) 负载平衡器与 VPC 网络均共享一个 Envoy 代理池。此外:

  • 代理专用子网仅用于 Envoy 代理,不可用于您的后端。
  • 一个地区中的所有内部 HTTP(S) 负载平衡器的后端虚拟机或端点和 VPC 网络都会收到来自代理专用子网的连接。
  • 内部 HTTP(S) 负载平衡器的 IP 地址不位于代理专用子网中。负载平衡器的 IP 地址由其内部代管转发规则定义,如下所述。

转发规则和 IP 地址

内部代管转发规则指定内部 IP 地址、端口和区域目标 HTTP(S) 代理。客户端使用 IP 地址和端口连接到负载平衡器的 Envoy 代理,转发规则的 IP 地址是负载平衡器的 IP 地址(有时称为虚拟 IP 地址或 VIP)。

连接到内部 HTTP(S) 负载均衡器的客户端必须使用 HTTP 1.1 或更高版本。如需查看受支持的协议的完整列表,请参阅负载均衡器功能

与转发规则关联的内部 IP 地址可以来自任何子网(位于同一网络和地区),其 --purpose 标志设置为 PRIVATE。请注意以下事项:

  • 该 IP 地址可以(但并非必须)与后端实例组来自同一子网。
  • 该 IP 地址不得来自 --purpose 标志设置为 INTERNAL_HTTPS_LOAD_BALANCER 的预留代理专用子网。

您在内部 HTTP(S) 负载平衡器中使用的每个转发规则只能引用一个 TCP 端口。对于 HTTP 负载平衡器,请使用端口 80 或 8080;对于 HTTPS 负载平衡器,请使用端口 443。

目标代理

地区目标 HTTP(S) 代理会终结来自客户端的 HTTP(S) 连接。HTTP(S) 代理会查询网址映射以确定如何将流量路由到后端。目标 HTTPS 代理使用 SSL 证书向客户端进行身份验证。

负载平衡器会保留原始客户端请求的 Host 标头。负载平衡器还会将两个 IP 地址附加到 X-Forwarded-For 标头:

  • 连接到负载平衡器的客户端的 IP 地址
  • 负载平衡器转发规则的 IP 地址

如果传入请求中没有 X-Forwarded-For 标头,则这两个 IP 地址为整个标头值。如果请求具有 X-Forwarded-For 标头,则这两个 IP 地址前保留其他信息(例如代理在连接到负载平衡器时记录的 IP 地址)。负载平衡器不会验证此标头中最后两个 IP 地址之前的任何 IP 地址。

如果您作为后端服务器运行代理,则此代理通常会将更多信息附加到 X-Forwarded-For 标头,您的软件可能需要考虑到这一点。来自负载平衡器的代理请求来自代理专用子网中的 IP 地址,后端实例上的代理可能会记录此地址以及后端实例自己的 IP 地址。

SSL 证书

传输层安全协议 (TLS) 是 SSL 证书中用于保护网络通信的加密协议。

Google Cloud 使用 SSL 证书为客户端到负载平衡器提供隐私保护和安全性。如果您使用的是基于 HTTPS 的负载平衡,则必须在目标 HTTPS 代理上安装一个或多个 SSL 证书。

如需详细了解 SSL 证书,请参阅以下内容:

网址映射

HTTP(S) 代理使用区域性网址映射根据 HTTP 特性(例如请求路径、Cookie 或标头)确定路由。根据确定的路由,代理会将客户端请求转发到特定的区域性后端服务。网址映射可指定要执行的其他操作,如重写标头、向客户端发送重定向以及配置超时政策等。

后端服务

区域级后端服务会将请求分配给运行状况良好的后端:包含 Compute Engine 虚拟机的实例组、包含 GKE 容器的 NEG 或指向受支持的 Google API 和服务的 Private Service Connect NEG。

后端服务支持 HTTP、HTTPS 或 HTTP/2 协议。只能透过 TLS 支持 HTTP/2。客户端和后端不需要使用同一请求协议。例如,客户端可以使用 HTTP/2 向负载平衡器发送请求,而负载平衡器可以使用 HTTP/1.1 将这些请求转发到后端。

必须有一个或多个后端连接到后端服务。由于内部 HTTP(S) 负载平衡器的范围是地区(而非全球)性的,因此客户端和后端虚拟机或端点必须均位于同一地区。后端可以是采用以下任一配置的实例组或 NEG:

  • 代管式实例组(可用区级或区域级)
  • 非代管实例组(区域性)
  • 网络端点组(区域性)

您不能在同一后端服务中同时使用实例组和 NEG。

运行状况检查

地区运行状况检查会定期监控您的后端的就绪情况。这样可以降低向无法处理请求的后端发送请求的风险。

防火墙规则

内部 HTTP(S) 负载平衡器需要以下防火墙规则:

超时和重试

内部 HTTP(S) 负载平衡有三种截然不同的超时:
  • 可配置的 HTTP 后端服务超时:表示负载均衡器等待您的后端返回完整 HTTP 响应的时间。后端服务超时的默认值为 30 秒。允许的超时值的完整范围介于 1 到 2,147,483,647 秒之间。

    例如,如果后端服务超时值是默认值 30 秒,则后端有 30 秒的时间来响应请求。如果后端在将响应标头发送到负载均衡器之前关闭了连接或超时,则负载均衡器会重试一次 HTTP GET 请求。如果后端发送响应标头,或者发送到后端的请求不是 HTTP GET 请求,则负载均衡器不会重试。如果后端根本没有响应,则负载平衡器会向客户端返回 HTTP 5xx 响应。对于这些负载均衡器,如果您希望后端有更多或更少时间响应请求,请更改超时值。

    对于 Envoy 和后端之间的交互,后端服务超时应设置为从请求的第一个字节到响应的最后一个字节的最长可能时间。如果您使用的是 WebSocket,则后端服务超时应设置为 WebSocket 空闲或活动的时长上限。

    在以下任一情况下,请考虑延长此超时:

    • 您预计后端需要更长时间才能返回 HTTP 响应。
    • 连接升级到 WebSocket。

    您设置的后端服务超时是尽力而为的目标。我们无法保证底层 TCP 连接会在该超时期间保持打开状态。

    您可以将后端服务超时设置为所需的任何值;但是,将其设置为超过 1 天(86400 秒)的值并不意味着负载均衡器会保持 TCP 连接运行那么长时间。也可能会如此,但也可能不会如此。Google 会定期重启 Envoy 代理以进行软件更新和例行维护,而且您的后端服务超时不会覆盖它。您后端服务超时设置的时间越长,Google 终止 TCP 连接以进行 Envoy 维护的可能性就越大。我们建议您实现重试逻辑,以降低此类事件的影响。

    如需了解详情,请参阅后端服务设置

    后端服务超时不是 HTTP 空闲 (keepalive) 超时。由于客户端较慢(例如浏览器连接速度较慢),系统可能会阻止后端的输入和输出 (IO)。这种情况下的等待时间不会计入后端服务超时。

  • HTTP keepalive 超时的值固定为 10 分钟(600 秒)。 无法通过修改后端服务配置此值。您必须配置后端使用的网络服务器软件,以使其 keepalive 超时时间大于 600 秒,以防止后端过早关闭连接。此超时不适用于 WebSocket。 下表说明了修改常用 Web 服务器软件的 keepalive 超时需要进行的更改:
    Web 服务器软件 参数 默认设置 推荐设置
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • 流空闲超时,其值固定为 5 分钟(300 秒)。此值不可配置。如果 HTTP 流 5 分钟没有活动,将变为空闲。

重试

您可以使用网址映射 (numRetries) 中的重试政策来配置重试。如果没有重试政策,则默认情况下,系统会限制只能尝试请求两次。负载均衡器在特定情况(例如达到后端服务超时时间时)下会重试失败的 GET 请求。它不会重试失败的 POST 请求。重试请求仅会为最终响应生成一个日志条目。

如需了解详情,请参阅 内部 HTTP(S) 负载平衡日志记录和监控

访问连接的网络

您可以从使用以下方式连接的网络访问 VPC 网络中的内部 HTTP(S) 负载平衡器:

  • VPC 网络对等互连
  • Cloud VPN 和 Cloud Interconnect

如需查看详细示例,请参阅内部 HTTP(S) 负载平衡和连接的网络

故障转移

如果后端运行状况不佳,流量会被自动重定向到同一区域内的运行状况良好的后端。如果所有后端运行状况不佳,则负载平衡器将返回 HTTP 503 Service Unavailable 响应。

WebSocket 支持

当您使用 HTTP 或 HTTPS 作为后端协议时,基于 Google Cloud HTTP(S) 的负载平衡器可以为 WebSocket 协议提供原生支持。负载平衡器无需进行任何配置即可代理 WebSocket 连接。

WebSocket 协议提供客户端和服务器之间的全双工通信通道。该通道由 HTTP(S) 请求发起。如需详细了解该协议,请参阅 RFC 6455

如果负载平衡器识别到来自 HTTP(S) 客户端的 WebSocket Upgrade 请求,并且后端实例为该请求返回了成功的 Upgrade 响应,则负载平衡器会在当前连接期间代理双向流量。如果后端实例未返回成功的 Upgrade 响应,则负载平衡器会关闭连接。

WebSocket 连接的超时时间取决于负载平衡器的可配置后端服务超时,默认为 30 秒。该超时适用于 WebSocket 连接,无论其是否正在使用。

WebSocket 的会话亲和性与其他任何请求的运作方式相同。如需了解详情,请参阅会话亲和性

gRPC 支持

gRPC 是远程过程调用的开源框架。它基于 HTTP/2 标准运行。适合使用 gRPC 的场景如下:

  • 延迟时间短、扩缩能力强的分布式系统
  • 开发与云服务器通信的移动客户端
  • 设计必须准确、高效并且独立于语言的新协议
  • 支持扩展、身份验证和日志记录的分层设计

如需将 gRPC 与您的 Google Cloud 应用搭配使用,您必须通过 HTTP/2 以端到端方式对请求进行代理。为此,请按以下说明操作:

  1. 配置 HTTPS 负载平衡器。
  2. 启用 HTTP/2 作为从负载平衡器到后端的协议。

在进行 SSL 握手过程中,负载平衡器会通过使用 ALPN TLS 扩展程序与客户端协商 HTTP/2。

负载均衡器仍然可以与某些客户端协商 HTTPS,或接受配置为在负载均衡器和后端实例之间使用 HTTP/2 的负载均衡器上的不安全 HTTP 请求。这些 HTTP 或 HTTPS 请求由负载平衡器进行转换,以便通过 HTTP/2 将请求代理到后端实例。

您必须在后端上启用 TLS。如需了解详情,请参阅从负载平衡器到后端的加密

共享 VPC 架构

内部 HTTP(S) 负载平衡支持使用共享 VPC 的网络。如果您还不熟悉共享 VPC,请阅读共享 VPC 概览文档

在内部 HTTP(S) 负载平衡环境中,可以通过两种方式在共享 VPC 网络中配置负载平衡。 您可以在服务项目或宿主项目中创建负载平衡器及其后端实例。

服务项目中的负载平衡器和后端

在此模型中,负载平衡器和后端存在于服务项目中,并使用共享 VPC 网络的子网中的 IP 地址。

此部署模型与典型的共享 VPC 用例密切相关:

  • 通过划分网络管理与服务开发之间的责任,即可明确区分网络管理员和应用开发者。
  • 允许网络管理员安全高效地管理内部 IP 地址。
共享 VPC 网络中的内部 HTTP(S) 负载平衡
共享 VPC 网络中的内部 HTTP(S) 负载平衡

宿主项目

在宿主项目中:

服务项目

  • 服务项目的 Owner、Editor 或更精细的角色(例如 Compute Admin)可创建后端实例。
  • 服务项目的 Owner、Editor 或更精细的角色(例如 Network Admin 或 Load Balancer Admin)可创建负载平衡器组件(转发规则、目标 HTTP( S) 代理、网址映射、后端服务和运行状况检查)。
  • 这些负载平衡资源和后端实例会引用宿主项目中的共享 VPC 网络和子网。

如果客户端与负载平衡器位于同一共享 VPC 网络和区域,则客户端可以访问负载平衡器。客户端可以位于服务项目中,也可位于宿主项目中。

如需了解如何为共享 VPC 网络配置内部 HTTP(S) 负载平衡器,请参阅设置使用共享 VPC 的内部 HTTP(S) 负载平衡

宿主项目中的负载平衡器和后端

在此模型中,共享 VPC 网络、负载平衡器组件和后端都位于宿主项目中。此模型不划分网络管理和服务责任。

此模型的配置方法与在独立 VPC 网络中配置负载平衡器的方法相同。按照设置内部 HTTP(S) 负载平衡中的步骤操作。

TLS 支持

默认情况下,HTTPS 目标代理在终结客户端 SSL 请求时仅接受 TLS 1.0、1.1、1.2 和 1.3。

当内部 HTTP(S) 负载平衡器使用 HTTPS 作为后端服务协议时,它可以与后端协商 TLS 1.0、1.1、1.2 或 1.3。

限制

  • 内部 HTTP(S) 负载平衡在地区级运行。

  • 我们无法保证地区中某区域的客户端发出的请求会发送到与该客户端位于相同区域的后端。 会话亲和性不会减少区域之间的通信。

  • 内部 HTTP(S) 负载平衡与以下功能不兼容:

  • 在共享 VPC 宿主服务项目中创建内部 HTTP(S) 负载平衡器时:

    • 所有负载平衡组件和后端都必须存在于同一项目中,或者全都位于宿主项目或服务项目中。例如,您不能在一个项目中部署负载平衡器的转发规则,而在另一个项目中创建后端实例。

    • 客户端可以位于宿主项目、任何关联的服务项目或任何连接的网络中。 客户端必须使用相同的共享 VPC 网络,并且与负载平衡器位于同一地区。

  • 内部 HTTP(S) 负载平衡器仅支持通过 TLS 使用 HTTP/2。

  • 连接到内部 HTTP(S) 负载均衡器的客户端必须使用 HTTP 1.1 或更高版本。不支持 HTTP 1.0。

  • 如果代理专用子网的 IP 地址耗尽,Google Cloud 不会向您发出警告。

  • 内部 HTTP(S) 负载平衡器使用的内部转发规则必须只有一个端口。

  • 内部 HTTP(S) 负载平衡不支持 Cloud Trace

  • 内部 HTTP(S) 负载平衡器不支持 VPC 网络对等互连。您必须在同一 VPC 网络中创建负载平衡器的转发规则和后端。

后续步骤