3. 服务目录概念：服务目录的定义、在平台工程中的角色、服务目录与 CMDB 的区别
3.1 服务目录的定义
在平台工程语境下，服务目录（Service Catalog）是一个经过治理的、可搜索的、面向开发者的服务清单。它不仅仅是“服务列表”，而是将平台能力（如 CI/CD 流水线、数据库实例、消息队列、监控告警、安全扫描等）封装为标准化、可自助申请的产品单元。
服务目录的核心要素包括：
- 服务定义：服务的名称、版本、描述、SLA、所属团队。
- 接口契约：API 端点、SDK 版本、配置参数 Schema。
- 依赖关系：运行时依赖（如数据库、缓存）、编译时依赖（如基础镜像）。
- 生命周期：创建、更新、废弃、退役的状态机。
- 自助入口：开发者可通过 UI 或 CLI 一键申请，无需提工单。
关键认知：服务目录是平台团队与业务团队之间的“产品货架”。开发者是“消费者”，平台团队是“产品经理”。服务目录的质量直接决定了开发者自助上线的效率。
3.2 服务目录在平台工程中的角色
服务目录在平台工程中扮演着能力抽象层和治理边界的双重角色。它解决了平台团队与业务团队之间的三个核心矛盾：
- 标准化 vs 灵活性：服务目录提供“黄金路径”模板，同时允许通过参数化配置保留必要的灵活性。
- 可见性 vs 混乱：所有可用的平台能力都集中在目录中，避免开发者“不知道平台有什么”或“重复造轮子”。
- 自助 vs 管控：开发者可以自助申请，但平台团队通过目录中的策略（如配额、审批流、合规检查）实施治理。
下图展示了服务目录在平台工程架构中的核心位置：
3.3 服务目录与 CMDB 的区别
很多团队容易将服务目录与传统的配置管理数据库（CMDB）混淆。虽然两者都涉及“服务”和“配置”，但它们的定位、受众和核心功能有本质区别。
| 对比维度 | 服务目录（Service Catalog） | CMDB（配置管理数据库） |
|---|---|---|
| 核心定位 | 面向开发者的自助服务“产品货架” | 面向运维/ITIL 的配置项“资产台账” |
| 目标用户 | 业务开发者、SRE、平台消费者 | 运维工程师、变更经理、合规审计 |
| 数据粒度 | 服务单元（如流水线模板、数据库规格） | 配置项 CI（如服务器 IP、中间件版本、网络端口） |
| 操作模式 | 自助申请、一键部署、生命周期管理 | 发现、记录、关联、变更审批 |
| 变更驱动 | 开发者需求驱动（Pull 模式） | 运维事件/变更驱动（Push 模式） |
| 核心价值 | 提升开发者效率，降低平台使用门槛 | 保障配置准确性，支撑故障定位与合规 |
| 典型工具 | Backstage、Port、Humanitec、Kratix | ServiceNow CMDB、BMC Atrium、iTop |
实践建议：在平台工程落地初期，不要试图用 CMDB 替代服务目录，也不要用服务目录管理所有配置项。两者应互补共存：服务目录负责“开发者体验”，CMDB 负责“运维资产底账”。通过 API 将服务目录的实例化结果同步到 CMDB，实现“申请即记录”。
下图直观对比了服务目录与 CMDB 在平台工程中的不同作用域：
3.4 服务目录的典型构成
一个生产级的服务目录通常包含以下组成部分：
- 元数据层：服务名称、版本、所有者、标签、描述。
- 模板层：Terraform 模块、Helm Chart、Pipeline 定义、Docker Compose 文件。
- 策略层：配额限制、审批流程、合规规则、成本预算。
- 接口层：REST API、CLI 工具、Web UI、Backstage 插件。
- 观测层：服务使用统计、申请成功率、平均交付时间、错误率。
常见误区：不要将服务目录做成“静态文档”。如果目录中的服务无法通过 API 或 GitOps 方式实际创建，它只是一个“愿望清单”，而不是真正的服务目录。服务目录必须与底层基础设施即代码（IaC）引擎深度集成。