内部 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 层的负载平衡的内部服务(点击可放大)

以下两个附加组件用于提供负载平衡服务:

  • 网址映射,用于定义映射到特定后端服务的流量控制规则(基于第 7 层参数,例如 HTTP 标头)。负载平衡器会根据网址映射评估传入的请求,以将流量路由到后端服务或执行其他操作(例如重定向)。
  • 运行状况检查,用于定期检查后端的状态并降低将客户端流量发送到无响应的后端的风险。

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

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

用例

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

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

一种常见的使用场景是在各项服务之间对流量进行负载平衡。在此示例中,内部客户端可以使用同一基准网址 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 的所有请求都路由到新的微服务,而不是旧式应用。

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

三层 Web 服务

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

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

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

访问示例

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

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

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

架构和资源

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

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

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

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

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

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

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

    • 该 IP 地址可以(但并非必须)与后端实例组来自同一子网。
    • 该 IP 地址不得来自 --purpose 标志设置为 INTERNAL_HTTPS_LOAD_BALANCER 的预留代理专用子网。
  • 地区目标 HTTP(S) 代理接收来自客户端的请求。HTTP(S) 代理使用网址映射评估请求,从而做出流量路由决策。该代理还可以使用 SSL 证书对通信进行身份验证。

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

  • 地区后端服务会将请求分配给运行状况良好的后端(包含 Compute Engine 虚拟机的实例组或包含 GKE 容器的 NEG)。

  • 必须将一个或多个后端连接到后端服务。后端可以是采用以下任一配置的实例组或 NEG:

    • 代管实例组(区域性或地区性)
    • 非代管实例组(区域性)
    • 网络端点组(区域性)

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

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

SSL 证书

如果您使用的是基于 HTTPS 的负载平衡,则必须在目标 HTTPS 代理上安装一个或多个 SSL 证书

目标 HTTPS 代理使用这些证书来保护负载平衡器和客户端之间的通信。

如需了解 SSL 证书限制和配额,请参阅负载平衡配额页面上的 SSL 证书

为获得最佳安全性,请为 HTTPS 负载平衡器部署使用端到端加密。如需了解详情,请参阅从负载平衡器到后端的加密

如需了解有关 Google 如何对用户流量进行加密的一般信息,请参阅Google Cloud 中的传输加密白皮书。

防火墙规则

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

超时和重试

后端服务超时是 HTTP(S) 流量的请求/响应超时。 这是负载平衡器等待后端返回对请求的完整响应的时间量。

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

内部 HTTP(S) 负载平衡有两种截然不同的超时:
  • 可配置的 HTTP 后端服务超时:表示负载平衡器等待您的后端返回完整 HTTP 响应的时间。后端服务超时的默认值为 30 秒。在以下任一情况下,请考虑延长此超时:

    • 您预计后端需要更长时间才能返回 HTTP 响应。
    • 您看到带有 jsonPayload.statusDetail client_timed_out 的 HTTP 408 响应。
    • 连接升级到 WebSocket

    对于通过负载平衡器发送的 WebSocket 流量,后端服务超时被解释为 WebSocket 连接可以保持打开状态(无论是否空闲)的最长时间。如需了解详情,请参阅后端服务设置

  • TCP 会话超时:其值固定为 10 分钟(600 秒)。此会话超时有时称为 keepalive 或空闲超时,并且其值无法通过修改后端服务进行配置。为了防止后端过早关闭连接,您必须配置后端使用的 Web 服务器软件,设置大于 600 秒的 keepalive 超时。此超时不适用于 WebSocket

下表说明了修改常用 Web 服务器软件的 keepalive 超时需要进行的更改:

Web 服务器软件 参数 默认设置 推荐设置
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

负载平衡器在特定情况(例如达到后端服务超时时间时)下会重试失败的 GET 请求。它不会重试失败的 POST 请求。重试次数以两次为限。重试请求仅会为最终响应生成一个日志条目。

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

WebSocket 支持

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

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

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

WebSocket 连接的超时时间取决于负载平衡器的可配置后端服务超时,默认为 30 秒。该超时适用于 WebSocket 连接,无论其是否正在使用。如需详细了解后端服务超时及其配置方式,请参阅超时和重试

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

流量类型、方案和范围

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

由于内部 HTTP(S) 负载平衡器的范围是地区(而非全球)性的,因此客户端和后端虚拟机或端点必须均位于同一地区。

共享 VPC 架构

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

  • 您可以指定一个宿主项目,并将一个或多个其他服务项目关联到该项目。
  • 宿主项目管理员可以创建一个或多个共享 VPC 网络和子网,并与服务项目共享这些网络和子网。
  • 服务项目中的合格资源可以使用共享 VPC 网络中的子网。

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

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

在此模型中,您可以在服务项目中部署负载平衡器和后端实例,然后将负载平衡器和后端实例配置为使用共享 VPC 网络。

此部署模型与共享 VPC 网络部署模型的典型使用场景(即网络管理和服务开发之间的责任分工)密切相关。它可让网络管理员安全高效地分配内部 IP 空间,并可明确区分网络管理员和服务开发者之间的责任。

共享 VPC 网络中的内部 HTTP(S) 负载平衡
共享 VPC 网络中的内部 HTTP(S) 负载平衡

宿主项目

宿主项目管理员执行以下操作:

  • 在宿主项目中设置共享 VPC 网络。
  • 预配共享 VPC 网络中的子网。
  • 在共享 VPC 网络中配置防火墙规则。

服务项目

  • 服务项目管理员在服务项目中创建负载平衡器(转发规则、目标 HTTP(S) 代理、网址映射、后端服务)和后端实例。
  • 这些负载平衡资源和后端实例会引用共享 VPC 宿主项目中的共享网络和子网。

此模式使服务开发者能够在自己的服务项目中创建负载平衡服务。服务开发团队还可以在没有宿主项目管理员协助的情况下更新负载平衡器的配置并更改后端实例。

如果客户端与负载平衡器位于同一共享 VPC 网络中,则客户端可以位于宿主项目或服务项目中。此类客户端可以使用负载平衡器的专用 IP 地址访问负载平衡服务。

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

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

使用此网络部署模型时,网络、负载平衡器和后端都在宿主项目中。虽然此设置有效,但并不适合典型的共享 VPC 部署,因为它不会区分网络管理和服务开发责任。

如果您仍需要在宿主项目中运行负载平衡器及其后端,则可以按照设置内部 HTTP(S) 负载平衡中的步骤操作。

限制

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

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

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

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

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

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

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

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

  • 在每个 VPC 网络中,每个内部代管转发规则都必须有专属的 IP 地址。如需了解详情,请参阅具有相同 IP 地址的多条转发规则

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

后续步骤