确定 Google Cloud 着陆区的网络设计

Last reviewed 2026-01-02 UTC

设计着陆区时，您必须选择适合您组织的网络设计。本文档介绍四种常见的网络设计，并可帮助您选择最符合贵组织要求以及贵组织对集中控制或分散控制的偏好的方案。本文档适用于为组织的着陆区创建网络设计的网络工程师、架构师和技术从业人员。

本文是关于着陆区的系列文章中的一篇。

选择网络设计

您选择的网络设计主要取决于以下因素：

  • 集中式或分散式控制：根据您的组织的偏好，您必须选择以下选项之一：
    • 集中控制网络，包括不同工作负载之间的 IP 寻址、路由和防火墙。
    • 让您的团队更自主地运行各自的环境并在其环境本身内构建网络元素。
  • 本地或混合云连接选项 ：本文档讨论的所有网络 设计都通过 Cloud VPN 或 Cloud Interconnect提供从本地到云 环境的访问。但是，有些设计要求您并行设置多个连接，而有些设计则对所有工作负载都使用相同的连接。
  • 安全要求：您的组织可能要求不同工作负载之间的流量 通过 Google Cloud 集中式网络设备，例如 下一代防火墙 (NGFW)。此限制条件会影响您的虚拟私有云 (VPC) 网络设计。
  • 可伸缩性：某些设计可能比其他设计更适合您的组织，具体取决于您要部署的工作负载数量、虚拟机 (VM) 数量、内部负载均衡器以及所使用的其他资源。

网络设计的决策点

以下流程图展示了为您的组织选择最佳网络设计而必须做出的决策。

网络设计的决策。

上图将引导您完成以下问题：

  1. 您是否要求在 Google Cloud 中的不同工作负载之间使用网络设备执行 第 7 层 检查 Google Cloud？
  2. 是否许多工作负载需要本地连接？
    • 如果是，请前往决策点 4。
    • 如果不是，请继续回答下一个问题。
  3. 您的工作负载是否可以使用服务提供方和使用方模型中的专用端点进行通信？
  4. 您是否要集中管理防火墙和路由？

此图表旨在帮助您做出决策，但通常存在多种设计可能适合您的组织的情况。在这些情况下，我们建议您选择最适合自己使用场景的设计。

网络设计方案

以下部分介绍了四种常见的设计方案。对于大多数使用场景，建议采用方案 1。本部分介绍的其他设计是适用于特定组织边缘用例要求的替代设计。

最适合您使用场景的网络也可能是结合了本部分讨论的多种设计方案中的元素。例如，您可以使用 共享 VPC 网络，在中心辐射型拓扑中实现更好的协作、集中式 控制并限制 VPC spoke 的数量。或者，您可能 在共享 VPC 拓扑中设计大多数工作负载，但仅在少量 VPC 网络中隔离少量工作负载，这些网络仅通过几个定义的端点使用 Private Service Connect公开 服务。

方案 1：每个环境使用共享 VPC 网络

对于大多数使用场景，建议使用此网络设计。此设计为您在 Google Cloud 中的每个部署环境（开发、测试和生产）使用单独的 共享 VPC 网络 Google Cloud 。此设计使您可以集中管理公共网络中的网络资源，并在不同的环境之间实现网络隔离。

如果满足以下条件，请使用此设计：

  • 您希望集中控制防火墙和路由规则。
  • 您需要一个简单、可伸缩的基础架构。
  • 您需要进行集中式 IP 地址空间管理。

如果满足以下条件，请避免使用此设计：

  • 您希望开发者团队拥有完全自主性，包括能够管理自己的防火墙规则、路由以及与其他团队网络的对等互连。
  • 您需要使用 NGFW 设备执行第 7 层检查。

下图展示了此设计的示例实现。

方案 1 图示。

上图显示了以下内容：

  • 本地网络分布在两个地理位置。
  • 本地网络通过冗余 Cloud Interconnect 实例连接到两个单独的共享 VPC 网络，一个用于生产环境，一个用于开发环境。
  • 生产环境和开发环境使用不同的 VLAN 连接连接到两个 Cloud Interconnect 实例。
  • 每个共享 VPC 都具有托管工作负载的服务项目。
  • 防火墙规则在宿主项目中集中管理。
  • 开发环境与生产环境具有相同的 VPC 结构。

根据设计，来自一个环境的流量无法到达另一个环境。 但是，如果特定工作负载必须相互通信，则您可以允许 通过本地受控渠道进行数据传输，也可以通过 Google Cloud 服务（如 Cloud Storage 或 Pub/Sub）在应用之间共享数据。 Google Cloud 我们建议您避免通过 VPC 网络对等互连直接连接不同的环境，因为这会增加环境之间意外混合数据的风险。在大型 环境之间使用 VPC 网络对等互连还会增加达到 VPC 配额 的对等互连和对等互连组的风险。

详情请参阅以下内容：

如需实现此设计选项，请参阅 创建选项 1：为每个环境创建共享 VPC 网络。

方案 2：具有集中式设备的中心辐射型拓扑

此网络设计使用中心辐射型拓扑。Hub VPC 网络包含一组设备虚拟机（例如 NGFW），这些虚拟机连接到包含工作负载的 spoke VPC 网络。工作负载、本地网络或互联网之间的流量通过设备虚拟机来路由，以进行检查和过滤。

如果满足以下条件，请使用此设计：

  • 您需要在不同工作负载或应用之间执行第 7 层检查。
  • 您的公司强制要求为所有流量指定安全设备供应商。

如果满足以下条件，请避免使用此设计：

  • 您不需要为大多数工作负载执行第 7 层检查。
  • 您希望 Google Cloud 上的工作负载完全不相互通信。 Google Cloud
  • 您只需检查第 7 层流量即可进入本地网络。

下图展示了此模式的示例实现。

方案 2 图示。

上图显示了以下内容：

  • 具有 hub VPC 网络和多个包含工作负载的 spoke VPC 网络的生产环境。
  • Spoke VPC 网络使用 VPC 网络对等互连与 hub VPC 网络连接。
  • Hub VPC 网络在托管式实例组中有多个虚拟设备实例。进入托管式实例组的流量流经内部直通网络负载均衡器。
  • Spoke VPC 网络通过虚拟设备并使用将内部负载均衡器作为下一个跃点的静态路由相互通信。
  • Cloud Interconnect 将中转 VPC 网络连接到本地位置。
  • 本地网络使用单独的 VLAN 连接通过相同的 Cloud Interconnect 互连进行连接。
  • 传输 VPC 网络连接到虚拟设备上的单独网络接口，可让您使用设备检查和过滤进出这些网络的所有流量。
  • 开发环境与生产环境具有相同的 VPC 结构。
  • 此设置不使用来源网络地址转换 (SNAT)。使用对称哈希技术，因此无需使用 SNAT 。 Google Cloud 如需了解详情，请参阅 对称哈希。

根据设计，来自一个 spoke 网络的流量无法到达另一个 spoke 网络。 但是，如果特定工作负载必须相互通信，则您可以使用 VPC 网络对等互连在 spoke 网络之间设置直接对等互连，或者您 可以通过 Google Cloud 服务（如 Cloud Storage 或 Pub/Sub）在应用之间共享数据。 Google Cloud

为了在设备在工作负载之间进行通信时保持低延迟，设备必须与工作负载位于同一 区域。如果您在云部署中使用多个区域，则每个区域中的每个环境可以有一组设备和一个 hub VPC。或者，您可以使用 带有路由的网络标记 ，让所有实例都与最近的设备通信。

防火墙规则 可以限制包含工作负载的 spoke VPC 网络中的连接。 通常，管理工作负载的团队也会管理这些防火墙规则。对于中央政策，您可以使用分层防火墙政策。如果您需要中央网络团队完全控制防火墙规则，请考虑使用 GitOps 方法在所有 VPC 网络中集中部署这些规则。 在这种情况下，请仅将 IAM 权限授予可以更改防火墙规则的管理员。如果多个团队在 spoke 中部署，则 spoke VPC 网络也可以是共享 VPC 网络。

在此设计中，我们建议您使用 VPC 网络对等互连来连接 hub VPC 网络和 spoke VPC 网络，因为这样增加的复杂性最低。但是，spoke 数量上限受以下各项的限制：

  • 来自单个 VPC 网络的 VPC 网络对等互连连接数的限制。
  • 对等互连组限制，例如每个对等互连组的内部 TCP/UDP 负载均衡的转发规则数上限。

如果您预计会达到这些限制，则可以通过 Cloud VPN 连接 spoke 网络。使用 Cloud VPN 会增加额外的费用和复杂性，并且每个 Cloud VPN 隧道都具有带宽限制。

详情请参阅以下内容：

如需实现此设计选项，请参阅 创建选项 2：采用集中式设备的中心辐射型拓扑。

方案 3：无设备的中心辐射型拓扑

此网络设计也使用中心辐射型拓扑，其中具有连接到本地网络的 hub VPC 网络和包含工作负载的 spoke VPC 网络。由于 VPC 网络对等互连不具有传递性，因此 spoke 网络无法直接相互通信。

如果满足以下条件，请使用此设计：

  • 您希望 Google Cloud 中的工作负载或环境完全不使用内部 IP 地址相互通信，但您希望它们共享本地连接。 Google Cloud
  • 您希望让团队更自主地管理各自的防火墙和路由规则。

如果满足以下条件，请避免使用此设计：

  • 您需要在工作负载之间执行第 7 层检查。
  • 您希望集中管理路由和防火墙规则。
  • 您需要从本地服务与通过其他 VPC 网络对等互连连接到 spoke 的代管式服务进行通信，因为 VPC 网络对等互连不具有传递性。

下图展示了此设计的示例实现。

方案 3 图示。

上图显示了以下内容：

  • 具有 hub VPC 网络和多个包含工作负载的 spoke VPC 网络的生产环境。
  • Spoke VPC 网络使用 VPC 网络对等互连与 hub VPC 网络连接。
  • 与本地位置的连接通过 hub VPC 网络中的 Cloud Interconnect 连接。
  • 本地网络使用单独的 VLAN 连接通过 Cloud Interconnect 实例进行连接。
  • 开发环境与生产环境具有相同的 VPC 结构。

根据设计，来自一个 spoke 网络的流量无法到达另一个 spoke 网络。 但是，如果特定工作负载必须相互通信，则您可以使用 VPC 网络对等互连在 spoke 网络之间设置直接对等互连，或者您 可以通过 Google Cloud 服务（如 Cloud Storage 或 Pub/Sub）在应用之间共享数据。 Google Cloud

此网络设计通常用于团队自主执行操作并且无法集中控制防火墙和路由规则的环境。但是，此设计的规模受以下各项的限制：

因此，此设计通常不用于具有 许多不同工作负载的大型组织 Google Cloud。

作为此设计的一种变体，您可以使用 Cloud VPN 来代替 VPC 网络对等互连。Cloud VPN 可让您增加 spoke 的数量，但会增加 每个隧道的带宽限制 并且会增加复杂性和费用。使用 自定义通告路由时， Cloud VPN 还允许 spoke 网络之间具有传递性，而无需 您直接连接所有 spoke 网络。

详情请参阅以下内容：

如需实现此设计选项，请参阅 创建选项 3：没有设备的中心辐射型拓扑。

方案 4：使用 Private Service Connect 在使用方提供方模型中公开服务

在此网络设计中，每个团队或工作负载都有自己的 VPC 网络，该网络还可以是共享 VPC 网络。每个 VPC 网络都是独立管理的，并使用 Private Service Connect 公开需要从 VPC 网络外部访问的所有服务。

如果满足以下条件，请使用此设计：

  • 工作负载仅通过定义的端点相互通信以及与本地环境通信。
  • 您希望团队彼此独立并管理他们自己的 IP 地址空间、防火墙和路由规则。

如果满足以下条件，请避免使用此设计：

  • 服务和应用之间的通信使用许多不同的端口或通道，或者端口和通道经常更改。
  • 工作负载之间的通信使用 TCP 或 UDP 以外的协议。
  • 您需要在工作负载之间执行第 7 层检查。

下图展示了此模式的示例实现。

方案 4 图示。

上图显示了以下内容：

  • 不同的工作负载位于不同的项目和 VPC 网络中。
  • 一个 VPC 网络中的客户端虚拟机可以通过 Private Service Connect 端点连接到另一个 VPC 网络中的工作负载。
  • 该端点连接到服务所在的 VPC 网络中的服务连接。 如果端点已配置为全球访问权限，则服务连接可以与端点位于不同的区域。
  • 服务连接通过 Cloud Load Balancing 连接到工作负载。
  • 工作负载 VPC 中的客户端可以按以下方式访问位于本地的工作负载：
    • 该端点连接到中转 VPC 网络中的服务连接。
    • 服务连接使用 Cloud Interconnect 连接到本地网络。
  • 内部应用负载均衡器连接到服务连接，并使用混合网络端点组来平衡位于本地的端点之间的流量负载。
  • 本地客户端还可以访问中转 VPC 网络中连接到工作负载 VPC 网络中的服务连接的端点。

详情请参阅以下内容：

如需实现此设计选项，请参阅创建方案 4：使用 Private Service Connect 在“使用方-提供方”模型中公开服务。

网络部署的最佳实践

选择最适合您的使用场景的网络设计后，我们建议您实现以下最佳实践：

如需了解详情，请参阅 VPC 设计的最佳实践与参考架构。

后续步骤