Google PCD: 云原生应用架构与服务选择 — 学习指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

概述

Google Cloud 上的云原生应用架构专注于构建无状态、有弹性的服务，这些服务可以水平扩展、最大限度地减少运维负担，并在适当的情况下采用托管服务。有效的服务选择需要理解在控制权、可移植性、性能、成本和运维责任之间的权衡。本节介绍的原则和模式可帮助您为全球用户设计、现代化和运维具有可预测可靠性的应用程序。

云原生原则和架构选择

十二要素（Twelve-factor）和无状态设计
- 代码库、依赖项和构建-发布-运行：固定确切的依赖项，创建不可变（immutable）的构件，并将构建与发布分离。容器镜像和 Cloud Build 流水线可强制实现可复现的发布。
- 配置存于环境中：使用环境变量、Secret Manager、Kubernetes Secrets 或 Compute Engine 的实例元数据将配置外部化。不要将凭据或每次部署的特定设置烘焙到镜像中。对于 Compute Engine 托管实例组，使用实例模板元数据来设置每次部署的值。
- 后端服务：将数据库、队列和缓存视为附加资源。优先选择托管服务（Cloud SQL、Cloud Spanner、Firestore、Memorystore、Pub/Sub）以减轻运维负担。
- 无状态进程：通过增加实例进行扩展；将会话状态存储在外部（Memorystore for Redis、Firestore 或 Spanner）。将日志写入由 Cloud Logging 代理收集的 stdout/stderr 或日志文件。
- 易处理性（Disposability）：快速启动/关闭可实现快速扩展和滚动更新。处理 SIGTERM 以实现优雅关闭。
- 日志即事件流：输出结构化日志；使用 Cloud Logging 进行采集，使用 Cloud Monitoring 进行告警。
架构权衡
- 单体（Monolith）
  - 优点：简化的开发/测试，更少的网络边界，单一的部署单元。
  - 缺点：独立交付速度较慢，扩展受限，跨领域紧密耦合。
  - 故障模式：一个热点路径可能会消耗共享资源；回归问题会影响所有功能。
- 模块化单体（Modular monolith）
  - 优点：清晰的内部模块边界，为重构为服务提供了路径，单一可部署单元。
  - 缺点：仍然受到单体部署和数据库的限制。
  - 适用于在提取服务之前，正在成熟其领域边界的团队。
- 微服务（Microservices）
  - 优点：可独立部署，可针对性扩展，团队自治，通过适当的舱壁（bulkheads）模式实现故障隔离。
  - 缺点：分布式系统的复杂性、一致性、可观测性和运维开销。
  - 故障模式：通过同步调用引发级联故障；模式（schema）漂移；网络通信过于频繁（chatty networks）。
- 事件驱动（Event-driven）
  - 优点：松散耦合，异步弹性，天然的缓冲能力，通过日志/流实现的可审计性。
  - 缺点：调试复杂，最终一致性，顺序和“恰好一次”（exactly-once）语义难以实现。
  - Pub/Sub 提供“至少一次”（at-least-once）的交付保证；需要设计幂等的消费者。
- 无服务器（Serverless）（Cloud Run、Cloud Functions、App Engine）
  - 优点：极少的运维工作，可缩容至零，基于请求的自动扩缩容，集成的安全性和遥测。
  - 缺点：执行时间和并发限制，冷启动，特定于平台的约束。
  - 适用于突发性工作负载、移动/Web 后端和事件处理。

通信模式和服务选择

同步与异步调用
- 同步
  - 用于需要立即获得结果的请求/响应式 API。
  - 协议：gRPC（HTTP/2、流式传输、紧凑的 Protobuf；非常适用于移动带宽和强类型合约的场景），HTTP/JSON（广泛的兼容性；更简单的调试）。
  - 风险：紧密耦合和延迟放大；使用超时、带抖动（jitter）的重试和熔断器。
- 异步
  - 当工作可以被推迟或批处理时，使用 Pub/Sub 或 Cloud Tasks。
  - 优点：平滑流量峰值，隔离故障，通过最终完成来改善用户感知的延迟。
  - 风险：需要幂等性和补偿操作；必须构建对处理中工作的可见性。
Google Cloud 上的服务选择标准
- 控制权和可移植性
  - Compute Engine：完全的 VM 控制权和自定义镜像；更高的运维负担。
  - GKE：可移植的容器和服务网格选项；强大的自动扩缩容；共同责任模型。
  - Cloud Run：容器具有高可移植性，运维工作最少；可缩容至零；面向请求。
  - App Engine：自带路由和扩缩容功能的、有明确主张的（Opinionated）PaaS；对于某些语言来说是（上云）最快的路径。
- 规模和延迟
  - 使用带有 Cloud CDN 的全局 HTTP(S) 负载均衡进行边缘加速。
  - 数据存储：
    - Cloud Spanner：全局一致性，水平扩展，多区域 99.999% 可用性。
    - Cloud SQL：托管的关系型数据库，区域性，支持包括跨区域在内的只读副本。
    - Firestore：文档数据库，在多区域模式下具有全球可用性，对单个文档提供强一致性。
    - Cloud Bigtable：适用于宽列场景的低延迟、大规模数据存储。
    - Memorystore：用于热点路径和会话的低延迟缓存。
- 运维责任
  - 对于核心关注点（可用性、补丁、备份、升级），优先选择托管服务。
  - 自我管理提供了灵活性，但增加了运维负担和故障面（例如，自托管的 Kafka 与 Pub/Sub）。
- 数据移动和集成
  - 使用 VPC 原生连接、Private Service Connect 和内部 HTTP(S) 负载均衡以实现低延迟的私有访问。
  - 服务发现：集群内的 Kubernetes Service 名称；用于 VM 的 Compute Engine 内部 DNS。

Kubernetes Service 示例（集群内名称发现）： apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

port: 80 targetPort: 8080 type: ClusterIP

全球化和运维考量

面向全球用户的多区域模式
- 全球前端：使用具有任播 (anycast) IP 的全球外部 HTTP(S) 负载均衡，并为静态内容使用 Cloud CDN。配置否定缓存和验证以减少源站负载。
- 数据平面：
  - 为实现五个九 (99.999%) 的数据库可用性并最小化全球读取延迟，请使用多区域 Cloud Spanner 实例（例如，nam-asia-eur1），并为计算和仲裁 (quorum) 预配足够的节点（生产环境至少三个节点）。
  - 对于没有严格全球一致性要求的读取密集型模式，可考虑采用区域主实例加跨区域只读副本的方案；接受跨大洲更高的写入延迟。
- 应用平面：
  - 在多个区域部署具有自动扩缩功能的无状态服务（GKE 或 Cloud Run）。每个区域使用后端服务和网络端点组。
  - 在遵守数据驻留和合规性约束的前提下，按延迟进行路由。
- 缓存：将 Memorystore 或边缘缓存放置在靠近用户的位置，以吸收读取流量并保护源站。
托管与自管理
- 使用 Cloud Monitoring 获取指标，Cloud Logging 获取日志，Cloud Trace/Profiler 分析延迟和 CPU/内存热点。为 SLO 消耗速率创建告警策略，并为外部可用性创建正常运行时间检查。
- 如果必须保留现有的可观测性平台作为权威数据源 (system of record)，请先使用 Cloud Logging 采集数据以实现低延迟告警，然后通过接收器 (sinks) 导出到外部平台。
现代化与增量迁移
- 绞杀者模式 (Strangler pattern)：用网关代理单体应用；将特定端点路由到新服务。逐步替换功能。
- 按抽象分支 (Branch by abstraction)：围绕一个依赖项引入一个接口，并在其后替换实现（例如，数据库或存储）。
- 防腐层 (Anti-corruption layer)：在旧数据模型和新的限界上下文之间进行转换。
- 数据迁移：使用带验证的双写或事件溯源 (event sourcing) 来回填数据；规划带有反压控制的切换方案。
- 分阶段交付：分阶段替换功能以最小化业务风险；持续衡量 SLO。
设计评审与权衡评估
- 安全性：威胁建模，IAM 最小权限原则，使用服务账号而非嵌入式密钥（在 GCE/GKE/Cloud Run 上使用应用默认凭据），在需要时使用 CMEK，私有连接，WAF 和速率限制，漏洞和 Web 安全扫描。
- 可靠性：定义 SLO 和错误预算，多区域故障切换计划，容量余量，混沌演练，依赖关系图。
- 性能：长尾延迟分析，在边缘和源站进行负载测试，连接复用 (HTTP/2, gRPC)，压缩，缓存策略。
- 成本：合理调整资源规模，自动扩缩策略，承诺使用折扣，为突发性工作负载实现缩容至零，出站流量和 CDN 卸载。
- 运维：运行手册 (Runbooks)，回滚，渐进式交付（金丝雀、蓝绿部署），策略即代码 (policy as code)，备份和灾难恢复测试，事件响应集成。

实际问题场景

Nimbus Retail 正在推出一个全球电子商务平台，该平台具有个性化图片功能，要求全球 p95 延迟低于 200 毫秒，并且订单数据库的可用性要求为 99.999%。他们还必须在提高告警速度的同时，保留现有的 SIEM 系统。

使用 Cloud Spanner 建立一个全球性的高可用数据库

操作：在 nam-asia-eur1 中创建一个多区域 Spanner 实例，至少包含三个节点，并将表拆分为适当的交错 (interleaved) 模式以实现局部性。
理由：多区域 Spanner 通过在三大洲的副本提供五个九的可用性和低读取延迟；三个或更多节点可确保足够的计算和副本仲裁 (quorum) 容量。

示例：

undefined

全球化部署前端和 API

操作：使用全球外部 HTTP(S) 负载均衡，为静态资产启用 Cloud CDN，并为到区域后端（位于 us-central1, europe-west1, asia-east1 的 GKE 服务）的请求提供动态路由。
理由：任播 (Anycast) VIP 最小化了 RTT；CDN 将图片缓存在用户附近；后端服务将请求分发到最近的健康区域。

在 GKE 上部署无状态服务并实现集群内发现

操作：在 GKE 上部署图片缩放和 API 服务，配置 Pod 水平自动扩缩 (horizontal pod autoscaling) 和 ClusterIP Service 以实现集群内基于名称的访问；通过 Ingress 暴露公共端点。
理由：无状态 Pod 允许弹性伸缩；Kubernetes Service 抽象了 Pod IP 并提供稳定的 DNS，从而降低客户端耦合。

事件驱动的图像处理

操作：将图像处理任务发布到 Pub/Sub；运行通过推送 (push) 订阅的 Cloud Run 服务来处理存储在 Cloud Storage 中的对象。对 GCS 的 429/5xx 错误实施带抖动 (jitter) 的截断指数退避 (truncated exponential backoff)。
理由：Pub/Sub 可缓冲流量尖峰并隔离故障；Cloud Run 按消息进行扩缩；退避机制可减少错误放大效应并帮助存储桶逐步预热。

可观测性与快速告警

操作：使用 Cloud Logging 和 Cloud Monitoring 采集日志和指标，为 API 定义正常运行时间检查，并根据错误率和延迟创建告警策略。配置一个日志接收器 (log sink) 以导出到现有的 SIEM。
理由：原生遥测提供低延迟告警和托管的正常运行时间检查；导出功能在不牺牲告警速度的情况下保留了集中的 SIEM。

外部化配置与密钥

操作：将非敏感配置存储在 ConfigMaps 中；将密钥和 API 密钥存储在 Secret Manager 中，并为 GKE 使用 Workload Identity。对于任何基于 Compute Engine 的作业，使用实例元数据来传递每个部署特定的值。
理由：外部化配置支持不可变镜像和环境特定设置；避免嵌入密钥；元数据无需更改代码即可支持虚拟机差异。

故障隔离与优雅降级

操作：使用独立的节点池为尽力而为 (best-effort) 的个性化工作负载应用隔舱 (bulkheads) 模式；为个性化服务强制执行请求预算和熔断器 (circuit breakers)。在 UI 中，当依赖项超时时，省略非关键的小组件。
理由：隔离容量可防止尽力而为的功能耗尽结账流程的资源；熔断器可限制爆炸半径；优雅降级可保留核心用户旅程。

API 契约与兼容性

操作：为移动客户端 (v1) 定义 gRPC 契约，并为 Web 提供 HTTP/JSON 转码；采用增量式变更，并在移动端发布期间至少维护两个版本。
理由：gRPC 减少了带宽并提供强类型；转码简化了浏览器和合作伙伴的集成；版本控制保留了向后兼容性。

安全与身份

操作：每个服务使用一个遵循最小权限 IAM 原则的 Google 服务账号；依赖应用默认凭据 (Application Default Credentials)。为边缘防护启用 Cloud Armor，并强制全程使用 TLS。
理由：Workload Identity 消除了密钥管理的风险；WAF 和速率限制可缓解滥用行为；传输中加密是默认且强制的。