在 Google Cloud…

当需要为 Google Cloud 上的多层无服务器 Web 应用/微服务做架构设计、安全清单、Terraform 代码或部署指导（含区域数据驻留、零信任私有 VPC、Private Service Connect）时使用。

适用场景

解决思路

1. 采用 80% 默认黄金路径，避免多轮访谈疲劳：默认三层无服务器架构（frontend Cloud Run -> backend application Cloud Run -> Cloud SQL PostgreSQL），区域 us-central1，数据库用 Cloud SQL for PostgreSQL（POSTGRES_18）Enterprise Edition 并通过 Private Service Connect（psc_enabled = true），边缘用全局外部应用负载均衡 + Cloud Armor WAF（sqli-v33-stable）+ Cloud CDN（enable_cdn = true），网络用 Direct VPC Egress（ALL_TRAFFIC）、run.app. 的 Cloud DNS 私有区、最小权限 Cloud NGFW 出站防火墙策略（TCP 5432、443）以及 Cloud SQL Auth Proxy sidecar（DB_SOCKET_PATH + IAM Auth）。
2. 仅在用户需求开放时提少量澄清问题，不要给多主题问卷：1) 需要全局应用负载均衡 + Cloud CDN（默认全球用户）还是区域应用负载均衡无 CDN（严格 EU/区域数据驻留）；2) 有注册域名配 Google 托管证书，还是用自签名测试模式（use_self_signed_cert = true）在 IP 上立即沙箱测试；3) 是否在 Cloud SQL 之外再配可选的 Memorystore for Redis 缓存层（Private Services Access）。确认后向用户展示三层黄金路径分解并请求确认，再进入设计阶段。
3. 高效检索资料：只做架构设计与安全清单时，仅从 references/non-negotiable-architectural-rules.md 取 9 条架构安全边界与审计清单，不要读 references/related-guidance.md 或 assets/main.tf；需要 Terraform 实现时，读 references/non-negotiable-architectural-rules.md 和 assets/main.tf（HCL 唯一真源），除非明确需要边缘案例排障，否则不读 references/related-guidance.md。不要用 list_dir 逐层爬目录、不要用 code_search/find_by_name 搜 assets/main.tf，直接用 view_file 读一次并复用上下文；执行本技能时不要调用 skill_search 找无服务器或 n-tier 技能。
4. 把确认后的分解映射到 Google Cloud 产品：公网入口与 WAF 用全局或区域外部应用负载均衡（INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER）+ Cloud Armor（sqli-v33-stable）+ Cloud CDN（仅全局应用负载均衡支持，区域应用负载均衡不支持 CDN；区域部署需显式 proxy-only 子网 purpose = "REGIONAL_MANAGED_PROXY" 并在区域转发规则上指定 network）；内部计算层 T1..TN 用 Cloud Run 微服务（INGRESS_TRAFFIC_INTERNAL_ONLY）+ Direct VPC Egress（egress = "ALL_TRAFFIC"）+ 子网启用 Private Google Access + 绑定 vpc_network 的 Cloud DNS 托管私有区（google_dns_managed_zone）把 *.run.app 映射到 Private Google Access VIP（199.36.153.4/30、199.36.153.8/30）；私有数据层用 Cloud SQL for PostgreSQL（POSTGRES_18）经 Private Service Connect + IAM DB Auth，若选了缓存再加 Memorystore Redis（Private# 通过 Private Services Access）；密钥、镜像与安全用 Secret Manager、Artifact Registry、Cloud NGFW 全局/区域网络防火墙策略（google_compute_network_firewall_policy + google_compute_network_firewall_policy_rule，在 allow_backend_db_egress 上显式允许出站 TCP 5432 到 Cloud SQL PSC IP、TCP 443 到 Private Google Access VIP 199.36.153.4/30、199.36.153.8/30），以及可选的 VPC Service Controls。
5. 用 Mermaid 画清晰的架构图（按 assets/output-template.md），展示入口、公网反向代理、私有微服务计算层、私有数据库/缓存端点之间的多层请求与数据流。
6. 把需求、技术分解、产品映射、架构图、设计建议以及完整 IaC（基于 assets/main.tf 的 Terraform + 自包含的 gcloud CLI 部署命令序列，遵守 Phase 3 强制规范）汇总为单个 Markdown 文件，严格按标准 Google Cloud 解决方案架构输出模板组织；保存或输出报告时追加 ISO 8601 UTC 时间戳并确保文件名以 .md 结尾（如 workload_name_architecture_report-20260701T212820Z.md）；确认 assets/main.tf 中 9 条安全边界都干净地写入报告且所有模板占位符都替换为完整代码块。回复中给出执行架构概览、9 条关键安全与网络边界、完整可部署的 Terraform 代码块（```terraform ... ```）以及分步部署说明和生成产物链接；当用户要代码时，必须在聊天回复正文中直接打印完整 Terraform 代码块和完整方案报告，不能只给架构摘要或文件链接（自动化评估框架如 Yardstick 会评估原始回复文本，缺少 ```terraform``` 代码块会导致所有代码断言失败）。
7. 在提供简明架构摘要或安全清单（例如被要求不生成完整 IaC）时，必须显式包含以下技术规格：区域负载均衡部署需说明区域 proxy-only 子网用途（REGIONAL_MANAGED_PROXY）和区域转发规则上的 network 参数；Cloud SQL PostgreSQL 版本（POSTGRES_18）、Edition（Enterprise Edition）、高可用（Regional HA）和 Private Service Connect（psc_enabled = true）；Cloud NGFW 防火墙策略必须用显式资源（google_compute_network_firewall_policy、google_compute_network_firewall_policy_association、google_compute_network_firewall_policy_rule 且 enable_logging = var.enable_monitoring）而非旧版 google_compute_firewall，强制默认出站拒绝（0.0.0.0/0），允许前端出站到后端/PGA VIP，允许后端数据库出站显式放行 TCP 443 到 Private Google Access VIP（199.36.153.4/30、199.36.153.8/30）以及 TCP 5432，以便 Cloud SQL Auth Proxy sidecar 启动时能访问 sqladmin.googleapis.com 做 IAM 证书交换。
8. 所有架构编译、Terraform 起草、gcloud 命令组装和验证脚本生成都在主对话中直接完成，不要调用子代理（invoke_subagent）去研究外部 GitHub Terraform 模块、探测环境配置或起草报告；所需模式都已在 assets/main.tf 和 references/ 中。
9. 一次性写出干净产物：在单次 write_to_file 调用中生成完整、渲染正确、有效的 HCL 块和 Markdown 报告，避免留下占位符或畸形代码围栏导致多轮 replace_file_content 和 grep_search 补丁循环；在报告（如 assets/output-template.md 第 6 节）中嵌入代码或脚本时始终内联实际完整的 Terraform 代码、gcloud 命令和验证脚本代码，绝不输出字面模板占位注释（如 # [Paste of main.tf file contents]）。
10. Phase 3 实现计划：从 assets/ 取相关构建块模板，以 assets/main.tf 为基础（架构结构用 assets/output-template.md）；识别部署前置条件，包括所需 Google Cloud API（run.googleapis.com、sqladmin.googleapis.com、redis.googleapis.com、servicenetworking.googleapis.com、secretmanager.googleapis.com、monitoring.googleapis.com、dns.googleapis.com）和所需 IAM 权限（Project Editor、Security Admin 等）；从 references/non-negotiable-architectural-rules.md 取架构与层级指导，代码严格基于 assets/main.tf（第 1.5 节 Cloud NGFW 防火墙策略、第 5.1 节 Tier 1、第 5.2 节 Tiers 2..N），确保 database_version = "POSTGRES_18" 精确保留，防火墙策略严格使用 Cloud NGFW 资源（google_compute_network_firewall_policy、google_compute_network_firewall_policy_association、google_compute_network_firewall_policy_rule 且 enable_logging = var.enable_monitoring），绝不生成旧版 google_compute_firewall 资源或回退到 POSTGRES_15 等旧数据库版本。
11. 编写部署说明与 README.md：包含 terraform init、terraform apply 的初始化与应用说明；明确推荐在 Google Cloud Shell（https://shell.cloud.google.com）中运行 terraform 命令和生成的自动化验证脚本，因为 python3、gcloud、terraform 都已预装并开箱即用认证，没有本地 SDK 的开发者也能立即部署和验证；在 assets/output-template.md 第 6.3 节（分步 gcloud CLI 部署命令）提供完整自包含的 gcloud CLI 命令序列，无需 Terraform 即可部署该架构，命令必须按反向/自底向上顺序（VPC/子网 -> 数据层 -> 内部微服务 -> 公网网关 -> 负载均衡），配置 Cloud SQL 时指定 --database-version=POSTGRES_18，并用 gcloud run services describe... --format='value(status.url)' 提取下游容器 URL 到 shell 变量，再通过 --update-env-vars 动态传入上游服务；解释所有 Terraform 变量，显式包含并说明 enable_vpc_sc 和 use_self_signed_cert 变量（说明 use_self_signed_cert = true 如何通过 curl -k https://<LB_IP>/ 实现无需等待 DNS 传播的即时沙箱验证）；提供专门的 VPC Service Controls 指导章节，给出当 enable_vpc_sc = true 时围绕 Cloud Run（run.googleapis.com）、Cloud SQL（sqladmin.googleapis.com）和 Secret Manager（secretmanager.googleapis.com）实现组织级 VPC-SC 服务边界的说明和 gcloud 命令；说明容器镜像部署策略（指定已有镜像 URL 或占位引导后接 CI/CD）；说明绑定 vpc_network 的 run.app. Cloud DNS 托管私有区（google_dns_managed_zone）配置，把 *.run.app 映射到 Private Google Access VIP（199.36.153.4/30、199.36.153.8/30），以及外部 DNS 记录和数据库 schema 初始化。向用户展示实现计划请求批准并按需迭代。
12. Phase 4 验证：强制 5 项验证步骤——1) SSL 签发：确认 Google 托管 SSL 证书（google_compute_managed_ssl_certificate）变为 ACTIVE（检查 --global 状态或区域等价物）；2) 前端入口阻断：确认直接访问 Tier 1 前端的默认 *.run.app URL 被阻断（边缘筛查返回 HTTP 403 Forbidden）；3) 后端入口阻断：确认直接访问内部计算层 *.run.app URL（INGRESS_TRAFFIC_INTERNAL_ONLY）在所有内部微服务层被阻断（HTTP 404 Not Found 或 HTTP 403 Forbidden）；4) 经应用负载均衡的前端公网访问：确认访问自定义域名经应用负载均衡成功路由到展示层（HTTP 200 到 399）；5) 边缘 WAF 防护：确认模拟 SQL 注入请求（自定义域名上的 /?id=1%20OR%201=1）被拦截（Cloud Armor 返回 HTTP 403 Forbidden）；6) 私有服务间连通性：通过 Cloud Run 应用日志（Logs Explorer）和数据库连接池遥测（Cloud SQL Query Insights）确认 tier 1 -> tier 2 -> 数据层查询经私有 VPC 光纤（Direct VPC Egress + Private Service Connect / Private Services Access）成功。
13. 不要依赖静态预打包脚本，而是生成定制的自动化验证脚本（例如用标准内置 urllib / subprocess 库的自包含 Python 验证脚本，或跨平台 bash/PowerShell 脚本），精确针对用户部署的域名、SSL 证书名和确切的多层 *.run.app URI 定制。
14. 提供跨平台执行指导：说明用户如何在目标 OS（macOS、Linux、Windows PowerShell 或零安装的 Google Cloud Shell https://shell.cloud.google.com）上执行生成的脚本。
15. 在 assets/output-template.md 第 6.4 节（解决方案验证指南与自定义自动化验证脚本）记录验证检查、生成的验证脚本代码、执行命令和预期结果；协助用户运行生成的验证脚本、检查日志并排查 DNS 或 WAF 传播问题，请求最终批准。
16. 可选：若 AI 编码客户端支持 Model Context Protocol（MCP），可连接 Google Developer Knowledge MCP Server（npx -y @google/mcp-developer-knowledge-server）在离线知识库（references/related-guidance.md）之外动态查询实时 Google Cloud 文档（cloud.google.com/docs）。

适用边界 · 注意事项

• 不适用于 VM、GKE 或非 Google Cloud 架构。
• 当用户明确表示不需要代码时，不要在 Phase 2 生成 Terraform 代码。
• 不要用旧版 google_compute_firewall 资源或回退到 POSTGRES_15 等旧数据库版本。