2. Google Cloud平台工程参考架构

在上一节中，我们已经明确了平台工程的核心目标：把基础设施与运维能力封装成可复用的产品，让开发者通过自助服务快速、安全地交付应用。本节要回答一个更具体的问题——在 Google Cloud 上，这套内部开发者平台（IDP，Internal Developer Platform）应该长成什么样子？我们给出一套参考架构，它由四个层次构成：基础设施层、平台层、开发者门户层、安全治理层。前三层是纵向的能力堆叠，安全治理层则横向贯穿全部三层。

理解这套分层架构的关键，不是记住四个名字，而是理解每一层"对谁负责、暴露什么接口、隐藏什么复杂度"。下面逐层展开。

基础设施层：把云资源变成可编排的底座

基础设施层是 IDP 的最底层，负责承载实际的计算、存储、网络与数据资源。在 Google Cloud 上，这一层的典型对象包括：GKE 集群（含节点池、Autopilot 模式）、Cloud Run 服务、Cloud SQL / Spanner / BigQuery 等数据服务、VPC 与子网、Cloud Load Balancing、Cloud Storage 存储桶，以及 Artifact Registry 制品仓库。

这一层最重要的工程实践是用声明式基础设施即代码（IaC）管理资源，主流选择是 Terraform（配合 google provider）或 Config Connector。平台团队不会让开发者直接点控制台创建资源，而是把资源定义封装成模块。例如一个标准的 GKE 集群模块，会固定开启 Workload Identity、私有节点、Shielded Nodes、节点自动修复与自动升级，并统一打上标签：

resource "google_container_cluster" "standard" {
  name                     = "idp-standard"
  location                 = "asia-east1"
  enable_shielded_nodes    = true
  workload_identity_config { workload_pool = "my-project.svc.id.goog" }
  private_cluster_config {
    enable_private_nodes    = true
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
  resource_labels = { "platform-layer" = "infra", "cost-center" = "shared" }
}

这样做的价值在于：开发者拿到的不是"一个空项目"，而是"一个已经符合组织安全与成本规范的集群"。基础设施层对上层暴露的接口是模块与资源模板，而不是原始 API。

平台层：把基础设施组装成开发者可用的能力

平台层是 IDP 的"能力中枢"，它把基础设施层的资源组合成开发者真正需要的东西：CI/CD 流水线、环境（dev/staging/prod）、服务目录、密钥与配置管理、可观测性接入点。在 Google Cloud 上，这一层通常由以下组件构成：Cloud Build 或 GitLab/GitHub Actions 负责构建，Cloud Deploy 负责渐进式发布（支持 canary 与蓝绿），Artifact Registry 存放镜像与包，Config Sync 或 Argo CD 负责把 Git 中的期望状态同步到 GKE 集群。

平台层最核心的设计原则是以 Git 为唯一事实来源（GitOps）。开发者提交代码后，流水线自动构建镜像、推送制品、更新部署清单仓库，再由同步控制器把变更应用到集群。平台团队在这一层定义"黄金路径"（Golden Path）：一个标准微服务从代码到上线的完整模板，包含 Dockerfile 规范、健康检查端点、资源请求与限制、HPA 策略、日志与指标接入。开发者只需填写少量参数，就能获得一条经过验证的交付链路。

平台层对上层暴露的接口是自助服务 API 与模板，例如一个 Backstage 软件模板，或一个内部 REST 端点，开发者调用它即可申请环境、创建服务骨架。

开发者门户层：开发者唯一需要面对的入口

开发者门户层是 IDP 的"门面"，也是开发者日常接触最多的界面。它的职责是把平台层的能力以产品化方式呈现：服务目录、文档、模板、环境状态、部署历史、日志与指标入口。在 Google Cloud 生态中，常见实现是 Backstage（配合 GKE 部署），也可以基于 Cloud Run 自建轻量门户。

门户层的关键不是"好看"，而是降低认知负担。一个合格的门户应该让开发者在一个页面内完成：查看我负责的服务、触发一次部署、查看当前环境健康度、申请一个新环境。它通过插件对接平台层 API，把分散在多个控制台的操作收敛为统一入口。门户层对开发者暴露的是用户界面与自助操作，对平台层则通过 API 调用，不直接触碰基础设施。

安全治理层：横向贯穿的约束与可见性

安全治理层不参与纵向的能力堆叠，而是横向覆盖前三层，确保"自助"不等于"失控"。它的核心机制包括：

• 身份与权限：用 Cloud IAM 与 Workload Identity 实现最小权限，服务账号按职责划分，禁止长期密钥。
• 策略即代码：用 Organization Policy 与 Policy Controller（Gatekeeper）限制可创建的资源类型、区域、镜像来源。
• 供应链安全：Artifact Registry 开启漏洞扫描，Binary Authorization 要求镜像必须签名且通过扫描才能部署。
• 审计与合规：Cloud Audit Logs 记录所有 API 调用，Security Command Center 汇总风险发现。

治理层的设计要点是把约束前置到模板与流水线中，而不是事后审计。开发者在门户里点击"创建服务"时，模板已经内置了合规配置；流水线在构建阶段就执行策略检查，不合规的镜像无法进入部署阶段。这样，安全团队从"审批者"转变为"规则定义者"，开发者则获得"在护栏内自由行动"的体验。

四层如何协同：一次服务上线的完整路径

把四层串起来看，一次典型的服务上线会经历如下路径：开发者在门户层选择"标准微服务"模板并填写服务名与团队；门户调用平台层 API，平台层从基础设施层模块创建命名空间、服务账号与 Artifact Registry 仓库；开发者提交代码后，平台层流水线构建镜像、扫描漏洞、推送制品；Cloud Deploy 按策略发布到 dev 环境；Config Sync 把清单同步到 GKE；治理层全程校验 IAM、策略与镜像签名；门户层实时展示部署状态与健康指标。

下面这张图展示了这套分层架构的纵向堆叠与横向治理关系，以及一次服务上线时数据与控制流的走向。

落地时的三个关键判断

这套参考架构不是必须一次建成的。实际落地时，平台团队需要做三个判断。第一，先建哪一层：如果组织已有成熟的 Terraform 模块和 CI/CD，优先补平台层的 GitOps 与黄金路径；如果开发者还在手动点控制台，优先建门户层与基础设施模块。第二，治理的粒度：初期可以用 Org Policy 做粗粒度约束，随着服务数量增长再引入 Policy Controller 做细粒度准入控制。第三，门户的边界：门户只做"聚合与展示"，不承载业务逻辑，所有能力通过平台层 API 暴露，避免门户变成新的单体。

总结来说，Google Cloud 上的 IDP 分层架构，本质是把"云资源的复杂性"逐层收敛：基础设施层收敛为模块，平台层收敛为黄金路径，门户层收敛为统一入口，治理层则把安全约束前置到每一层。四层各司其职、接口清晰，才能让开发者真正获得"自助但不失控"的体验。