1. 服务目录概念
1.1 什么是服务目录
服务目录（Service Catalog）是 IT 运维与 DevOps 领域中用于统一描述、注册和管理可交付服务项的结构化清单。它不仅是“服务菜单”，更是一套包含服务名称、描述、输入参数、交付流程、SLA 及依赖关系的标准化元数据集合。
核心定义：服务目录 = 服务项 × 标准化参数 × 自动化交付流程。在 GitLab CI 场景下，每个服务目录项对应一条可被参数化调用的流水线模板。
服务目录通常包含以下关键属性：
| 属性 | 说明 | 示例（GitLab CI 场景） |
|---|---|---|
| 服务名称 | 唯一标识该服务项 | java-microservice-deploy |
| 描述 | 服务用途与适用场景 | Java 微服务编译、镜像构建与 K8s 部署 |
| 输入参数 | 调用时需传入的变量 | APP_NAME、ENV、REPLICAS |
| 交付流程 | 自动化执行步骤 | build → test → package → deploy |
| SLA/质量门禁 | 交付必须满足的条件 | 单元测试覆盖率 ≥ 80%、安全扫描通过 |
| 依赖关系 | 前置服务或基础设施 | 依赖 base-image-build 流水线 |
1.2 服务目录在 DevOps 中的作用
服务目录是 DevOps 从“手工运维”迈向“平台工程”的关键桥梁。它解决了以下核心痛点：
- 标准化治理：将分散的部署脚本、构建流程统一为可复用的服务项，消除“每个项目一套 Jenkinsfile”的混乱局面。
- 自助式交付：开发人员无需精通 CI/CD 底层细节，通过选择目录项并填写参数即可触发流水线，降低使用门槛。
- 合规与审计：所有服务项经过审批注册，参数范围受控，流水线执行可追溯，满足企业合规要求。
- 效率提升：减少重复造轮子，新项目接入时直接引用已有目录项，交付周期从数天缩短至分钟级。
DevOps 成熟度视角：服务目录是平台工程（Platform Engineering）的核心组件。当组织达到“平台化”阶段时，80% 以上的应用交付应通过服务目录完成，而非手工编写流水线。
1.3 服务目录与 CI/CD 流水线的关联
服务目录与 CI/CD 流水线之间存在“定义-实例化”的强关联关系。服务目录是流水线的“模板仓库”，而 CI/CD 流水线是服务目录的“运行时实例”。
| 维度 | 服务目录 | CI/CD 流水线 |
|---|---|---|
| 角色 | 设计时（Design Time） | 运行时（Runtime） |
| 内容 | 参数定义、流程模板、约束规则 | 具体参数值、执行日志、制品产物 |
| 变更频率 | 低（版本化发布） | 高（每次提交触发） |
| 使用者 | 平台工程师 / DevOps 团队 | 开发工程师 / 测试工程师 |
| GitLab 实现 | .gitlab-ci.yml 模板 + include 机制 |
Pipeline 执行记录 + Job 日志 |
在 GitLab CI 中，服务目录通过以下方式与流水线深度集成：
- 模板化：将通用流水线逻辑抽取为
.gitlab-ci.yml模板文件，存放在独立仓库中。 - 参数化：使用
variables关键字定义输入参数，支持类型校验与默认值。 - 引用机制：项目通过
include关键字引用服务目录模板，并传入具体参数。 - 触发方式：支持手动触发（带参数表单）、API 触发、Webhook 触发等多种模式。
常见误区：服务目录不是静态文档，而是可执行的自动化资产。如果服务目录中的模板无法被流水线直接引用并运行，它就退化为普通的 Wiki 页面，失去了 DevOps 平台工程的价值。