4. 服务目录存储选型：基于数据库、基于 Git、基于专用工具的对比
服务目录的存储层决定了数据的一致性模型、变更审计能力以及与现有工具链的集成成本。当前主流方案可归纳为三类：关系型数据库（PostgreSQL）、基于 Git 的 YAML 文件、专用工具（Backstage / ServiceNow）。本章从数据模型、变更流程、查询性能、多环境同步四个维度进行对比，并给出选型决策树。
4.1 三类存储方案的核心差异
| 维度 | PostgreSQL（数据库） | Git + YAML（文件） | Backstage / ServiceNow（专用工具） |
|---|---|---|---|
| 数据模型 | 关系表 + JSONB，强 Schema | YAML 结构，弱 Schema | 预定义实体模型 + 自定义字段 |
| 变更审计 | 行级审计日志 / 触发器 | Git Commit + PR 审批 | 内置变更记录 + 审批工作流 |
| 查询能力 | SQL 聚合、关联、全文检索 | 需 grep / yq / 外部索引 | REST API / GraphQL 查询 |
| 多环境同步 | 逻辑复制 / 流复制 | Git Branch + Merge | 环境隔离空间 / 同步插件 |
| 离线可用 | 依赖数据库连接 | 本地 Git 仓库完全离线 | 依赖 SaaS 或本地部署 |
| 典型延迟 | 毫秒级写入 | 秒级（CI 触发后） | 毫秒级（API 写入） |
关键权衡： 数据库方案适合高频查询、强一致性场景；Git 方案适合声明式、审计驱动的平台工程团队；专用工具在开箱即用体验上最优，但定制成本较高。
4.2 方案一：PostgreSQL —— 关系型服务目录
将服务元数据存储在 PostgreSQL 中，利用 JSONB 字段存储可变属性，通过外键关联团队、环境、依赖关系。典型表结构如下：
-- 服务主表
CREATE TABLE services (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(128) NOT NULL UNIQUE,
owner_team VARCHAR(64),
metadata JSONB DEFAULT '{}',
created_at TIMESTAMPTZ DEFAULT now()
);
-- 服务依赖关系表
CREATE TABLE service_dependencies (
source_id UUID REFERENCES services(id),
target_id UUID REFERENCES services(id),
type VARCHAR(32) DEFAULT 'runtime',
PRIMARY KEY (source_id, target_id)
);
实践建议： 使用
pg_audit 扩展记录所有 DML 变更；配合 NOTIFY/LISTEN 机制实时推送目录变更事件到 CI/CD 流水线。
4.3 方案二：Git + YAML —— 声明式服务目录
每个服务对应一个 YAML 文件，存放在 Git 仓库中。变更通过 Pull Request 触发 CI 校验，合并后自动同步到运行时。典型文件结构：
# services/payment-service.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
annotations:
github.com/project-slug: org/payment-service
spec:
type: service
lifecycle: production
owner: team-finance
dependsOn:
- component:default/account-db
- resource:default/redis-cluster
避坑： 当服务数量超过 500 时，纯 YAML 方案的查询性能会显著下降。建议引入
treefmt 统一格式化，并使用 yq 或 jq 在 CI 中做批量校验。
4.4 方案三：专用工具 —— Backstage 与 ServiceNow
Backstage（开源）和 ServiceNow（商业）提供了预构建的服务目录模型、搜索索引和权限体系。Backstage 使用 SQLite/PostgreSQL 作为后端存储，ServiceNow 使用自家 CMDB 引擎。
| 特性 | Backstage | ServiceNow |
|---|---|---|
| 部署方式 | 自托管 Kubernetes | SaaS / 本地部署 |
| 实体模型 | Component / Resource / API / System | CI / CMDB / 业务服务 |
| CI/CD 集成 | 插件市场 + 自定义处理器 | REST API + Flow Designer |
| 许可成本 | Apache 2.0 免费 | 按节点/用户订阅 |
选型倾向： 若团队已有 Kubernetes 运维能力且需要高度定制，选 Backstage；若企业已有 ServiceNow 合规流程且预算充足，选 ServiceNow；若团队规模小于 50 人且追求极简，优先考虑 Git + YAML。
4.5 存储选型决策流程
下图展示了从团队规模、查询频率、审计要求三个维度出发的选型决策路径：
4.6 混合存储策略（进阶）
大型平台工程团队通常采用混合存储：以 Git 仓库作为单一事实源（Source of Truth），通过 CI 流水线将 YAML 解析后写入 PostgreSQL 作为查询加速层。架构示意如下：
实践案例： 某中型互联网团队采用 GitLab + Backstage 插件，将 200+ 微服务的 YAML 定义存储在 monorepo 中，合并到 main 分支后自动触发 GitLab CI，调用 Backstage API 更新 PostgreSQL 中的目录索引。开发者门户查询延迟从 2 秒降至 50 毫秒。
4.7 选型总结清单
- PostgreSQL：适合需要复杂关联查询、实时变更通知、已有数据库运维经验的团队。
- Git + YAML：适合强调审计合规、声明式管理、多环境 GitOps 流程的团队。
- Backstage：适合需要开箱即用开发者门户、插件生态丰富、Kubernetes 原生集成的团队。
- ServiceNow：适合大型企业、已有 ServiceNow 合规流程、预算充足的团队。
- 混合策略：Git 作为事实源 + PostgreSQL 作为查询层，兼顾审计与性能，是平台工程团队的主流选择。