1. 课程导论：服务目录与资源健康检测的背景、目标与整体架构概览

1.1 为什么需要服务目录资源健康检测？

在微服务和云原生架构大规模普及的今天，一个中型企业往往管理着数百甚至上千个微服务、中间件、数据库和基础设施组件。运维团队面临的典型困境是：告警太多，但有效信息太少。Prometheus 虽然能够采集海量指标并触发告警，但告警事件与具体的业务服务、负责人、依赖关系之间缺乏关联，导致故障排查时不得不手动翻阅 CMDB 或 Wiki，效率极低。

服务目录（Service Catalog）正是为了解决这一痛点而引入的抽象层。它将 Prometheus 的原始指标和告警事件，映射到有业务含义的服务实体上，从而实现告警即服务的闭环管理。

1.2 方案目标

本课程设计的《服务目录资源健康检测方案》旨在达成以下四个核心目标：

1.3 整体架构概览

下图展示了本方案的核心架构分层与数据流转关系。整个体系分为数据采集层、服务目录层、告警引擎层和消费展示层四个部分。

1.4 核心数据流与关键组件

为了更清晰地展示数据在服务目录与 Prometheus 之间的流转关系，下图以服务注册 → 规则生成 → 告警触发 → 健康评分为主线，描述了完整的闭环流程。

1.5 方案关键设计原则

• 声明式服务定义： 每个服务通过 YAML 或 JSON 声明其名称、负责人、标签、依赖服务、健康检测阈值，避免硬编码。
• 规则模板化： 预定义 CPU、内存、延迟、错误率等通用告警模板，服务只需选择模板并传入参数，无需手写 PromQL。
• 健康评分量化： 基于 SLO（服务等级目标）和错误预算（Error Budget）计算服务健康评分，评分范围 0~100，直观反映服务状态。
• 告警关联与降噪： 利用服务目录的依赖关系，自动对下游服务的告警进行抑制或聚合，避免告警风暴。

1.6 适用场景