2、服务目录平台核心概念：服务注册、服务版本、服务依赖、服务元数据、运行基线的定义

服务目录平台是组织内部所有可复用数字服务的“统一注册中心”与“运行状态总览”。要理解平台如何支撑运行基线核验与多团队签名证据交接，首先需要掌握其五大核心概念：服务注册、服务版本、服务依赖、服务元数据与运行基线。这五个概念共同构成了服务目录的数据模型与生命周期管理基础。

2.1 服务注册

服务注册是服务进入目录的第一道门。每个服务实例或服务提供单元在部署上线时，必须向目录平台注册其基本信息与访问端点。注册行为通常由 CI/CD 流水线或服务网格控制面自动触发，也可由平台工程师手动录入。

服务注册的核心要素包括：

• 服务唯一标识（Service ID）：全局唯一，通常采用 UUID 或 命名空间:服务名 格式。
• 端点信息（Endpoint）：gRPC 地址、HTTP URL、消息队列 Topic 等。
• 协议与接口契约：Proto 文件、OpenAPI 规范、AsyncAPI 文档。
• 所属团队与负责人：用于后续的签名证据交接与责任追溯。
• 注册时间与注册源：记录注册流水线 ID 或操作者身份。

2.2 服务版本

服务版本管理是目录平台支持灰度发布、回滚与多版本共存的基础。每个服务注册后，其每一次变更（代码、配置、依赖）都应产生一个新的版本记录。版本号通常遵循 语义化版本规范（SemVer）：主版本号.次版本号.修订号。

服务版本的关键属性：

• 版本号：如 v2.1.0，必须唯一且递增。
• 版本状态：开发中、测试中、已发布、已废弃。
• 版本快照：包含该版本对应的代码 Commit、容器镜像 Digest、配置文件 Hash。
• 版本签名：由发布流水线或负责人对版本元数据进行数字签名，形成证据。
• 兼容性标记：向前兼容、向后兼容、破坏性变更。

# 服务版本注册示例（JSON）
{
  "service_id": "payment-svc",
  "version": "2.1.0",
  "status": "released",
  "semver": {
    "major": 2,
    "minor": 1,
    "patch": 0
  },
  "artifact_digest": "sha256:a1b2c3d4e5f6...",
  "signature": "MEUCIQDQ...",
  "compatibility": "backward_compatible",
  "release_timestamp": "2025-03-15T10:30:00Z"
}

2.3 服务依赖

服务依赖描述了服务之间的调用关系与数据流。在微服务架构中，一个服务通常依赖多个下游服务（数据库、缓存、消息队列、其他业务服务）。服务目录必须显式记录这些依赖，才能构建完整的运行基线拓扑。

服务依赖的表示方式：

• 直接依赖：服务 A 调用服务 B 的 API。
• 间接依赖：服务 A 通过服务 B 调用服务 C。
• 可选依赖：服务降级时可忽略的依赖。
• 强依赖：缺失会导致服务不可用。

2.4 服务元数据

服务元数据是附着在服务注册、版本、依赖之上的描述性信息与标签，用于搜索、分类、策略绑定与审计追溯。元数据通常以键值对（Key-Value）或结构化文档形式存储。

常见的元数据分类：

2.5 运行基线

运行基线是服务目录平台中最核心的合规与运维概念。它定义了一个服务在特定环境（如生产环境）下，应该处于的“标准运行状态”。运行基线由服务注册信息、特定版本、依赖版本范围、元数据约束以及合规策略共同构成。

运行基线的组成要素：

• 基线标识：如 payment-svc:production:v2.1.0-baseline。
• 目标服务与版本：指定哪个服务的哪个版本应遵循此基线。
• 依赖版本锁定：所有依赖服务必须处于指定的版本范围内。
• 配置与参数快照：环境变量、启动参数、Feature Flag 状态。
• 合规策略集：必须满足的安全扫描、漏洞修复、签名验证等条件。
• 签名证据要求：基线本身需要由合规审计团队或平台负责人签名。

2.6 五大概念的关系总结

这五个核心概念并非孤立存在，而是构成了一个相互关联的数据模型：