Google PCA: 网络、混合连接与流量架构 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

属于 Google Professional Cloud Architect — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 上的网络、混合连接和流量架构围绕以下核心构建：安全、可扩展的虚拟私有云 (VPC) 设计；可靠的混合互连；智能的流量管理；以及强大的可观测性。其目标是交付低延迟、高弹性的服务，并具备清晰的分段、受控的出口和可预测的故障模式。本节概述了跨 Google Cloud 核心网络服务的实用设计模式、权衡取舍以及操作指南。

VPC 架构与分段

地址规划与子网
- 使用自定义模式 VPC 来控制子网创建和 IP 地址分配。在生产环境中避免使用默认 VPC。
- 尽早分配不重叠的 RFC1918 地址块。考虑未来的增长、高可用性拓扑和混合扩展。为服务（例如 Private Service Connect 端点）和对等互连/Interconnect 预留地址范围。
- 优先选择按功能或按环境划分的较小子网，而不是大型扁平网络，以最小化故障爆炸半径并简化防火墙配置。
路由
- 每个 VPC 都有一个系统路由表；路由按最长前缀匹配然后按优先级进行评估。Google 管理的路由包括在存在外部 IP 时的默认互联网路由以及子网路由。动态路由通过 Cloud Router 与本地数据中心交换。
- 谨慎使用自定义静态路由；尽可能依赖动态路由以实现弹性。除非作为有意的控制手段，否则避免使用黑洞路由。
防火墙规则
- VPC 防火墙是有状态的，按优先级进行评估，并在末尾有隐式拒绝规则。通过网络标签或服务账号来指定目标；与标签相比，使用服务账号作为目标能提供更强的身份保证。
- 按用途（健康检查、层内通信、管理）分离允许规则，并将其范围限定在源服务账号或 IP 范围。
- 将关键规则的防火墙决策记录到 Cloud Logging，以帮助进行问题取证和性能分析。
分层防火墙策略和组织策略
- 分层防火墙策略应用于组织或文件夹级别，并在 VPC 级规则之前进行评估。使用它们来设置全局护栏（例如，拒绝 0.0.0.0/0 的 SSH 访问），项目无法覆盖这些护栏。前置和后置策略提供了灵活性，但在更高层级设置的拒绝规则无法被取代。
- 通过组织策略约束（例如，限制创建外部 IP、禁止项目创建 VPC 对等互连）作为补充，以强制执行治理。
共享 VPC 与分段
- 使用共享 VPC 将网络集中在宿主项目中，同时将工作负载隔离在服务项目中。这种模式可以减少重复的出口路径、标准化控制措施并简化混合中转。
- 在不同的宿主项目或文件夹中隔离环境（生产、非生产）；通过分层策略和独立的子网来强制分段。限制 IAM 权限，以便只有网络运维团队才能管理宿主项目资源。
VPC 网络对等互连
- 对等互连是私有的、可扩展的、低延迟的，但非传递性的。它最适合用于连接自治网络或第三方管理的服务。避免使用对等互连构建中转枢纽；应使用 Network Connectivity Center 或集中的共享 VPC 来实现中转。
- 限制：不允许 IP 地址重叠；某些路由（例如，默认互联网路由）和一些服务不会被传播。在设计时需要理解自定义路由的导入/导出规则。

权衡与故障模式：

重叠的 IP 范围会阻碍对等互连和混合路由交换；通过重新编号或 NAT 解决。
过于宽松的防火墙规则或缺失健康检查规则会导致服务中断和难以诊断的行为。
静态路由会产生脆弱的依赖关系；优先选择 Cloud Router 以实现故障切换。

流量管理、DNS 和边缘安全

Cloud Load Balancing 模式
- External HTTP(S) Load Balancer 是全局任播，具有单个任播 VIP、跨区域故障转移、路径和主机路由以及 CDN/Armor 集成。用于面向互联网的 Web 和 API 工作负载。
- Internal HTTP(S) Load Balancer 是区域级的，用于 VPC 内部或通过 Private Service Connect 实现的服务到服务的流量。
- External/Internal TCP/UDP Network Load Balancer 是区域级 L4 负载均衡器；用于非 HTTP 协议或需要保留源 IP 的场景。
- 后端服务和网络端点组 (NEG)：对虚拟机池使用可用区级实例组后端；对 GKE、混合后端或 Cloud Run 使用可用区级、区域级或无服务器 NEG。根据流量类别、健康状况配置文件或容量策略创建独立的后端服务。例如：通过路径路由到不同的后端服务，在同一主机名下提供新旧 API 版本，使两者都可独立部署和扩展。
健康检查和常见陷阱
- 防火墙必须允许健康检查。对于外部 HTTP(S) 健康检查，需允许 130.211.0.0/22 和 35.191.0.0/16 访问后端。如果缺少此规则，会导致后端被标记为不健康；若自动扩缩功能对负载均衡器的信号做出反应，则会触发虚拟机的快速重启。
- 将健康检查的路径和端口与容器的就绪端点对齐；设置超时和阈值，以在快速故障转移和误报之间取得平衡。
DNS 架构
- 使用 Cloud DNS 作为权威区域。为内部名称创建私有区域；为互联网名称创建公共区域。
- 分离 DNS (Split-horizon DNS)：通过创建名称相同的独立公共和私有区域，对内部和外部提供不同的应答。这可以安全地支持私有服务主机名和面向公众的记录。
- 转发和对等区域：使用 DNS 策略和服务器策略与本地 DNS 集成，以转发特定域的查询；使用条件转发来避免递归循环。
- 服务发现：为每个环境和服务采用一致的命名约定。对于 GKE，可考虑使用带有 Cloud DNS 的无头服务 (headless services)，或通过 Internal HTTP(S) Load Balancer 和私有 DNS 名称映射服务端点。
边缘缓存和保护
- Cloud CDN 在边缘卸载可缓存内容，从而降低源站延迟和出站流量成本。谨慎设置缓存键、TTL 和否定缓存；对个性化或动态端点绕过缓存。
- Cloud Armor 提供 WAF、速率限制以及基于地理位置/IP 的访问控制。将安全策略附加到负载均衡器；监控规则命中日志。使用预配置规则应对常见 CVE，并使用自定义签名应对特定于应用的威胁。
- 在负载均衡器上进行 TLS 终止可集中管理证书；在可能的情况下，启用自动证书配置和托管续订。

操作指南：

版本化 API：通过基于路径或主机的路由将流量分发到不同的后端服务，以便每个版本都可以通过蓝绿部署或金丝雀模式独立发布。
通过流量导向策略，使用请求标头和 Cookie 进行 A/B 测试；务必验证日志/指标与正确的后端身份相关联。

混合连接、私有访问和中转

Cloud Router 和 BGP
- Cloud Router 通过 BGP 与本地环境动态交换 Cloud VPN 隧道和 Interconnect 连接的路由。当需要多区域分支连接时，请在 VPC 中使用全局动态路由模式。
- 仅通告必要的前缀；进行过滤以防止路由泄漏。在设计主/备路径时，需理解 MED 和优先级之间的相互作用。
Cloud VPN、Dedicated Interconnect 和 Partner Interconnect
- HA VPN 通过 IPsec 提供有 SLA 保证的冗余隧道，支持通过 Cloud Router 进行动态路由，适用于具有中等带宽需求的生产级混合环境。
- Dedicated Interconnect 在一个或多个位置提供物理的 10/100 Gbps 链路；Partner Interconnect 通过服务提供商提供类似服务。为实现高可用性，请至少在不同的城域位置或不同的边缘区域使用两个多样化的互连。
- 冗余路径和故障切换：设计 active/active 模式，在每个区域的两个 Cloud Router 和两个本地路由器之间使用 BGP；验证对非对称路由的容忍度。定期测试故障切换；调整 BFD 计时器和健康阈值以达到期望的收敛速度。
- 故障模式：MTU 不匹配会导致分片和性能下降；确保为 Interconnect 启用端到端的巨型帧。配置错误的路由过滤器可能会导致子网黑洞。单宿主（Single-homed）的合作伙伴线路是常见的单点故障。
Cloud NAT、Private Google Access 和 Private Service Connect
- Cloud NAT 为没有外部 IP 的私有虚拟机提供访问互联网的出口能力。根据峰值连接数规划 NAT IP 和端口分配，以避免端口耗尽；启用日志记录以便于问题排查。
- Private Google Access 允许私有虚拟机使用内部 IP 访问 Google API；在子网上为虚拟机访问启用此功能，并在 GKE 节点上为节点本地 API 访问启用此功能。对于本地客户端，使用 Private Service Connect for Google APIs 来暴露作为 Google API 前端的私有 VIP。
- Private Service Connect for producer/consumer services 为跨项目或跨组织的服务发布提供私有的内部 IP 端点；与私有 DNS 结合使用，可以在不暴露网络的情况下引导流量。
Network Connectivity Center (NCC) 和中转
- NCC 支持中心辐射型（hub-and-spoke）拓扑，其中的分支（spoke）可以是 VPC、HA VPN 或 Interconnect 连接。使用中央枢纽（hub）来简化路由分发和多 VPC 中转，尤其是在跨项目或组织时。
- 当治理策略允许时，优先使用 Shared VPC 进行组织内部的中转；当需要灵活的多域中转或 SD-WAN 集成时，使用 NCC。
- 理解 VPC Peering 是非传递性的；不要依赖它进行中转。NCC 或集中的防火墙/负载均衡器 VPC 构成中转核心。

多区域选择、延迟和出口成本：

将计算资源部署在靠近用户和有状态后端的位置，以最小化 RTT。External HTTP(S) Load Balancing 提供具有智能路由的全局入站流量，但数据库复制延迟和一致性仍然是应用程序层面的限制。
可用区之间的流量在区域内会产生费用；跨区域复制会增加出口费用和延迟。使用 Cloud CDN 来减少互联网出口流量和源站负载，并将通信频繁的服务部署在同一位置。
对于灾难恢复，需权衡在另一区域部署温备（warm standby）方案所带来的出口费用和运维复杂性。仅当数据平面和控制平面能够容忍区域隔离时，才使用带有跨区域故障切换策略和健康检查的全局负载均衡。

可观测性、可靠性运营和控制

网络可观测性
- VPC Flow Logs：在子网级别启用，并调整采样和元数据选项。用于流量基线分析、出站流量分析和威胁狩猎。导出到 BigQuery 进行长期分析。
- Firewall rules logging：在关键规则上启用，以捕获允许和拒绝的流量；与流日志关联以检测配置错误。
- Connectivity Tests：对源-目标路径建模，以验证可达性、路由选择和防火墙评估。集成到 CI/CD 中，在部署前检测配置漂移。
- 健康状况仪表板：监控负载均衡器后端健康状况、Cloud NAT 端口利用率、Cloud Router BGP 会话状态和 Interconnect 利用率。对偏差进行告警。
可靠性模式和常见故障模式
- 可用区级弹性：将后端分布在至少两个可用区；使用托管实例组或多可用区 GKE 节点池。验证健康检查和防火墙标记是否应用于所有可用区。
- 路由弹性：使用全局动态路由和多个 Cloud Router 实现跨区域连接。测试黑洞场景，并确保监控覆盖路由撤销。
- DNS 弹性：使用 Cloud DNS 默认部署多个域名服务器；对于混合环境，确保转发器是冗余的，并避免本地解析器中的单点故障。防止分离-水平（split-horizon） DNS 配置错误从错误的一侧返回不可路由的应答。
- 边缘安全：应用 Cloud Armor 速率限制以保护源站免受洪水攻击；否则可能引发自动扩缩容风暴和成本飙升。
成本控制
- 最小化跨区域调用，对于 VPC 内部流量优先使用内部负载均衡，并考虑为生产者-消费者流量使用 PSC 以避免 NAT 出站。
- 对静态和半静态资产使用 Cloud CDN；调整可缓存性。合理规划 Interconnect 容量以避免为闲置余量支付过高费用；使用流量数据来合理调整承诺用量。

操作片段：

允许负载均衡器的健康检查访问私有后端：
- gcloud compute firewall-rules create allow-lb-hc –network=prod –action=ALLOW –direction=INGRESS –rules=tcp:80,tcp:443 –source-ranges=130.211.0.0/22,35.191.0.0/16 –target-service-accounts=backend-sa@project.iam.gserviceaccount.com
在子网上启用 Private Google Access：
- gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access
为 HA VPN 创建一个 Cloud Router：
- gcloud compute routers create cr-us-central1 –region=us-central1 –network=prod –asn=64514

实际问题场景

Contoso Retail 计划推出一个全球电子商务 API，要求实现零停机版本控制、与后台办公系统的严格私有连接，并且应用虚拟机上无公共 IP。该解决方案必须提供 DDoS 保护、边缘缓存以及来自两个数据中心的可靠混合访问。

方法：

设计 VPC 和分段

创建一个自定义模式的 Shared VPC 宿主项目，在两个区域中为每个层级（web、api、data）设置专用子网。理由：Shared VPC 集中了控制，而服务项目隔离了团队。按层级划分的子网能够实现最小权限防火墙和更小的故障域。
在组织级别应用分层防火墙策略，以拒绝来自互联网的入站 SSH，并将出站流量限制在允许的目的地。理由：全局护栏降低了项目中配置错误的风险。

实现基于路径的全局入站和 API 版本控制

部署一个外部 HTTP(S) 负载均衡器，使用单个任播 IP 和 HTTPS 终止。配置 URL 映射，将 /v1/* 和 /v2/* 路由到由区域级 zonal NEG 支持的独立后端服务。理由：独立的后端服务允许在同一个主机名和 TLS 证书下，对每个 API 版本进行独立的部署和回滚。
附加 Cloud Armor WAF 和速率限制；为可缓存的端点（例如，产品图片）启用 Cloud CDN。理由：保护源站，并降低延迟和出站成本。

确保后端可达性和健康状况

创建一条防火墙规则，允许负载均衡器的健康检查访问 API 实例组的预期端口。理由：如果没有这条规则，健康检查会失败，自动扩缩容器可能会因为实例被视为不健康而发生抖动。
将实例分布在每个区域的两个可用区；保守地设置健康检查阈值以避免状态抖动。理由：可用区多样性和稳定的健康策略可提高可用性。

构建分离-水平（split-horizon） DNS 和服务发现

为 contoso.com 创建一个公共 Cloud DNS 可用区，并为仅限内部的记录（例如，db.internal.contoso.com）创建一个同名的私有可用区。理由：分离-水平 DNS 在保持命名一致性的同时，防止了内部名称的泄漏。
配置 DNS 策略，将本地的 corp.local 查询转发到企业 DNS，并将私有可用区导入到应用项目中。理由：实现跨混合边界的无缝解析，且不会产生递归循环。

建立具有冗余的混合连接

在每个区域，为每个数据中心配置两条 HA VPN 隧道，每对隧道都位于独立的 Cloud Router 上并使用 BGP。如果容量和 SLA 需求合理，可添加 Partner Interconnect，并在独立的边缘可用区中使用冗余连接。理由：多条不同路径提供故障转移；BGP 可实现快速收敛和动态路由交换。
在 Shared VPC 中使用全局动态路由，并应用路由过滤器以防止不需要的本地前缀传播。理由：在实现跨区域一致路由的同时，降低了路由泄漏的风险。

提供对 Google API 和出站互联网的私有访问

在应用子网上启用 Private Google Access，并为批处理作业使用的 Google API 配置 Private Service Connect 端点。在需要时，为非 API 的出站流量使用 Cloud NAT。理由：后端在不持有公共 IP 的情况下仍能访问必要的服务；PSC 通过私有 DNS 简化了名称解析。

集中化中转和第三方连接

在宿主项目中创建一个 Network Connectivity Center hub；连接 HA VPN、Interconnect 连接点和任何 SD-WAN 分支。理由：与对等网络网格相比，中心辐射型（Hub-and-spoke）中转简化了多个 VPC 和外部网络之间的路由分发。

实施可观测性和护栏

在所有子网上启用 VPC Flow Logs 并设置适当的采样率；在关键防火墙规则上启用日志；将日志导出到 BigQuery。在发布新的防火墙或路由变更之前，在 CI/CD 中使用 Connectivity Tests。理由：深度可见性支持故障排除、容量规划和可审计性。
为 Cloud Router BGP 会话中断、Cloud NAT 端口耗尽、后端健康状况下降和 Cloud Armor 规则命中设置告警。理由：及早发现故障和攻击可降低平均修复时间 (MTTR)。