3. 服务目录平台架构：整体架构图、核心模块与数据流
服务目录平台作为容量水位巡检的元数据中心与调度枢纽，其架构设计直接决定了巡检数据的完整性、实时性与可扩展性。本章从整体架构、核心模块、数据流三个维度展开，帮助学员建立平台级视角。
3.1 平台整体架构图
服务目录平台采用分层架构，自上而下分为：接入层、服务层、数据层与基础设施层。各层职责清晰，通过标准 API 与消息队列解耦。
3.2 核心模块详解
服务目录平台包含三个核心模块，它们共同构成了容量水位巡检的数据底座与调度中枢。
3.2.1 服务注册模块
服务注册模块负责维护所有被纳管服务的实例清单与运行状态。它是容量巡检的“服务发现”基础。
- 实例注册：服务启动时通过 SDK 或 Sidecar 向目录平台上报实例 IP、端口、协议、启动时间。
- 健康检查：支持主动探测（HTTP/TCP/gRPC）与被动心跳两种模式，异常实例自动标记并触发告警。
- 状态变更推送：实例上下线、健康状态变化通过消息队列实时推送给下游巡检引擎。
3.2.2 元数据管理模块
元数据管理模块是服务目录的“知识图谱”，存储服务的业务属性、技术属性与关联关系。
| 元数据类别 | 典型字段 | 用途 |
|---|---|---|
| 基础属性 | 服务名称、owner、部门、环境（prod/staging） | 权限管控、告警分派 |
| 容量属性 | CPU 配额、内存限制、副本数、QPS 基线 | 水位阈值计算、扩缩容决策 |
| 依赖关系 | 上游服务、下游 DB/缓存、外部 API | 故障影响面分析、容量链路追踪 |
| 版本与标签 | Git 版本、镜像 Tag、自定义标签（如“核心链路”） | 灰度发布、巡检策略匹配 |
3.2.3 监控集成模块
监控集成模块负责对接各类监控系统，将原始指标转化为服务目录可理解的容量水位数据。
- 数据源适配器：支持 Prometheus、Grafana、Zabbix、自研监控系统等数据源，通过插件化方式扩展。
- 指标映射：将监控系统中的 metric 名称（如
container_cpu_usage_seconds_total）映射为服务目录的统一指标模型（如cpu_usage_percent）。 - 数据拉取与缓存：按可配置周期（如 1 分钟）拉取指标，写入 Redis 缓存，避免重复查询监控系统。
实践建议：监控集成模块应设计为“无侵入”模式——不要求被监控服务安装任何 Agent，仅通过标准 API 拉取已有监控数据，降低接入成本。
3.3 数据流与交互关系
服务目录平台的数据流分为注册流、元数据流与监控数据流三条主线，它们最终汇聚到容量水位巡检引擎。
3.4 交互关系总结
下表梳理了三个核心模块之间的交互关系与数据依赖：
| 交互对 | 交互方式 | 数据内容 | 触发条件 |
|---|---|---|---|
| 服务注册 → 元数据管理 | RPC 调用 / MQ 事件 | 实例 ID、服务名、IP、端口 | 实例注册/注销时 |
| 元数据管理 → 监控集成 | API 查询 | 服务容量属性、阈值配置 | 巡检周期开始前 |
| 监控集成 → 服务注册 | 无直接交互 | — | — |
| 服务注册 → 巡检引擎 | MQ 事件 / 定时拉取 | 实例列表、健康状态 | 实例变更或定时触发 |
| 元数据管理 → 巡检引擎 | API 查询 | 服务属性、依赖关系、阈值 | 巡检引擎初始化或策略更新 |
| 监控集成 → 巡检引擎 | 缓存读取 | CPU/内存/磁盘/网络指标 | 每个巡检周期 |
架构要点：服务目录平台通过“注册流”保证巡检目标实时准确，通过“元数据流”实现巡检策略动态化，通过“监控数据流”确保水位数据及时可用。三条数据流在巡检引擎中完成汇聚，形成完整的容量水位巡检闭环。