gcp-cloud-run

GCP Cloud Run

用于在 GCP 上构建可用于生产环境的无服务器应用程序的专用技能。 涵盖 Cloud Run 服务（容器化）、Cloud Run Functions（事件驱动）、 冷启动优化，以及使用 Pub/Sub 的事件驱动架构。

部署前提条件

示例是不完整的集成草图：必须提供应用程序辅助工具、IAM 角色、队列、区域以及健康检查／启动探针。选择已获授权的项目／服务和预算，默认使用私有入口和身份验证，并使用带版本号的 Artifact Registry 映像和可回滚的修订版本。历史上的 nodejs20／GCR 示例需要检查受支持的运行时并完成注册表迁移。限制最大实例数和数据库连接总数；最小实例数和扩容加速会产生费用。只有在工作已完成或已持久入队后，才应返回 2xx 响应；重试时应确保幂等性。psutil 的主机内存读数可能无法反映容器 cgroup 限制；请使用 Cloud Monitoring／容器指标。

详细指南

执行此技能前，请阅读详细指南。其中保留了完整的操作流程和参考资料。必须遵守其中的安全要求、前提条件和验证要求。对于针对性任务，请加载相关章节；对于端到端任务，请完整阅读指南。

计算内存（包括 /tmp 用量）

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      - 'run'
      - 'deploy'
      - 'my-service'
      - '--memory=1Gi'  # Include /tmp overhead
      - '--image=gcr.io/$PROJECT_ID/my-service'

监控内存使用情况

import psutil
import logging

def log_memory():
    memory = psutil.virtual_memory()
    logging.info(f"Memory: {memory.percent}% used, "
                f"{memory.available / 1024 / 1024:.0f}MB available")

并发数 = 1 会造成扩缩容瓶颈

严重性：高

情况：为了隔离请求而将并发数设为 1

症状： 自动扩缩容会创建许多容器实例。 流量激增时延迟较高。 冷启动增多。 实例增多导致费用上升。

原因： 并发数设为 1 意味着每个容器一次只能处理一个 请求。流量激增时：

• 100 个同时进行中的请求可能需要多达 100 个实例，具体取决于容量、排队情况和限制
• 每个实例都有冷启动开销
• 实例越多，费用越高
• 扩缩容需要时间，请求会排队

仅在以下情况使用：

• 处理确实是单线程的
• 每个请求的处理都占用大量内存
• 使用线程不安全的库

建议的修复方法：进行负载测试，选择与处理程序的线程安全性、峰值内存、延迟和下游连接限制相匹配的并发数；在适当情况下，并发数为 1 也可以使用。

适用场景

当请求明确符合上述能力和模式时，使用此技能。

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为环境专属验证、测试或专家审查的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请暂停并请求澄清。