Google PCA: 计算、应用平台与工作负载架构 — 学习指南

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

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

概览

该领域涵盖了如何在 Google Cloud 上选择和设计计算平台，如何打包和部署应用，以及如何运维工作负载以实现可靠性、高性能、安全性和成本效益。它涉及虚拟机、Kubernetes、无服务器运行时、负载均衡、发布策略、有状态和专用计算，以及在满足不断变化的需求的同时减少技术债务的现代化模式。

Compute Engine 和基于虚拟机的架构

Compute Engine 提供了对操作系统、网络和机器形态的精细控制。根据工作负载的特性选择机器系列：

• E2：成本优化的通用型；适用于开发/测试、突发性应用。
• N2/N2D：为大多数生产工作负载提供了均衡的性价比；N2D 使用 AMD CPU，具有强大的内存带宽。
• C2/C2D/C3：计算优化型，适用于 CPU 密集型任务（例如，高 QPS 的 API、批处理计算）。
• M3：内存优化型，适用于大型内存数据集（例如，缓存、内存分析）。
• A3：GPU 优化型 (NVIDIA)，适用于训练/推理；也可以将 GPU 挂载到其他机器系列。
• Confidential VM（在支持的 CPU 上）能以最少的代码更改来加密使用中的数据。

代管实例组 (MIG) 可带来弹性和韧性：

• 使用实例模板 (Instance Templates) 实现不可变配置，并使用 MIG 在多个可用区之间进行水平扩缩。
• 自动扩缩政策：可基于 CPU、负载均衡器利用率、Cloud Monitoring 指标或通过自定义指标衡量的队列深度。设置最小/最大副本数和冷却时间，以避免在突发负载下发生抖动。
• 滚动更新和 Canary 发布可降低风险；对于有状态或冷启动密集型服务，请保守设置浪涌 (surge) 和不可用 (unavailable) 的数量。

负载均衡和健康检查：

• 全球外部 HTTP(S) 负载均衡器可终止 TLS、支持 URL 映射，是 Web API 的标准前端；内部 HTTP(S) LB 用于东西向流量。
• 健康检查必须能够访问后端。一个常见的故障是探测被阻止，导致实例不断重启和流量丢失。应使用 VPC 防火墙规则和目标标记，允许健康检查的源 IP 范围访问后端端口。

允许 HTTP 健康检查访问 MIG 的示例：

undefined

虚拟机生命周期注意事项：

• 使用启动脚本或镜像元数据进行引导；将运行时配置存储在 Secret Manager 中，而不是固化到镜像里。
• 对于 Preemptible/Spot VM，添加一个关闭脚本 (shutdown-script)，以便在收到终止通知时排空工作。
• 通过固化补丁到镜像中并进行滚动替换的方式来打补丁，以避免配置漂移。
• 永久性磁盘 (Persistent disk) 的大小调整可在线进行：先增加磁盘大小，然后在文件系统上扩容（例如，在 ext4 上使用 resize2fs），停机时间极短。

永久性磁盘大小调整示例：

undefined

undefined

安全身份和可观测性：

• 为实例挂载最小权限的服务账号 (service accounts)；不要嵌入静态凭据。
• 安装 Ops Agent 以使用 Cloud Logging 和 Cloud Monitoring。使用 Cloud Trace 和 Cloud Profiler 来减少尾延迟和发现热点。
• 将审计和指标数据导出到 BigQuery 或 Cloud Storage 进行长期保留和分析。

批处理和专用计算：

• 使用 Cloud Batch 或带有 Preemptible VM 的 MIG 来执行容错批处理以降低成本；实现检查点机制。
• 在需要机器学习加速的地方挂载 GPU/TPU。使用专用节点池或单租户节点 (sole-tenant nodes) 来满足合规性/隔离要求。
• Confidential VM 保护内存中的敏感数据；衡量其开销与实际需求。

状态注意事项：

• 保持应用实例无状态；将会话外部化到共享存储（例如 Memorystore、Cloud SQL），以避免在扩缩容时出现用户可见的异常。
• 对于绑定到虚拟机的状态，使用区域级永久性磁盘或复制型数据库；测试故障切换路径。

Kubernetes 和容器平台 (GKE)

GKE 提供托管的控制平面和灵活的工作节点池：

• 区域级集群跨可用区复制控制平面和节点以实现高可用性；可用区级集群集中资源以降低成本并满足延迟敏感性需求。
• 使用多个节点池来分段工作负载（例如，通用型、GPU、高内存、Spot）。应用污点/容忍 (taints/tolerations) 和亲和性/反亲和性 (affinity/anti-affinity) 来控制调度并减少“吵闹邻居”效应。
• 自动扩缩层级：集群自动扩缩器 (cluster autoscaler) 增删节点；Horizontal Pod Autoscaler (HPA) 基于 CPU/自定义指标扩缩副本数量；Vertical Pod Autoscaler (VPA) 调整请求的资源大小。将 HPA 与集群自动扩缩器结合使用以实现弹性。

工作负载调度和服务：

• 合理设置 CPU/内存的请求/限制 (requests/limits) 大小，以最小化驱逐风险并最大化装箱效率 (binpacking)。
• 使用 PodDisruptionBudgets 在升级期间保持可用性。
• 服务类型：ClusterIP（集群内）、NodePort/LoadBalancer（南北向）以及用于通过全局 LB 进行 HTTP(S) 路由的 Ingress。对于金丝雀部署，可通过独立的服务/Ingress 后端或服务网格来引导流量。

升级和弹性：

• 使用 surge upgrades 和 maxUnavailable 来控制变更频率；将关键工作负载固定到多个可用区和节点池。
• 为业务关键时期设置维护窗口/排除时段。
• 在广泛推广前，使用预生产环境和金丝雀节点池进行验证。

镜像和安全：

• 将容器镜像存储在 Artifact Registry 中；启用漏洞扫描并设置二进制文件授权 (binary authorization) 或来源证明 (attestations)。
• 使用 Workload Identity 将 GSA 映射到 KSA，以实现对 Google API 的无凭证、最小权限访问。
• 通过 CSI 驱动程序从 Secret Manager 拉取运行时配置；除非使用 CMEK 加密且 RBAC 权限收紧，否则避免将高度敏感的值存储在 Kubernetes Secrets 中。

发布和回滚：

• 首选采用小步长和健康探针的 Deployment 滚动更新；对于低容错系统，可通过单个 Service 背后的两个 Deployment 实现蓝绿部署，并通过切换标签/选择器来切换流量。
• 务必定义就绪探针 (readiness probe) 和存活探针 (liveness probe)；配置错误的探针会在发布期间导致级联重启或流量黑洞。

无服务器和事件驱动平台

Google Cloud 无服务器平台抽象了基础设施，同时在规模、安全和成本方面提供了强大的控制能力：

• Cloud Run：容器原生，由 HTTP 请求或 Eventarc 触发。可缩容至零；并发数可配置；可按修订版本拆分流量以实现金丝雀部署和回滚。为延迟敏感的端点设置最小实例数以减少冷启动。通过 Serverless VPC Access 与 VPC 集成以实现私有出站流量。
• App Engine：定制化 PaaS。标准环境 (Standard) 提供快速扩缩和针对不同语言的单请求并发约束；灵活环境 (Flexible) 在 VM 上运行容器，提供更多控制权。避免使用实例本地会话状态；将其外部化到共享存储，以防止在高负载下出现过时或重复的用户体验。
• Cloud Functions：用于事件驱动逻辑的函数级粒度。使用 Pub/Sub、Cloud Storage 或 Eventarc 触发器执行轻量级微操作；保持函数幂等和无状态。对于没有现有代码的批处理/流处理组合管道，Dataflow 提供带自动扩缩的统一处理能力。

平台选择权衡：

身份和配置：

• 每个服务都应使用具有最小权限的专用服务账号。对于 Cloud Run 和 Functions，需明确设置运行时服务账号。
• 将密钥存储在 Secret Manager 中，并通过 IAM 绑定访问权限；通过环境变量或卷挂载注入。

架构模式、交付与运维

服务分解与边界：

• 单体架构 (Monolith): 部署和事务最简单，但限制了独立扩展和爆炸半径控制；可能会掩盖调用链深处的性能问题。
• 模块化单体 (Modular monolith): 清晰的内部模块，共享进程；一个很好的过渡步骤——在没有分布式开销的情况下强制执行接口。
• 微服务 (Microservices): 可独立部署和扩展；引入了网络延迟、分布式事务和一致性挑战。定义清晰的限界上下文和数据所有权；避免共享数据库以防止耦合。

现代化改造模式：

• 绞杀者模式 (Strangler-fig): 增量地将一部分流量路由到新组件，逐步淘汰旧的端点。
• 直接迁移 (Lift and shift): 首先进行容器化或虚拟机迁移以稳定系统，然后再进行重构。
• 防腐层/外观模式 (Anti-corruption layer/facade): 在构建新服务的同时，隔离旧系统的契约。
• 优先处理高变化、高摩擦的领域，以最大化业务价值并降低风险。

交付与部署：

• 带有自动化测试和分阶段环境的 CI/CD 可以减少回滚。增加金丝雀分析、错误预算和渐进式交付。
• 蓝绿部署 (Blue-green) 以双倍容量为代价，最大限度地减少停机时间并简化回滚。
• 流量拆分 (Traffic splitting): Cloud Run/App Engine 支持在不同修订/版本之间进行基于百分比的路由；在真实流量下使用严格的 SLO 错误预算进行测试。

负载均衡与健康状况：

• 对 HTTP 使用全局 L7 负载均衡器，对非 HTTP 协议使用 TCP 代理；对私有服务使用内部负载均衡器。仅在必要时配置会话亲和性，并将会话状态外部化。
• 健康检查应反映应用的真实可用性（例如，依赖项的健康状况）；一个简单的 200 OK 可能会掩盖数据存储故障，从而导致错误的流量导向。

可观测性与治理：

• 为跨服务的端到端延迟归因检测链路追踪 (traces)；启用请求 ID 日志记录，以关联日志和追踪。
• 将日志/指标/审计跟踪导出到 BigQuery 或 Cloud Storage 以满足保留和审计需求；通过视图和 IAM 保护访问安全。
• 对于虚拟机日志，安装 Ops Agent；定义保留策略和接收器 (sinks) 以控制成本和合规性。

安全软件供应链：

• 使用带有扫描功能的 Artifact Registry；保持镜像最小化。优化 Dockerfile：优先使用 slim 基础镜像，先安装依赖项，然后复制源代码以利用构建缓存。

网络与分段：

• 通过 VPC 防火墙标签和规则强制执行分层访问，仅允许预期的流量（例如，Web → API → DB）。拒绝 Web 直接访问 DB。

容量、性能和专用计算

为可变需求进行设计：

• GCE：基于前瞻性指标（如队列长度）对 MIGs 进行自动扩缩，以避免 CPU 饱和；添加请求速率限制和背压机制以保护下游服务。
• GKE：结合基于每秒请求数 (RPS) 或自定义指标的 HPA 与集群自动扩缩器；预置一个小型缓冲区以避免扩缩延迟。
• Serverless：调整并发度和最小实例数，以平衡成本与延迟；使用区域级部署以实现靠近用户的低延迟。

弹性和测试：

• 运行综合负载以验证自动扩缩和 SLO；引入混沌测试（例如，随机终止实例/Pod），以确保系统在故障和升级期间保持可用性。
• 配置 PodDisruptionBudgets 和优雅终止钩子，以在 Pod/VM 关闭前排空连接。

性能和存储选择：

• 高吞吐、低延迟的时间序列和点击流数据注入非常适合使用 Bigtable；设计宽行和按时间分桶的键以避免热点。
• 对于希望最小化运维变更的 Spark/Hadoop，使用 Dataproc；通过自动扩缩合理调整集群规模。
• 对于没有现有代码、需要结合小时级批处理和流处理的场景，使用 Dataflow，通过自动扩缩和窗口化来统一流水线。

数据迁移和连接：

• 对于持续、高带宽、私密的复制（例如，数 TB 的数据库），考虑使用 Dedicated Interconnect；使用 VLAN attachments 和 Cloud Router 实现动态路由。对于临时或较低吞吐量的场景，Cloud VPN 已足够。

有状态工作负载：

• 在 GKE 上，使用带有持久卷（为实现高可用性可使用区域级 PD）和有序、稳定身份标识的 StatefulSets；若需 NFS 语义，可考虑使用 Filestore。
• 尽可能使用托管数据库（Cloud SQL、AlloyDB、Spanner）以获得持久性和扩展性；规划只读副本和故障转移。

安全与合规：

• 考虑使用 Confidential VMs 来保护使用中的数据，其性能开销有限；根据工作负载要求进行评估。
• 在密钥必须由客户控制的场景下使用 CMEK；强制执行按环境隔离，并为开发/测试/生产环境使用独立的项目。

成本控制：

• 对稳态计算资源使用承诺使用折扣和持续使用折扣；对容错的批处理任务使用可抢占/Spot 实例；在 Serverless 平台上实现自动缩容至零。
• 根据 Monitoring 的建议合理调整资源规模；移除空闲服务并设置基于日志的指标配额，以避免意外成本。

延迟问题排查：

• 使用 Cloud Trace 识别造成延迟最大的微服务；优化该服务的代码路径、缓存或数据库索引。通过 A/B 金丝雀发布验证改进效果。

实际问题场景

FerroLine Logistics 计划对一个处理货运跟踪和客户通知的 J2EE 单体应用进行现代化改造。该工作负载在区域截单期间呈突发性，必须满足 99.9% 的可用性目标，并且团队希望在引入事件驱动功能的同时，实现可移植性且运维负担最小。

1. 稳定并观察现有系统

• 理由：在进行变更前，建立行为和错误的基线，以降低回滚风险。在现有 VM 上部署 Ops Agent 以接入 Cloud Logging 和 Monitoring，并在高延迟请求路径中注入分布式追踪。将日志和指标导出到 BigQuery，用于历史分析和 SLO 报告。

2. 选择分阶段的落地环境和平台组合

• 理由：平衡控制力与开发速度。将单体应用作为容器迁移，其中批处理组件使用 Cloud Run 作业，无状态 HTTP API 使用 Cloud Run 服务，并为延迟敏感的端点设置最小实例数。初期将有状态的 Oracle 数据库保留在 Compute Engine 上，前端由一个区域级内部 HTTP(S) 负载均衡器为内部 API 提供服务，并计划未来迁移到 AlloyDB。

3. 外部化会话和配置状态

• 理由：避免实例本地会话问题，并实现安全的自动扩缩。将密钥存储在 Secret Manager 中，并为每个服务配置独立的服务账号以实现最小权限访问。将会话状态迁移到 Memorystore，共享文件迁移到 Cloud Storage。这可以防止用户在峰值负载下看到陈旧数据。

4. 建立身份和镜像仓库控制

• 理由：强制执行最小权限和来源追溯。将镜像存储在启用了漏洞扫描的 Artifact Registry 中。为每个 Cloud Run 服务和 GKE 工作负载（用于后续分解的组件）分配唯一的运行时服务账号，并仅授予所需角色（例如，Pub/Sub Publisher）。

5. 实施具备安全发布策略的 CI/CD

• 理由：减少意外回滚。构建一个运行单元/集成测试并部署到预发环境的流水线。使用 Cloud Run 的流量切分功能，将 5–10% 的流量进行金丝雀发布到新版本，并支持快速回滚。对于基于 VM 的数据库变更，使用蓝绿模式的数据库模式迁移策略，以解耦应用和数据库的部署。

6. 优先分解高频变更的领域

• 理由：以较低风险实现增量价值。应用绞杀者模式：将通知分发功能剥离为一个 GKE 上的微服务，以利用 HPA 处理流量尖峰，并使用 Pub/Sub 进行解耦。在接口稳定之前，将剩余的单体应用作为模块化单体保留在 Cloud Run 上。

7. 设计自动扩缩和负载削减

• 理由：在不引发级联故障的情况下处理突发流量。为每个端点配置 Cloud Run 的并发度和最小实例数；在全局 HTTP(S) 负载均衡器上设置 Cloud Armor 速率限制，以防范未经身份验证的流量激增。对于 GKE 服务，启用基于自定义指标（每秒请求数）的 HPA，并通过集群自动扩缩器预置一个小型节点缓冲区。

8. 准备有状态服务和数据路径

• 理由：确保持久性和性能。对于 GKE 上的通知重试机制，使用一个以客户-区域和时间桶为主键的 Bigtable 表，以高写入速率存储瞬时投递状态。在过渡期间，为实现与本地 ERP 系统的私密、一致连接，使用带有 Cloud Router 的 Dedicated Interconnect。

9. 执行弹性和性能测试

• 理由：在完全切换前验证 SLO。运行综合、随机的用户流程以触发各层自动扩缩。通过随机终止 Cloud Run 实例（让控制平面重新创建）和驱逐 GKE Pod 来注入混沌，以验证 PodDisruptionBudgets 和就绪探针。使用 Trace 识别造成尾部延迟的最大因素并进行修复。

10. 在成本和合规护栏下进行运维

• 理由：在生产环境中可持续地运行。设置按服务的预算和告警，在需要时为敏感存储启用 CMEK，并在稳态负载被确定后，为 GKE 节点池和 AlloyDB 使用承诺使用折扣。配置日志保留策略和 BigQuery 视图，以便安全地与内部审计员共享审计数据。

这种分阶段的方法提供了即时的稳定性和可观察性，引入了安全的部署实践，沿着自然的服务边界逐步分解单体应用，并使平台选择与控制、延迟、可移植性、扩展性和成本目标保持一致。

← 组织设计、IAM 与云治理 · 所有领域 · 数据存储、数据库与分析架构 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →