3. 服务模板发布流程:从模板创建、注册、审批到部署上线的完整生命周期
在 Backstage 平台中,服务模板(Software Template)是连接开发者与基础设施的桥梁。一个模板从创建到最终被开发者使用并部署上线,需要经过一套严谨的发布生命周期。理解这一流程,是后续进行容量水位 SLO 复核的前提——因为只有标准化的发布流程,才能确保每个服务实例都携带可观测的容量基线。
3.1 模板发布生命周期总览
完整的模板发布流程包含四个核心阶段:创建与定义 → 注册与版本化 → 审批与准入 → 部署与上线。每个阶段都有明确的产出物和检查点。
关键原则:模板本身也是软件制品,必须遵循版本管理、变更审批、灰度发布的工程规范,不能直接在生产环境“裸奔”。
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 门禁检查——这是容量水位复核的关键环节。
常见陷阱:很多团队只做人工审批,忽略了自动化门禁。结果模板上线后,开发者创建的服务没有容量基线,导致生产环境频繁出现资源过载。
审批门禁通常包含以下检查项:
- 参数完整性检查:模板是否包含
estimatedQps、criticality等容量相关参数。 - 基线文件存在性检查:模板 skeleton 中是否包含
slo-config.yaml或capacity-baseline.yaml。 - Sidecar 注入检查:模板动作是否包含 Prometheus 指标采集 Sidecar 的注入步骤。
- 资源配额合理性检查:默认 CPU/Mem 请求值是否在合理范围内(例如 CPU 不低于 0.5 核,不高于 8 核)。
- 人工审批: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 复核的第一道防线。只有将容量检查嵌入模板生命周期的每个阶段,才能确保后续每个通过模板创建的服务都自带可观测、可管控的容量基线。