3. 服务目录平台架构：服务注册、服务发现、元数据管理、依赖关系图、健康检查与状态同步
服务目录平台是容量规划与水位评估的数据基座。它并非简单的服务列表，而是一个集注册、发现、元数据管理、依赖分析、健康感知于一体的动态知识图谱。本节将拆解其核心架构组件，并说明各组件如何为水位评估提供实时、可信的数据输入。
3.1 架构总览：五大核心能力
服务目录平台围绕五个关键能力构建，它们共同构成了从服务注册到状态同步的完整闭环：
| 能力模块 | 核心职责 | 对水位评估的价值 |
|---|---|---|
| 服务注册 | 服务实例启动时，将其网络地址、协议、版本等信息写入目录 | 提供水位评估的数据采集目标列表，确保无遗漏 |
| 服务发现 | 消费方或监控系统按服务名获取可用实例列表 | 支撑动态扩缩容感知，水位评估自动适配实例数变化 |
| 元数据管理 | 存储服务的非运行时属性：Owner、SLA、资源规格、部署环境等 | 提供水位标签与阈值上下文，区分核心/非核心服务 |
| 依赖关系图 | 记录服务间的调用链、数据流、强依赖/弱依赖关系 | 支撑级联故障影响面分析，水位异常时快速定位根因 |
| 健康检查与状态同步 | 周期性探测实例存活状态，同步至目录并触发事件 | 保证水位数据时效性与准确性，剔除已宕实例的指标 |
架构原则：服务目录平台采用“写路径与读路径分离”模式。服务注册、健康检查属于写路径，要求高可用与强一致性；服务发现、依赖查询属于读路径，要求低延迟与高并发。水位评估系统主要作为读路径的消费者，通过订阅变更事件或定时拉取获取最新目录快照。
3.2 服务注册与发现：动态实例管理
服务注册与发现是目录平台的基础能力。在云原生环境中，实例的启停、扩缩容是常态，水位评估必须感知这些变化，否则将基于过时的实例列表计算错误的水位。
注册流程（以 Kubernetes 为例）：
- 实例启动： Pod 进入 Ready 状态，kubelet 更新 EndpointSlice。
- 注册触发： 服务目录 Agent 监听 EndpointSlice 变化，提取 Pod IP、Port、Pod Name、Node Name。
- 元数据注入： Agent 从 Pod Labels/Annotations 中提取 Owner、Service Tier、CPU Request/Limit 等元数据，一并写入目录存储。
- TTL 续约： 实例定期发送心跳续约 TTL；若续约失败，目录标记实例为“失联”状态。
发现机制对比：
| 模式 | 典型实现 | 延迟 | 适用场景 |
|---|---|---|---|
| 客户端侧发现 | Eureka、Consul Client | 秒级（本地缓存+长轮询） | 微服务间 RPC 调用 |
| 服务端侧发现 | Kubernetes Service + kube-proxy | 毫秒级（iptables/IPVS） | 南北向流量、网关代理 |
| 事件驱动发现 | Etcd Watch、Kubernetes Informer | 亚秒级（Watch 回调） | 水位评估、监控系统 |
水位评估实践要点：水位评估系统应使用事件驱动发现模式订阅实例变更事件。当实例数变化时，自动触发对应服务的水位重新计算，避免定时轮询带来的数据窗口延迟。同时，需处理“实例刚注册但尚未就绪”的边界情况，建议结合 Readiness Probe 状态过滤。
3.3 元数据管理：为水位数据打标签
元数据是水位评估的“上下文”。没有元数据，CPU 利用率只是一个数字；有了元数据，才能判断这个数字是否异常、是否重要、是否需要告警。
核心元数据字段：
- 服务标识： Service Name、Namespace、Cluster、Environment（prod/staging/test）。
- 资源规格： CPU Request/Limit、Memory Request/Limit、GPU 规格、存储大小。
- 业务属性： Owner Team、Service Tier（P0/P1/P2）、SLA（99.9%/99.99%）、业务域。
- 部署属性： Deployment Strategy（rolling/blue-green）、Replicas、Pod Anti-Affinity 策略。
- 水位阈值： 自定义 CPU 高水位线（如 80%）、内存高水位线、自定义告警静默窗口。
元数据存储选型：
| 存储类型 | 优势 | 劣势 | 推荐场景 |
|---|---|---|---|
| 关系型数据库（PostgreSQL） | 强事务、支持复杂查询、关联 Join | 扩展性有限、Schema 变更成本高 | 元数据量 < 10 万条，需要复杂过滤 |
| 图数据库（Neo4j） | 天然支持依赖关系遍历、深度查询 | 运维成本高、非通用查询语法 | 依赖关系图深度分析 |
| 键值存储（Etcd） | 强一致性、Watch 机制、云原生原生 | 不适合大对象存储、查询能力弱 | 服务注册与发现元数据 |
| 对象存储 + 索引（S3 + Elasticsearch） | 海量存储、全文检索、Schema-free | 最终一致性、写入延迟较高 | 历史元数据归档、审计 |
避坑指南：元数据管理切忌“大而全”。建议采用分层存储策略：热数据（当前实例的元数据）放在 Etcd 或 Redis 中，保证毫秒级读取；温数据（历史变更记录）写入 PostgreSQL；冷数据（超过 30 天的元数据快照）归档至对象存储。水位评估的实时查询只访问热数据层。
3.4 依赖关系图：水位异常的传播链
依赖关系图是服务目录平台区别于普通注册中心的核心能力。当某个服务的水位异常时，依赖图能快速回答：“这个异常会影响哪些下游服务？上游服务的流量变化是否导致了当前水位飙升？”
依赖关系构建方式：
- 静态分析： 解析代码中的 RPC 框架注解、OpenAPI 定义、gRPC proto 文件，提取服务间调用声明。
- 动态采集： 通过 Service Mesh（Istio/Linkerd）或 APM 系统（SkyWalking/Pinpoint）采集实时调用链数据，聚合生成调用拓扑。
- 人工维护： 提供 Web UI 让开发团队手动编辑依赖关系，用于补充静态/动态分析无法覆盖的异步消息、数据流依赖。
依赖关系图的数据模型：
- 节点： 服务（Service Name + Namespace）。
- 边： 调用关系（方向、协议、平均 QPS、P99 延迟）。
- 属性： 依赖类型（强依赖/弱依赖）、超时配置、熔断阈值、重试策略。
水位评估中的应用：当服务 A 的 CPU 水位超过 90% 时，依赖图可立即展示：服务 A 的上游服务 X、Y 是否正在增加流量？服务 A 的下游服务 B、C 是否出现延迟升高？结合水位数据与依赖图，可实现根因定位：是上游流量突增导致 A 过载，还是 A 自身代码问题导致 CPU 飙升？依赖图提供了流量传播的上下文。
3.5 健康检查与状态同步：保证水位数据鲜活
健康检查是服务目录平台的数据保鲜机制。水位评估系统必须知道哪些实例是健康的、哪些已宕机，否则会将已宕实例的指标（通常为 0 或 NaN）纳入计算，导致水位失真。
健康检查策略：
| 检查层级 | 检查方式 | 检查间隔 | 失败处理 |
|---|---|---|---|
| Liveness Probe | HTTP GET /healthz 或 TCP 端口检查 | 10s | 重启容器 |
| Readiness Probe | HTTP GET /ready 或自定义脚本 | 5s | 从 Service Endpoint 中移除 |
| 服务目录心跳 | Agent 定期向目录上报 TTL | 30s | 标记为“失联”，触发告警 |
| 端到端健康检查 | 外部探针模拟真实用户请求 | 60s | 标记服务为“降级”，触发自动扩缩容 |
状态同步机制：
- 推模式： 健康检查 Agent 发现实例状态变化后，立即通过 gRPC Stream 或 Webhook 推送至目录平台。延迟最低，适合水位评估的实时性要求。
- 拉模式： 目录平台定期（如 30s）轮询所有 Agent 或 Kubernetes API，获取最新状态。实现简单，但存在数据窗口延迟。
- 混合模式： 推模式处理状态变更事件，拉模式作为兜底，定期全量同步以修复可能的数据不一致。
关键设计：状态同步必须处理“脑裂”场景。例如，网络分区导致 Agent 与目录平台断开，但实例本身健康。此时目录平台不应立即将实例标记为“宕机”，而应引入租约机制：实例续约失败后，给予一个宽限期（如 90s），宽限期内若恢复续约，则保留健康状态；超期未恢复，才标记为失联。水位评估系统在宽限期内应继续使用该实例的指标，但标记为“疑似失联”，降低其权重。
3.6 架构总览图：服务目录平台核心组件
下图展示了服务目录平台五大核心能力之间的数据流与协作关系：
3.7 状态同步时序：从实例启动到水位计算
下图以时序图形式展示一个服务实例从启动到被水位评估系统纳入计算的完整流程：
3.8 水位评估的目录数据消费模型
水位评估系统作为服务目录平台的核心消费者，其数据消费模型可概括为以下步骤：
- 订阅变更： 水位评估系统通过 Watch 机制订阅服务目录的实例变更事件（新增、删除、状态变更）。
- 拉取快照： 收到变更事件后，拉取受影响服务的完整实例列表及元数据（资源规格、水位阈值）。
- 过滤实例： 根据健康状态过滤实例，仅保留状态为“健康”的实例。对于“失联”实例，根据宽限期策略决定是否纳入计算。
- 聚合指标： 从监控系统拉取每个健康实例的 CPU、内存、网络等指标，按服务维度聚合（平均值、P99、最大值）。
- 水位判定： 将聚合指标与元数据中的水位阈值对比，生成水位等级（正常/警告/严重）。
- 写回目录： 将水位评估结果写回服务目录的元数据中，供其他系统（如告警、自动扩缩容）消费。
性能优化：水位评估系统应避免每次变更都全量拉取所有实例指标。建议采用增量计算策略：维护一个本地缓存的服务-实例-指标映射表，仅对发生变更的服务重新计算水位。对于未变更的服务，直接复用上次计算结果，并打上时间戳标记。这可将计算开销降低 90% 以上。