3. 服务模板发布流程:从模板创建、注册、审批到部署上线的完整生命周期

在 Backstage 平台中,服务模板(Software Template)是连接开发者与基础设施的桥梁。一个模板从创建到最终被开发者使用并部署上线,需要经过一套严谨的发布生命周期。理解这一流程,是后续进行容量水位 SLO 复核的前提——因为只有标准化的发布流程,才能确保每个服务实例都携带可观测的容量基线。

3.1 模板发布生命周期总览

完整的模板发布流程包含四个核心阶段:创建与定义 → 注册与版本化 → 审批与准入 → 部署与上线。每个阶段都有明确的产出物和检查点。

关键原则:模板本身也是软件制品,必须遵循版本管理、变更审批、灰度发布的工程规范,不能直接在生产环境“裸奔”。
服务模板发布生命周期总览 服务模板发布生命周期总览 创建与定义 模板脚手架 + 参数 注册与版本化 Catalog + Git Tag 审批与准入 SLO 门禁 + 人工审核 部署与上线 ArgoCD / 自愈发布 ⏱ 每个阶段都对应一个 SLO 复核检查点 模板参数校验 → 容量基线注册 → 水位门禁审批 → 上线后自动观测 T0: 模板定义 T1: 注册入库 T2: 审批通过 T3: 上线生效

3.2 阶段一:创建与定义

模板创建是生命周期的起点。SRE 或平台工程师在 Backstage 中通过 scaffolder 模块定义模板的脚手架结构、参数表单和后置动作。

组件 说明 容量水位关注点
template.yaml 模板元数据定义,包含名称、参数、步骤 是否声明了默认资源配额(CPU/Mem)
参数表单 开发者创建服务时填写的 UI 表单 是否包含“预期 QPS”或“服务等级”字段
actions 模板执行的后置动作(如创建仓库、写入文件) 是否自动注入容量监控 Sidecar
skeleton 模板脚手架目录结构 是否包含 slo-config.yaml 占位文件
最佳实践:在模板参数中强制要求开发者填写“预估流量等级”(低/中/高),该值将直接映射到后续的容量基线模板。避免上线后才发现资源不足。

3.3 阶段二:注册与版本化

模板创建完成后,需要注册到 Backstage 的软件目录(Software Catalog)中,并打上语义化版本标签。注册过程使模板对组织内所有开发者可见。

  • Catalog 注册:通过 catalog-info.yaml 将模板实体注册到 Backstage,包含 kind: Template、metadata.name、spec.type: service 等字段。
  • Git 版本化:模板代码仓库使用 v1.0.0、v1.1.0 等语义化标签管理版本。每个版本对应一组确定的参数定义和动作逻辑。
  • 版本兼容性检查:新版本模板必须向后兼容已有服务的参数结构,否则会导致已创建的服务无法更新。
# 示例:catalog-info.yaml 中的模板注册片段
apiVersion: backstage.io/v1beta1
kind: Template
metadata:
  name: spring-boot-service
  title: Spring Boot 微服务
  description: 标准 Spring Boot 微服务模板,含容量基线
  tags: ["java", "spring", "microservice"]
spec:
  owner: sre-team
  type: service
  lifecycle: production
  parameters:
    - title: 服务基础信息
      required: ["serviceName", "estimatedQps"]
      properties:
        serviceName:
          type: string
        estimatedQps:
          type: integer
          description: 预估每秒请求数(用于容量规划)
  steps:
    - id: fetch-base
      name: Fetch Base
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}

3.4 阶段三:审批与准入

模板版本发布前必须经过审批门禁。审批不仅包含人工 Code Review,还包含自动化 SLO 门禁检查——这是容量水位复核的关键环节。

常见陷阱:很多团队只做人工审批,忽略了自动化门禁。结果模板上线后,开发者创建的服务没有容量基线,导致生产环境频繁出现资源过载。

审批门禁通常包含以下检查项:

  1. 参数完整性检查:模板是否包含 estimatedQps、criticality 等容量相关参数。
  2. 基线文件存在性检查:模板 skeleton 中是否包含 slo-config.yaml 或 capacity-baseline.yaml。
  3. Sidecar 注入检查:模板动作是否包含 Prometheus 指标采集 Sidecar 的注入步骤。
  4. 资源配额合理性检查:默认 CPU/Mem 请求值是否在合理范围内(例如 CPU 不低于 0.5 核,不高于 8 核)。
  5. 人工审批:SRE 负责人确认模板的容量设计符合组织标准。
模板审批门禁检查流程 模板审批门禁检查流程 模板 PR 提交 ① 参数完整性 容量字段检查 ② 基线文件检查 slo-config.yaml ③ Sidecar 注入 指标采集检查 ④ 资源配额检查 CPU/Mem 范围 ⑤ 人工审批 SRE 负责人确认 ✅ 审批通过 ❌ 任一检查失败 → 驳回

3.5 阶段四:部署与上线

审批通过后,模板进入部署上线阶段。此时模板本身作为一个“服务”被部署到 Backstage 的生产环境,供开发者使用。

部署方式 适用场景 容量水位复核时机
GitOps (ArgoCD) 模板代码与部署配置分离,自动同步 ArgoCD 同步完成后触发 SLO 基线校验
Backstage 内置部署 使用 scaffolder 的 publish 动作直接部署 模板动作执行完毕后立即校验
CI/CD Pipeline 通过 Jenkins/GitHub Actions 触发部署 Pipeline 中增加 SLO 复核步骤

上线后的关键动作:

  • 自动注册容量基线:模板上线后,其关联的容量基线(如默认 CPU 请求、QPS 阈值)自动注册到容量管理系统中。
  • 创建示例服务:平台自动使用新模板创建一个示例服务,验证模板的完整执行链路,并采集首次容量数据。
  • 发布公告:在 Backstage 的“新闻”或“公告”组件中通知所有开发者新模板可用。

3.6 生命周期中的 SLO 复核检查点

在模板发布的每个阶段,SRE 都需要执行对应的容量水位 SLO 复核。下表总结了各阶段的复核要点:

阶段 复核对象 通过标准 失败处理
创建与定义 模板参数定义 包含 estimatedQps 和 criticality 字段 禁止提交 PR,返回参数补充要求
注册与版本化 Catalog 实体 + Git Tag 实体中 spec.type 为 service,Tag 符合 semver 自动修复 Tag 或驳回注册
审批与准入 自动化门禁结果 5 项门禁全部通过 标记 PR 为 failed,通知 SRE
部署与上线 示例服务容量数据 首次采集的 CPU/Mem 使用率 ≤ 基线 80% 回滚模板版本,触发告警
核心结论:服务模板的发布流程不仅是工程规范,更是容量水位 SLO 复核的第一道防线。只有将容量检查嵌入模板生命周期的每个阶段,才能确保后续每个通过模板创建的服务都自带可观测、可管控的容量基线。