[解决方案] Cross-Cloud Network 中的 VPC 间连接架构模式

**发布时间:** 2025-02-27 **厂商:** GCP **类型:** BLOG **原始链接:** https://cloud.google.com/blog/products/networking/inter-network-communication-design-with-ncc-vpc-peering --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] Cross-Cloud Network 中的 VPC 间连接架构模式 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该文档详细阐述了在 **Google Cloud** 的 **Cross-Cloud Network** 框架下，构建跨越多VPC（虚拟私有云）网络连接的两种核心架构模式。**Cross-Cloud Network** 是一个利用谷歌全球软件定义骨干网，为分布式应用提供“任意到任意”（any-to-any）连接能力的解决方案集。 该方案旨在解决企业在上云过程中，随着业务增长和网络数量增加而面临的日益复杂的**网络间通信**问题，特别是混合云（连接本地数据中心）和多云环境下的连接需求。两种架构均采用经典的 **Hub-and-Spoke（中心辐射型）** 模型，通过一个中央 **`transit VPC`**（中转VPC）作为流量枢纽，连接外部网络（如本地环境或其他云）和多个内部的 **`workload VPC`**（工作负载VPC）。 ## 架构模式对比分析 文档对比了两种实现 Hub-and-Spoke 模型的不同技术路径，一种是基于传统的 VPC 对等连接，另一种是基于更现代的网络连接中心。 ### 模式一：基于 VPC Network Peering 的连接 - **核心机制**: 此模式主要利用 **VPC Network Peering** 在中央 `transit VPC` 和各个 `workload VPC` 之间建立直接的、私有的、非公开路由的连接。 - **技术特点**: - **非传递性 (Non-transitive)**: 这是 VPC Peering 的一个关键特性。默认情况下，通过 Hub VPC 连接的两个 Spoke VPC 之间不能相互通信。例如，`workload VPC 1` 无法通过 `transit VPC` 将流量路由到 `workload VPC 2`。 - **扩展性**: 若要实现 Spoke 之间的通信，必须在它们之间建立直接的 Peering 连接，或者额外使用 **Network Connectivity Center (NCC) 的 VPC Spoke** 功能作为补充。当 VPC 数量增多时，管理网状的 Peering 关系会变得非常复杂。 ### 模式二：基于 Network Connectivity Center (NCC) 的连接 - **核心机制**: 该模式被描述为一种 **更现代的设计**，它使用 **Network Connectivity Center (NCC)** 作为网络拓扑的中心管理平面，将各个 VPC 作为 **Spoke** 连接到 NCC Hub。 - **技术特点**: - **集中式管理**: NCC 允许管理员以声明方式定义网络拓扑，例如 **星型 (star)** 或 **网状 (mesh)**，并集中管理路由策略。 - **传递性路由 (Transitive Routing)**: 这是与 Peering 模式最核心的区别。NCC 原生支持 Spoke 之间的传递路由。流量可以从一个 `workload VPC` 经由中央 Hub 路由到另一个 `workload VPC`，极大地简化了大规模网络环境下的连接和路由管理。 - **可扩展性**: 对于拥有大量 VPC 的复杂网络环境，NCC 提供了更优越的可扩展性和可管理性。 ## 涉及的相关产品 两种架构模式使用了相似的产品组合，但核心连接技术的侧重点不同。 - **Cloud Interconnect**: 提供从本地或其他云到 `transit VPC` 的高带宽、低延迟的专用连接，包括物理专线（Direct）、合作伙伴专线（Partner）和跨云专线（Cross-Cloud）。 - **Cloud VPN**: 提供基于 IPsec 的安全 VPN 通道，用于连接外部网络或在 GCP 内部（如此处用于连接 `service access VPC` 和 `transit VPC`）传输加密流量。 - **VPC Network Peering**: 在模式一中是核心组件，用于连接 `workload VPC` 和 `transit VPC`。它在谷歌网络内部建立私有连接。 - **Network Connectivity Center (NCC)**: 在模式二中是核心组件，作为一个集中式的网络连接管理平台，通过其 **VPC Spoke** 功能实现 VPC 间的灵活连接和路由。 - **Private services access**: 用于从用户 VPC 私密地连接到由 Google 管理的服务（如 Cloud SQL），这些服务托管在 Google 拥有的 VPC 中。 - **Private Service Connect**: 允许服务生产者在一个 VPC 中发布服务，而服务消费者可以在自己的 VPC 中创建私有端点来使用这些服务，实现了跨 VPC 的安全服务消费。 ## 技术评估 - **VPC Peering 模式**: - **优势**: 对于简单的 Hub-and-Spoke 场景，配置相对直接。连接建立在 Google 的骨干网上，性能和延迟表现优秀。 - **局限性**: 其 **非传递性** 的本质是最大的限制。随着网络规模扩大，需要管理的 Peering 连接数量会呈指数级增长，导致所谓的“网状网络管理难题”（mesh complexity），运维成本高，且容易出错。 - **Network Connectivity Center (NCC) 模式**: - **优势**: 提供了更先进和高度可扩展的解决方案。通过 **集中式拓扑和路由管理**，有效解决了 VPC Peering 的扩展性问题。原生支持 **传递路由**，是构建大型、复杂企业网络的理想选择，显著降低了管理复杂度。 - **局限性**: 文档未明确指出其局限性。但通常这类集中式管理平台相比简单的点对点连接，初始配置可能涉及更多概念。其功能和性能高度依赖于中央 Hub 的设计和可靠性。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 跨云网络 (Cross-Cloud Network) 中的 VPC 间连接架构模式 **原始链接:** [https://cloud.google.com/blog/products/networking/inter-network-communication-design-with-ncc-vpc-peering](https://cloud.google.com/blog/products/networking/inter-network-communication-design-with-ncc-vpc-peering) **发布时间:** 2025-02-27 **厂商:** GCP **类型:** BLOG --- 网络 # 跨云网络 (Cross-Cloud Network) 中的 VPC 间连接架构模式 2025 年 2 月 27 日  ##### Ammett Williams 开发者关系工程师 ##### Mark Schlagenhauf 技术文档工程师 ##### Google Cloud Next 点播观看 Next 大会的精彩集锦。 [立即观看](https://cloud.withgoogle.com/next/25?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=cgc-blog-left-hand-rail-post-next&utm_term=-) 将混合环境连接到云是云架构中一个至关重要的方面。除了从本地环境 (on-premises environments) 连接，您可能还有需要相互通信的多云环境。在本博客中，我们将探讨一些使用 [跨云网络 (Cross-Cloud Network)](https://cloud.google.com/solutions/cross-cloud-network?hl=en) 实现中心辐射型 (hub-and-spoke) 通信的参考架构。 ## **跨云网络 (Cross-Cloud Network) 的强大功能** 随着您的云项目不断增长并添加更多网络，您需要实现网络间的通信。跨云网络 (Cross-Cloud Network) 提供了一套功能和架构，利用 Google 的软件定义全球骨干网连接您分布式的应用，实现任意节点间的连接。 让我们来看两种架构模式：一种基于 [VPC 网络对等互连 (VPC Network Peering)](https://cloud.google.com/vpc/docs/vpc-peering) ，另一种基于 [网络连接中心 (Network Connectivity Center)](https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/overview) 。 ### **#1 - 使用 VPC 网络对等互连 (VPC Network Peering) 的 VPC 间通信示例模式** 为了理解如何思考网络设计，让我们来看一个数据包从 **外部网络 (external network)** 流向位于 Google Cloud 中 **工作负载 VPC 网络 1 (workload VPC network 1)** 的应用的流程。该设计侧重于使用 VPC 网络对等互连。整个网络由 **外部网络** (本地和其他云) 和 **Google Cloud 网络** (中转 VPC、服务访问 VPC、托管服务 VPC、工作负载 VPC) 组成。  该设计使用以下服务来构建其端到端解决方案： - **Cloud Interconnect** ([Direct](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/dedicated-overview) 、[Partner](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/partner-overview) 、[Cross-Cloud](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cci-overview)) - 用于从您的本地或其他云连接到中转 VPC (transit VPC)。 - [Cloud VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies) - 用于从服务访问 VPC (service-access VPC) 连接到中转 VPC，并从私有服务访问网络导出自定义路由。 - **VPC 网络对等互连 (VPC Network Peering)** - 用于从工作负载 VPC 连接到中转 VPC。 - [私有服务访问 (Private services access)](https://cloud.google.com/vpc/docs/private-services-access) - 用于在服务访问 VPC 中私密地连接到托管服务。 - [Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect) - 用于将在托管服务 VPC (managed services VPC) 网络中的服务暴露出来，以便在服务访问 VPC 中使用。 - [网络连接中心 VPC Spoke (Network Connectivity Center VPC spokes)](https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-spokes) - 在必要时允许工作负载 VPC 之间进行通信。 要了解更具体的细节，如路由交换和数据包流，请阅读完整的架构文档参考指南：[使用 VPC 网络对等互连的跨云网络 VPC 间连接](https://cloud.google.com/architecture/ccn-distributed-apps-design/ccn-vnp-vpn-ra) 。 ### **#2 - 使用网络连接中心 (Network Connectivity Center) 的 VPC 间通信** 在这个更现代的设计中，我们使用网络连接中心 (Network Connectivity Center) 以及星型配置和互连 Spoke。为了理解在这种配置下如何思考网络设计，让我们来看一个数据包从 **外部网络** 流向位于 **工作负载 VPC 1** 中的应用的流程。 该网络由 **外部网络** (本地和其他云) 和 **Google Cloud 网络** (中转 VPC、服务访问 VPC、托管服务 VPC、Private Service Connect 消费者 VPC 和工作负载 VPC) 组成。  该设计使用以下服务来提供端到端解决方案： - **Cloud Interconnect** (Direct、Partner、Cross-Cloud) - 用于从您的本地或其他云连接到中转 VPC。在这种情况下，多个外部位置在不同区域进行连接。 - **Cloud VPN** - 用于从服务访问 VPC 连接到中转 VPC，并从私有服务访问网络导出自定义路由。 - **VPC 网络对等互连 (VPC Network Peering)** - 用于从工作负载 VPC 连接到中转 VPC。 - **私有服务访问 (Private services access)** - 用于在服务访问 VPC 中私密地连接到托管服务。 - **Private Service Connect** - 用于将在托管服务 VPC 网络中的服务暴露出来，以便在服务访问 VPC 和 Private Service Connect 消费者 VPC 中使用，并通过端点向已连接的对等方提供服务。 - **网络连接中心 VPC Spoke (Network Connectivity Center VPC spokes)** - 在必要时允许工作负载 VPC 之间进行通信。 - **网络连接中心拓扑 (Network Connectivity Center topology)** - 利用预设的拓扑 (根据您的需求选择 [网格拓扑 (mesh)](https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#mesh-topology) 或 [星型拓扑 (star)](https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#star-topology) )。 要了解具体细节，例如网络连接中心的星型拓扑、路由交换和数据包流，请阅读完整的架构文档参考指南：[使用网络连接中心的跨云网络 VPC 间连接](https://cloud.google.com/architecture/ccn-distributed-apps-design/ccn-ncc-vpn-ra) 。  ### **后续步骤** 深入了解网络迁移支持和跨云网络 (Cross-Cloud Network)。 - 文档：[用于分布式应用的跨云网络 (Cross-Cloud Network)](https://cloud.google.com/architecture/ccn-distributed-apps-design) - 文档：[为迁移企业工作负载设计网络：架构方法](https://cloud.google.com/architecture/network-architecture) 想要提问、了解更多信息或分享想法？请通过 [Linkedin](https://www.linkedin.com/in/ammett/) 与我联系。 发布于 - [网络](https://cloud.google.com/blog/products/networking) - [开发者与实践者](https://cloud.google.com/blog/topics/developers-practitioners) <!-- AI_TASK_END: AI全文翻译 -->