3. 服务注册与发现机制：服务定义、版本管理、元数据管理、健康检查与自动发现

服务目录平台的核心价值在于为微服务提供一套动态、可靠、可治理的注册与发现机制。本章将深入剖析服务定义模型、版本管理策略、元数据管理方案、健康检查机制以及自动发现流程，帮助学员构建对服务目录数据平面与控制平面的完整认知。

3.1 服务定义模型

服务定义是服务目录的原子单元，它描述了服务对外暴露的接口、协议、网络位置以及治理策略。一个标准化的服务定义通常包含以下核心字段：

3.2 版本管理策略

服务目录需要支持多版本共存，以应对灰度发布、蓝绿部署、A/B 测试等场景。版本管理通常采用语义化版本控制（SemVer），格式为 MAJOR.MINOR.PATCH：

• MAJOR：不兼容的 API 变更，需触发消费者适配。
• MINOR：向下兼容的功能新增。
• PATCH：向下兼容的问题修复。

在服务目录中，版本管理的关键操作包括：

1. 版本注册：新版本上线时，向目录注册完整服务定义。
2. 版本路由：消费者通过请求头或服务名后缀指定目标版本。
3. 版本废弃：标记旧版本为 deprecated，保留元数据但不再参与自动发现。
4. 版本归档：超过保留周期的版本自动移入冷存储。

3.3 元数据管理

元数据是服务定义的扩展层，用于承载业务属性、运维标签、治理策略等非结构化信息。元数据管理需满足以下要求：

• 可扩展性：支持任意键值对，无需预定义 schema。
• 可查询性：支持按元数据标签进行服务发现过滤。
• 可继承性：服务级元数据可继承自命名空间级默认元数据。

常见的元数据分类示例：

3.4 健康检查与自动发现

健康检查是服务目录自愈能力的基石。服务实例必须定期向目录上报存活状态，目录根据检查结果动态调整可用端点列表。

3.4.1 健康检查模式

• 主动检查（Probe）：目录定期向服务实例发起 HTTP/TCP/gRPC 探针，根据响应判断健康状态。
• 被动检查（Heartbeat）：服务实例主动向目录发送心跳包，目录在超时窗口内未收到心跳则标记为不健康。
• 混合模式：同时启用主动与被动检查，兼顾实时性与可靠性。

3.4.2 自动发现流程

自动发现是消费者从服务目录获取可用服务实例的过程，其核心步骤包括：

1. 服务订阅：消费者向目录注册对特定服务名+版本的监听。
2. 端点推送：目录将当前健康端点列表推送给消费者（Push 模式）或等待消费者拉取（Pull 模式）。
3. 增量更新：当端点发生变更（新增/移除/状态变化）时，目录仅推送差异数据，减少网络开销。
4. 本地缓存：消费者在本地维护一份端点缓存，并设置 TTL，防止目录短暂不可用导致服务中断。

3.5 服务目录架构总览

综合以上机制，服务目录平台的逻辑架构可抽象为以下分层：

• 注册层：接收服务实例的注册、注销、心跳请求，写入后端存储。
• 存储层：持久化服务定义、版本、元数据、健康状态，通常使用分布式 KV 存储（如 etcd、Consul）。
• 发现层：处理消费者的订阅与查询请求，返回健康端点列表，支持 Push/Pull 双模式。
• 健康检查层：调度主动探针、处理心跳超时，更新实例状态。
• 治理层：基于元数据执行路由、限流、熔断等策略。

3.6 关键设计考量