手册

微服务既需要同步的请求/响应，也需要异步的事件驱动通信。

→对于同步调用，使用 gRPC 或 HTTP。对于异步事件和扇出，使用 Pub/Sub。

原因: Pub/Sub 完全解耦服务，以实现可靠性和独立扩展。直接调用提供低延迟的同步响应。

参考↗

无状态计算服务（Cloud Run、Cloud Functions）需要处理临时文件。

→使用 Cloud Storage 进行所有临时文件 I/O。

原因: 无服务器平台的本地文件系统是短暂的、基于内存的且不共享的。Cloud Storage 提供持久、可扩展的存储，可供所有实例访问。

根据十二要素原则管理 GKE 工作负载的环境特定配置和秘密信息。

→对于非敏感配置，使用 K8s ConfigMaps。对于敏感值，使用 Secret Manager，并通过 Workload Identity 安全访问。

原因: Secret Manager 比 K8s Secrets 更安全、更易管理且可审计。Workload Identity 避免了管理和分发服务账号密钥。

参考↗

应用流量峰值极高，但空闲期较长，需要最大限度地降低成本。

→使用 Cloud Run 并将 `min-instances` 设置为 0。

原因: Cloud Run 可以缩容到零，在空闲期间消除所有计算成本。GKE 和 Compute Engine 需要最低数量的运行节点/实例。

在微服务中一致地实现重试、熔断器和 mTLS，无需更改应用程序代码。

→在 GKE 上部署服务网格 (Anthos Service Mesh)。

原因: 服务网格在平台层面注入弹性、安全性与可观测性，保持应用程序代码的简洁并确保行为一致。

将后端服务通过速率限制、API 密钥和使用分析暴露给外部合作伙伴或移动应用程序。

→在后端服务（例如 Cloud Run、GKE）前使用 API Gateway。

原因: API Gateway 为 API 生命周期问题（安全性、监控、版本控制）提供完全托管的解决方案，从而将这些问题从后端服务中分流。

参考↗

为仅追加的事件日志选择一个持久、可扩展且强一致的存储。

→使用 Cloud Spanner 作为事件存储。

原因: Spanner 提供具有强全局一致性的水平可扩展性，这对于在大规模环境下维护事件日志的完整性至关重要。

长时间运行作业的 API 必须立即响应，同时处理在后台继续进行。

→API 端点在 Pub/Sub 或 Cloud Tasks 中入队一个任务，并返回一个带有作业 ID 的 202 Accepted 响应。一个独立的 worker（Cloud Run、Cloud Function）处理该任务。

原因: 这使面向用户的响应时间与后端处理时间解耦，从而改善用户体验和系统可靠性。使用 Cloud Storage 进行状态更新。

在不共享数据库的情况下，维护多个微服务之间的数据一致性。

→使用编排器（Cloud Workflows）或编舞（Pub/Sub 事件）并结合补偿事务来实现 Saga 模式。

原因: 避免了复杂且易于产生锁的两阶段提交，倾向于最终一致性，这更适合分布式系统。

应用程序调用一个数据不经常变化的、受速率限制的第三方 API。

→使用 Memorystore for Redis 作为分布式缓存。实现带有 TTL 的 Cache-Aside 模式。使用分布式锁（例如 Redis SETNX）来防止缓存击穿。

原因: 分布式缓存可在所有应用实例之间共享数据，显著减少对外部 API 的调用，提高延迟并遵守速率限制。

开发团队需要一致、预配置、安全的开发环境，并能访问私有 VPC 资源。

→使用 Cloud Workstations。

原因: Cloud Workstations 提供托管的、基于容器的开发环境，具有集成的安全性和 VPC 访问功能，解决了“在我的机器上能运行”的问题。

参考↗

SaaS 应用程序要求租户拥有完全隔离的数据、加密密钥和数据驻留。

→采用每个租户一个项目模型。使用 IaC (Terraform) 集中管理预置和配置。

原因: 为 IAM、账单、配额、网络和数据位置提供最高级别的隔离，这通常是企业或受监管客户所要求的。

强制只有来自官方管道的受信任、经过扫描的容器镜像才能部署到生产环境。

→使用 Cloud Build 生成 SLSA 来源证明，使用 Artifact Registry 进行漏洞扫描，并使用 Binary Authorization 根据证明强制执行部署策略。

原因: 创建从代码到部署的可验证、不可绕过的加密信任链，防止部署受损或未经扫描的工件。

参考↗

部署 Cloud Run 服务的新版本，在不影响用户的情况下进行测试，并即时切换流量。

→使用 `--no-traffic` 部署新修订版本。使用唯一的修订版本 URL 或修订版本标签进行测试。验证后，将 100% 的流量切换到新修订版本。

原因: Cloud Run 的原生流量管理允许在新版本接收任何生产流量之前对其进行验证，从而实现安全、零停机时间的部署。

逐步推出新版本，自动分析指标并在失败时回滚。

→使用 Cloud Deploy 和金丝雀部署策略。与 Cloud Monitoring 集成以进行自动指标分析和回滚触发。

原因: Cloud Deploy 自动化了整个渐进式交付工作流，包括指标分析和安全检查，减少了手动工作和风险。

管理开发、 staging 和 prod 环境的 Kubernetes 清单，避免代码重复。

→使用 Kustomize 或 Helm。定义一个基础配置，并创建环境特定的覆盖或值文件以修补差异。

原因: 遵循 DRY 原则，使配置更易于管理，并降低环境漂移的风险。

减小容器镜像大小，以加快部署速度并缩小攻击面。

→使用多阶段构建。`build` 阶段使用完整的 SDK/JDK 镜像；最终阶段仅将编译后的工件复制到最小的 `distroless` 基础镜像中。

原因: 最终镜像只包含应用程序及其运行时依赖项，移除了所有构建工具、Shell 和包管理器。

在合并之前，为每个拉取请求自动部署临时环境以进行验证。

→使用 Cloud Build 触发器响应 PR 事件，部署到带有修订版本标签（例如 `pr-123`）的 Cloud Run。在 PR 关闭时使用另一个触发器来清理带标签的修订版本。

原因: 修订版本标签为每个 PR 提供唯一的临时 URL，而无需创建新服务的开销，使其具有成本效益且易于自动化。

通过缓存公共软件依赖项（例如来自 npm、Maven Central 的依赖项）来提高 CI/CD 构建速度和可靠性。

→使用 Artifact Registry 远程仓库，它充当公共仓库的拉取直通缓存。

原因: 提高构建性能，使构建免受公共仓库中断的影响，并允许对缓存工件进行漏洞扫描。

安全地存储和锁定 Terraform 状态，以支持并发的 CI/CD 流水线执行。

→为 Terraform 状态使用 Cloud Storage 后端，并为 Cloud Build 服务账号配置适当的 IAM。

原因: Cloud Storage 提供持久、版本化和可锁定的后端，防止并发构建导致状态损坏。

Cloud Run 或 Cloud Function 需要访问私有 VPC 网络上的资源（例如 Cloud SQL、Memorystore）。

→配置无服务器 VPC 访问连接器。

原因: 该连接器充当网络桥梁，允许无服务器环境的出站流量进入目标 VPC，而无需公开暴露资源。

参考↗

GKE 上的有状态应用程序需要稳定的身份和持久存储，以在 pod/节点故障后仍然可用。

→使用带有 Headless Service 的 StatefulSet 用于身份。使用带有区域 Persistent Disk 的 PersistentVolumeClaim (PVC) 用于存储。

原因: 这是有状态工作负载的规范 Kubernetes 模式，确保数据持久性、高可用性和可预测的 pod 命名/网络。

GKE 上的 Pod 需要安全地访问 GCP API，而无需管理静态服务账号密钥。

→配置和使用 Workload Identity。

原因: Workload Identity 将 Kubernetes 服务账号绑定到 Google 服务账号，允许 Pod 使用从元数据服务器获取的短期 GCP 凭据。

运行一个需要数小时才能完成的批处理作业（例如，处理大文件，夜间数据聚合）。

→使用 Cloud Run jobs，由 Eventarc 或 Cloud Scheduler 触发。

原因: Cloud Run jobs 专为长时间运行（最长 24 小时）的任务设计，可缩容到零，并且比专用的 GKE 集群或 VM 更具成本效益且更简单，适用于批处理工作负载。

在 Cloud Run 上部署多容器应用程序，其中主容器需要一个用于日志记录、指标或作为代理的边车。

→部署 Cloud Run 服务时指定多个容器镜像，一个作为主容器，其他作为边车。

原因: Cloud Run 的原生多容器支持为无服务器工作负载实现了边车模式，而无需 GKE 的复杂性。

数据库迁移必须在新 Cloud Run 修订版本接收流量之前完成。

→在容器启动期间运行迁移，并使用 Cloud Run 启动探针，该探针仅在迁移成功后才通过。

原因: 启动探针会延迟流量路由，直到容器完全就绪，确保在处理任何请求之前数据库 Schema 是正确的。

GKE 应用程序需要根据自定义指标（例如 Pub/Sub 的队列深度）进行扩缩，而不仅仅是 CPU/内存。

→使用配置为从 Cloud Monitoring 读取自定义指标的 Horizontal Pod Autoscaler (HPA)。

原因: 这允许自动扩缩由业务逻辑或应用程序特定的负载指标驱动，提供比通用资源指标更准确的扩缩。

消息驱动的服务必须精确处理每条消息一次，即使存在重试和潜在的重复投递。

→将 Pub/Sub（具有至少一次或精确一次投递）与幂等消费者结合使用。消费者在持久存储（例如 Firestore、Memorystore）中跟踪已处理的消息 ID。

原因: Pub/Sub 保证消息投递，但消费者负责幂等性，以处理应用程序级别的重试并实现真正的精确一次处理。

与同一实体（例如特定用户）相关的事件必须按照它们生成的顺序进行处理。

→使用 `orderingKey` 将消息发布到 Pub/Sub。在订阅上启用消息排序。

原因: Pub/Sub 保证具有相同排序键的消息按顺序投递，而具有不同键的消息可以并行处理以实现可扩展性。

参考↗

确保任务（例如生成每日用户报告）只运行一次，即使收到多个触发事件。

→使用 Cloud Tasks。创建带有明确名称的任务（例如 `report-userX-2024-10-26`）。Cloud Tasks 将对创建具有现有名称的任务的请求进行去重。

原因: 这会将去重逻辑卸载到队列服务，简化应用程序代码并防止重复工作。

Pub/Sub 消息在多次重试后持续处理失败，并阻塞队列。

→在 Pub/Sub 订阅上配置死信主题 (DLQ)，并设置最大投递尝试次数。

原因: Pub/Sub 自动将“毒丸”消息移动到 DLQ，允许处理其他消息并保留失败消息以供分析。

业务流程涉及一系列服务调用，具有条件逻辑、错误处理和长时间等待。

→使用 Cloud Workflows 定义和执行编排逻辑。

原因: Cloud Workflows 是一个无服务器编排器，管理状态、重试和长时间等待，提供比手动链式函数更好的可靠性和可见性。

参考↗

Cloud Function 或 Cloud Run 服务应仅由特定的云事件触发（例如，Cloud Storage 中的某些文件类型）。

→使用带有 CEL (Common Expression Language) 过滤事件属性的 Eventarc 触发器。

原因: 过滤发生在服务调用之前，通过不处理不相关的事件来节省成本和计算周期。

对来自 Cloud Run 等横向扩展服务到第三方 API 的出站调用进行速率限制。

→将 API 调用作为任务放入配置了 `rateLimits`（例如，每秒最大分派数）的 Cloud Tasks 队列中。

原因: Cloud Tasks 提供集中式、无服务器的速率限制，适用于所有扩展实例，而无需复杂的分布式计数器。

安全地认证两个 Cloud Run（或 Cloud Functions）服务之间的调用。

→授予调用者服务的服务账号在被调用者服务上的 `roles/run.invoker` IAM 角色。调用者在其请求中发送一个 Google 签名的 ID 令牌。

原因: 这是服务到服务认证的原生、安全且无密钥的方法，利用了 Google 的身份基础设施。

事件驱动的服务需要近实时地响应 Cloud SQL 数据库中的行级更改。

→使用 Datastream (CDC) 将数据库更改流式传输到 Pub/Sub。使用 Eventarc 从 Pub/Sub 主题触发 Cloud Run 服务。

原因: 这是一种解耦、可靠的模式，避免了数据库轮询，并且不需要修改写入数据库的应用程序。

一个长时间运行的业务流程必须暂停，等待外部事件，例如人类点击电子邮件中的审批链接。

→使用带有回调端点的 Cloud Workflows。工作流会暂停（最长一年），直到它在其唯一的 Callback URL 上接收到 HTTP 请求。

原因: 回调允许工作流等待外部事件而不消耗任何计算资源，使其成为长时间运行、需要人工参与的流程的理想选择。

对延迟敏感的无服务器应用程序在空闲期后遇到缓慢的初始响应。

→将 `min-instances` 配置为 1 或更多。对于不可避免的冷启动，使用 `startup-cpu-boost`。同时优化应用程序（更小的镜像，更快的初始化）。

原因: `min-instances` 是消除冷启动最有效的方法，但会产生费用。`startup-cpu-boost` 则加速了启动过程本身。

参考↗

请求在多个微服务之间缓慢或失败，并且瓶颈从日志或单个服务指标中不明显。

→使用带有上下文传播的 Cloud Trace。检测应用程序以转发跟踪头（例如 W3C Trace Context）。

原因: Cloud Trace 提供所有服务中整个请求生命周期的瀑布图可视化，精确定位延迟或错误的来源。

参考↗

应用程序在生产环境中运行缓慢，不清楚问题是 CPU 密集型、内存泄漏还是 I/O。

→使用 Cloud Profiler 持续分析生产环境中的 CPU 和堆使用情况。

原因: Cloud Profiler 以极低的开销识别代码级别的性能瓶颈（热路径、内存泄漏），而无需在测试环境中重现问题。

从简单的阈值警报（例如“延迟 > 500ms”）转向基于服务等级目标 (SLO) 的更有意义的警报。

→在 Cloud Monitoring 中定义 SLI 和 SLO。基于错误预算的“消耗率”创建警报策略。

原因: 消耗率警报比简单的阈值警报对显著变化更敏感，噪音更小，能在你偏离 SLO 轨道时发出信号。

聚合来自多个服务的应用程序异常，以跟踪频率、查看堆栈跟踪并获取新错误类型的通知。

→使用 Cloud Error Reporting。

原因: Error Reporting 自动摄取、分组和分析来自结构化日志的异常，提供一个集中式仪表板来管理应用程序错误。

监控、可视化并根据自定义业务指标（例如每分钟订单数、用户注册数）发出警报。

→使用 OpenTelemetry SDK 检测应用程序代码。配置导出器将指标发送到 Cloud Monitoring。

原因: 这是现代的、供应商中立的自定义检测标准。它允许跟踪任何指标并利用 Cloud Monitoring 的所有功能。