服务目录API集成与平台门户基线校验 - 第1节
1.1 Service Catalog 定义
Service Catalog（服务目录）是云平台中面向最终用户和运维团队提供的标准化服务清单。它将底层复杂的资源编排、网络配置、中间件部署等操作封装为可被直接请求和消费的“服务项”，用户无需关心实现细节，只需通过门户选择所需服务并提交请求即可。
核心定义：Service Catalog 是一组经过审批、版本化、可重复部署的云服务模板集合，配合自动化引擎实现服务的“请求—审批—交付—回收”全生命周期管理。
1.2 核心价值
| 价值维度 | 说明 | 典型场景 |
|---|---|---|
| 标准化 | 消除“手工配置漂移”，所有服务按统一模板交付 | 开发环境统一使用 CentOS 7.9 + JDK 11 镜像 |
| 自助化 | 用户通过门户自行选择、配置并申请服务，无需联系管理员 | 业务线自助申请 4C8G 云主机，30 秒内完成 |
| 治理合规 | 内置审批流、配额限制、标签策略，确保资源合规使用 | 生产环境必须经二级审批且绑定安全组 |
| 效率提升 | 从“天级”人工交付变为“分钟级”自动化交付 | 数据库实例创建从 2 天缩短至 15 分钟 |
| 成本可追溯 | 每笔服务请求关联项目/成本中心，便于费用分摊 | 月度账单按部门展示资源消耗明细 |
1.3 在云平台中的角色
Service Catalog 在云平台整体架构中处于“承上启下”的关键位置：
- 对上：对接云门户/自服务界面，提供统一的 API 接口供前端调用。
- 对中：管理服务模板、版本、参数、审批策略和配额规则。
- 对下：调用编排引擎（如 Terraform、Ansible、CloudFormation）或直接调用 IaaS/PaaS API 完成资源创建。
1.4 与 CMDB 的关系
CMDB（配置管理数据库）是记录 IT 环境中所有配置项（CI）及其关系的数据库。Service Catalog 与 CMDB 之间是“事前定义”与“事后记录”的协作关系：
| 对比维度 | Service Catalog | CMDB |
|---|---|---|
| 定位 | 服务交付的“蓝图”和“入口” | 服务运行后的“资产台账” |
| 数据产生时机 | 服务申请前（模板定义阶段） | 服务交付后（实例运行阶段） |
| 核心数据 | 服务模板、参数、版本、审批策略 | 主机、数据库、中间件、网络等 CI 及其关系 |
| 变更驱动 | 用户请求触发服务创建/变更 | 自动发现或 Service Catalog 回调更新 |
| 典型交互 | 用户选择“MySQL 5.7 主从”模板并提交 | 记录该实例的 IP、端口、版本、所属项目 |
最佳实践：Service Catalog 在完成资源交付后，应通过回调接口或消息队列将实例信息（IP、主机名、规格、标签）自动写入 CMDB，确保 CMDB 数据实时准确。反之，CMDB 中的资源生命周期状态（如“已回收”）也应反馈给 Service Catalog，避免已释放的服务仍被展示为可用。
常见误区：不要试图用 Service Catalog 替代 CMDB，也不要将 CMDB 作为服务模板的存储库。两者职责不同：Catalog 管“怎么建”，CMDB 管“建了什么”。混淆职责会导致模板管理混乱、配置项数据失真。