Google PCD: 性能、可扩展性和弹性工程 — 学习指南

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

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

概述

Google Cloud 上的性能、可伸缩性与弹性工程专注于在可变负载下维持低延迟、高性价比的服务，同时在容忍故障的情况下不违反服务水平目标 (SLO)。设计时必须将自动扩缩容信号与工作负载特征对齐，合理放置数据和计算资源以最小化尾部延迟，并实施过载控制、重试和故障切换机制以避免级联故障。本节详细介绍在计算、网络和数据层面，对应用开发者至关重要的模式、控制措施以及权衡取舍。

扩展与负载分发

水平扩展与垂直扩展

• 水平扩展通过增加实例或 Pod 来提升容量和弹性。对于无状态服务以及需要快速弹性的场景，应优先选用。可使用 Managed Instance Groups (MIGs)、Cloud Run 修订版本或 GKE Deployments。
• 垂直扩展通过增大机器规格来实现。适用于单线程或内存密集型工作负载，或用于减少节点间协调，但其上升空间有限且重启时间较长。
• 并发性：调整请求并发数以匹配 CPU 密集型与 I/O 密集型的工作负载特征。Cloud Run 支持按修订版本配置并发数；如果您的运行时是非阻塞的，GKE Pod 可以处理多个请求；若需严格隔离，可将并发数设置为 1。

自动扩缩容信号与预热容量

• MIG 的自动扩缩容支持基于 CPU 利用率、负载均衡利用率以及通过 Cloud Monitoring 获取的自定义指标。对于突发流量，应基于请求指标（如每秒请求数 rps、队列深度）而非 CPU 进行扩缩容。
• GKE Horizontal Pod Autoscaler (HPA) 可基于 CPU、内存或自定义/外部指标（例如 Pub/Sub 队列长度）进行扩缩容。可使用 Vertical Pod Autoscaler (VPA) 进行规模优化，但应避免在快速扩展的前端上使用 VPA 的实时更新功能，以防抖动。
• Cloud Run 基于并发请求负载进行扩缩容，并可选地支持自定义指标。通过维持预热容量来避免冷启动：配置最小实例数，保持较低的空闲并发数，并在需要时通过合成健康探测进行预热。
• MIG 中的预测性自动扩缩容以及在 Deployment/Revision 上设置最小副本数，有助于在昼夜流量高峰期间掩盖资源预配延迟。

负载均衡、全局流量分发、健康检查与故障切换

• 使用全球外部 Application Load Balancer 以获得全球任播 VIP、HTTP/2 和 HTTP/3 支持，并通过 Cloud CDN 在边缘终止流量。后端可以是实例组、可用区/区域级 NEG、无服务器 NEG (Cloud Run/Functions) 或 GKE Ingress。
• 健康检查可将流量从不健康的后端移开。请确保您的健康检查端点仅对依赖项进行小范围验证（例如，进程和关键本地资源），以避免在下游服务中断时发生循环故障。
• 防火墙允许列表必须允许健康检查程序的流量。如果到 80 端口的检查失败，请允许 Google 的 IP 范围： gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
• 故障切换：配置主/备后端服务或流量策略，在健康检查失败时将流量导向备用区域。对于 DNS 级别的故障切换，可使用带健康检查的 Cloud DNS 策略来处理非 HTTP 端点。

延迟与效率

延迟预算

• 为每一层（客户端、边缘、应用、数据）分配端到端的延迟预算。监控 p95/p99 指标，而非平均值。使用 Cloud Trace 查找跨服务的延迟贡献者和队头阻塞问题。为 RPC 调用设置截止时间，以便上游请求取消时能释放容量。

缓存与 CDN 的使用

• 分层缓存：客户端/浏览器缓存、CDN 边缘缓存 (Cloud CDN) 以及区域级/内存缓存 (Memorystore 或进程内缓存)。谨慎选择缓存键和 vary 标头。根据数据新鲜度要求和陈旧风险设置 TTL；在安全的情况下，可考虑对 404 响应进行否定缓存。
• 从 Cloud Storage 托管静态资产，并置于 Cloud CDN 之后，以减少源站负载和尾部延迟。使用签名 URL/标头进行访问控制。

连接复用

• 优先使用 HTTP/2 或 gRPC 以实现多路复用和标头压缩。启用长连接 (keep-alive) 和连接池以减少握手开销。注意 NAT 端口耗尽问题；调整客户端连接池和空闲超时时间，并在适用时为每个虚拟机分配合适的 Cloud NAT 端口数。

负载效率

• 使用二进制编码（如 protobuf），并对超过一定大小阈值的文本负载进行压缩 (gzip/brotli)。精心设计请求/响应字段；在服务端进行分页和过滤，避免过度抓取数据。使用 ETag 和条件请求 (If-None-Match) 来避免冗余传输。对于 Cloud Storage，使用 generation 前置条件和 Range 读取来获取部分内容。

过载与韧性模式

速率限制、反压、排队和批处理

• 在边缘（使用 Cloud Armor 进行基于 IP/地理位置/服务的速率限制）和 API 层（使用 Apigee 配额、基于 API 客户端的令牌）强制执行速率限制。在服务器端实现令牌桶或漏桶算法以实现公平共享。
• 反压：不要让下游系统不堪重负。使用队列（Pub/Sub 用于至少一次的事件传递；Cloud Tasks 用于具备调度和重试功能的、针对每个队列和每个目标的节流控制）。通过传播 429 Too Many Requests 或带 Retry-After 的 503 向上游客户端施加压力。
• 批处理可以提高吞吐量并减少单次调用的开销（例如，对数据库的批量修改或批量确认 Pub/Sub 消息），以延迟增加为代价换取效率提升。调整批处理大小和最大等待时间。

过载保护

• 为每个 RPC 应用超时和截止时间。使用熔断器来停止向故障依赖项发送工作，并启用快速回退。基于队列深度、CPU 或延迟 SLO 违规实施负载削减，以保护核心功能。

弹性重试、指数退避、抖动、幂等性和重复处理

• 仅在安全时重试：网络超时、5xx 或文档中注明的可重试代码（例如，Cloud Storage 的 429/5xx）。除非有明确规定，否则绝不重试 4xx 错误（如 400/401/403）。
• 使用带抖动的截断指数退避来避免同步重试。首选完全抖动。 示例：

undefined

• 确保幂等性。使用幂等性密钥（例如，唯一的操作 ID）和 upsert/条件写入来容忍重复操作。对于 Pub/Sub，使用 messageId 或应用程序密钥进行去重；将处理程序设计为对“至少一次”的交付模式是安全的。对于 Cloud Storage 写入，使用 generation-match 前置条件来避免覆盖。

休眠资源的预热启动

• 某些服务会强制执行自适应限制。对于 Cloud Storage，应逐步提升先前空闲存储桶的请求速率，以减少突发流量高峰期间短暂的 429/5xx 错误。在满负载之前，通过受控流量对生产者进行节流，并对存储桶进行预热。

高可用性、数据、灾难恢复和测试

多可用区、区域性、多区域；主-主模式 vs 主-备模式

• 跨故障域进行部署。使用区域级 MIG 或区域级 GKE 集群以实现可用区级别的故障容忍。对于全球性服务，使用多个区域并结合全球负载均衡器。
• 主-主模式可降低 RTO 和延迟，但要求数据无冲突并需谨慎管理一致性。主-备模式简化了写入语义，但会产生更高的 RTO 和潜在的冷容量问题。

RTO、RPO、备份、恢复和灾难恢复测试

• 为每个工作负载定义 RTO（恢复服务所需时间）和 RPO（可容忍的数据丢失量）。将其映射到平台能力：
  • Cloud Spanner：多区域，提供五个九的可用性和同步复制，实现近乎为零的 RPO。
  • Cloud SQL：区域内高可用；使用跨区域副本进行灾难恢复，启用 PITR，并验证故障切换/故障恢复操作手册。
  • Firestore 和 Bigtable 提供区域性和多区域选项；根据 RTO/RPO 的要求进行选择。
  • Cloud Storage 的双区域或多区域存储桶提供地理冗余；验证恢复流程和签名 URL 的重新颁发。
• 测试灾难恢复：定期进行故障切换演练。通过在隔离环境中恢复来验证备份，演练 DNS/流量故障切换，并衡量实际的 RTO/RPO。

数据库和存储性能、索引设计、热键和争用

• Cloud Spanner：避免使用可能导致热点的单调递增主键。使用交错表以实现局部性，使用二级索引以适应读取模式，并使用有界事务以减少锁冲突。根据 QPS 和存储量来确定节点规模；为生产环境的仲裁和裕量至少保留三个节点。
• Cloud SQL：分析查询，添加覆盖索引，避免长事务，并使用连接池。审慎地调整 InnoDB 或 Postgres 的设置；为读取密集型工作负载扩展只读副本。
• Bigtable：设计行键以均匀分布负载（例如加盐或字段反转）。如果可用，使用多集群路由以实现跨区域的高可用性。
• Firestore：对多字段查询使用复合索引；注意当大量写入操作针对同一文档路径时可能出现的热点问题。
• Cloud Storage：对新对象提供强读后写一致性；使用并行上传和分块来提高吞吐量。对空闲的存储桶逐步增加流量；对于热点读取，优先使用 CDN 边缘。对于多个虚拟机需要相同的大型只读数据集的情况，可将一个永久性磁盘以只读模式挂载到多个实例，以低成本实现快速的本地访问。

负载测试、混沌实验、故障注入和容量规划

• 负载测试：模拟真实的流量形态和数据分布。预热缓存和自动扩缩容器；在负载下和扩缩容事件期间测试 p95/p99 延迟。将一小部分实时流量镜像到影子堆栈，以验证在生产环境复杂度下的行为。
• 混沌和故障注入：终止 Pod/虚拟机，封锁一个可用区，在服务网格（例如 Envoy/Istio）层面注入延迟/错误，以观察爆炸半径和弹性。验证熔断器和重试机制是否按预期工作。
• 容量规划：利用历史需求和计划内事件进行预测。为 N+1 故障和再平衡保留裕量。将自动扩缩容器的冷却时间和最大速率与预期峰值对齐；在可预测的高峰期间进行预先配置。

托管服务与自定义架构之间的可用性权衡

• 计算：Cloud Run 提供快速的缩容至零和低运维开销，但存在冷启动和请求并发限制。GKE 提供精细化控制和可移植性，但运维成本更高。Compute Engine 虚拟机提供最大程度的控制，但运维负担最重。
• 数据：Cloud Spanner 提供全球一致性和高可用性，但成本更高且 schema 更严格。Cloud SQL 适用于传统的 RDBMS 场景，运维更简单，但高可用性/可扩展性有限。Bigtable 在低延迟、大规模键值/时间序列数据方面表现出色。Firestore 提供灵活的 schema、强一致性和全球选项。
• 网络：全球负载均衡器和 Cloud CDN 具有高可用性，并在 Google 的边缘运行；自建代理提供定制化能力，但会带来运维和故障风险。
• 优先选择托管服务以获得更高的基线可用性和 DDoS 抵御能力，但在设计中要考虑配额、冷启动和服务特定的语义。

实践问题场景

NimbusMart 是一家全球电子商务公司，需要一个低延迟的产品目录 API，要求具备五个九的可用性，并为北美、欧洲和亚太地区的用户提供最小化的读取延迟。写入操作必须是全球一致的。在秒杀活动期间流量会出现尖峰，并且历史事件中曾出现过级联重试和源站过载问题。

方法：

1. 部署一个多区域 Cloud Spanner 实例，使用 nam-asia-eur1 并至少配置三个节点。

• 基本原理：提供全球一致的读/写操作和五个九的可用性，并将副本放置在用户附近以减少读取延迟。至少三个节点可提供仲裁稳健性和用于再平衡的裕量。

2. 在多个区域部署一个无状态 API 层，并置于全球外部应用负载均衡器之后。

• 基本原理：Anycast VIP 和全球路由减少了连接建立时间，并将用户引导至最近的健康区域。无状态服务简化了水平扩缩容和故障切换。

3. 为负载均衡器的可达性配置健康检查和防火墙规则。

• 基本原理：健康检查可防止流量被路由到不健康的后端。允许 Google 健康检查 IP 范围，以确保检查成功： gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS

4. 基于请求指标实施自动扩缩容，并配置暖容量。

• 基本原理：根据 QPS/延迟而不是 CPU 来对 MIG 或 GKE HPA 进行扩缩容，以应对秒杀活动的流量。在每个区域保持最小副本数，以避免冷启动，并在已知事件发生前启用预测性自动扩缩容。

5. 为存储在 Cloud Storage 中的静态产品媒体文件添加 Cloud CDN。

• 基本原理：边缘缓存为源站减负，降低尾部延迟，并减轻应用和存储层上的突发流量放大效应。使用签名 URL 和适当的缓存键/TTL。

6. 在边缘和服务层实施过载保护和速率限制。

• 基本原理：配置 Cloud Armor 速率限制以吸收恶意流量尖峰。在服务内部，对每个客户端使用令牌桶限制，并在延迟 SLO 受到威胁时丢弃低优先级请求。为每个下游调用应用超时期限。

7. 使用带截断的指数退避和完全抖动的弹性重试；通过操作 ID 确保幂等性。

• 基本原理：防止在部分故障期间出现惊群效应和重复写入。幂等性密钥确保了重放的安全性；对于存储操作，使用条件性前置条件。

8. 在可接受的情况下，引入一个写入队列以实现突发流量平滑和异步处理。

• 基本原理：Pub/Sub 可以缓冲非关键写入（例如分析事件）的突然尖峰，将生产者与 Spanner 解耦，并保护主要写入路径免于过载。

9. 定义 SLO 和延迟预算；配置追踪和仪表盘。

• 基本原理：每层预算为优化提供指导。Cloud Monitoring 的 SLO 结合错误预算和 Cloud Trace 可以揭示跨区域和数据层对 p99 延迟的贡献因素。

10. 建立灾难恢复操作手册并测试故障切换。

• 基本原理：使用多区域 Spanner 和多区域计算资源，演练区域疏散。通过流量排空和流量爬坡时间线来验证 RTO，并验证自动扩缩容器和 CDN 在故障切换期间是否行为正确。

该设计通过统一计算和数据拓扑、实施过载控制以及使用提供经过验证的可扩展性和弹性的托管服务，满足了全球可用性和低延迟的目标。

← 可观测性、调试和网站可靠性运维 · 所有领域 · 测试、质量工程和安全发布管理 →

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

浏览 Google →