1. 课程导论：服务画像的定义、为什么需要动态更新、Golden Signals 四指标简介
1.1 服务画像的定义
服务画像（Service Profile）是对一个微服务或应用在正常运行时表现出的多维特征集合的数字化描述。它不仅仅是静态的元数据（如服务名、版本、实例数），更包含了动态的行为基线，例如请求速率、错误率、延迟分布、资源消耗模式等。
一个完整的服务画像通常包含以下维度：
| 维度 | 描述 | 示例指标 |
|---|---|---|
| 标识层 | 服务的基础身份与拓扑信息 | 服务名、命名空间、依赖的上游/下游服务 |
| 流量层 | 服务接收与发出的请求特征 | QPS、请求来源分布、请求体大小 |
| 性能层 | 服务的响应能力与资源效率 | P50/P99 延迟、CPU 利用率、内存占用 |
| 健康层 | 服务的错误与稳定性状态 | 错误率、熔断状态、健康检查通过率 |
| 行为层 | 服务随时间变化的模式规律 | 日间高峰时段、周期性批处理窗口 |
核心观点：服务画像 = 静态元数据 + 动态行为基线。没有画像的监控，就像没有地图的导航——你只能看到数字在跳，却不知道“正常”应该是什么样子。
1.2 为什么需要动态更新
传统的静态阈值告警（如“CPU > 80% 告警”）在当今的动态基础设施中已严重失效。服务画像必须动态更新，原因如下：
- 基础设施波动：Kubernetes 的 Pod 扩缩容、节点迁移、Spot 实例中断，都会导致服务实例的资源配置和负载特征发生剧烈变化。
- 流量模式漂移：业务促销、A/B 测试、新版本上线，会改变请求的分布和速率基线。昨天的“高峰”可能是今天的“低谷”。
- 依赖关系变化：服务拓扑并非一成不变。新服务加入、旧服务下线、数据库迁移，都会影响当前服务的延迟和错误特征。
- 季节性规律：许多业务具有明显的日、周、月周期性。静态基线无法区分“凌晨 3 点的低流量”和“下午 3 点的高流量”哪个是异常。
动态更新的价值：通过持续学习最近窗口（如过去 1 小时、24 小时、7 天）的指标数据，自动调整服务画像的基线，使异常检测能自适应环境变化，大幅降低误报和漏报。
1.3 Golden Signals 四指标简介
Google SRE 经典著作《Site Reliability Engineering》中提出了监控分布式系统的四个黄金信号（Golden Signals）。它们是构建服务画像动态基线的核心数据源：
- 延迟（Latency）：请求处理所花费的时间。关键是要区分成功请求的延迟和失败请求的延迟（失败请求可能返回得很快，但掩盖了真正的性能问题）。
- 流量（Traffic）：系统服务的请求量级。对于 Web 服务通常是 HTTP 请求数/秒（QPS）；对于数据库可能是查询速率或写入速率。
- 错误（Errors）：请求失败的速率。包括显式错误（HTTP 5xx、4xx）和隐式错误（返回 200 OK 但业务逻辑错误，如“商品库存不足”）。
- 饱和度（Saturation）：系统资源被使用的程度。最常关注 CPU、内存、磁盘 I/O、网络带宽，以及更上层的指标如线程池使用率、数据库连接池占用率。
下表总结了四指标在服务画像中的角色与典型基线更新方式：
| Golden Signal | 画像中的角色 | 动态基线示例 |
|---|---|---|
| 延迟 | 用户体验的直接反映 | P99 延迟的移动平均 ± 2σ 作为上下界 |
| 流量 | 负载压力的量化指标 | 按小时分桶的 QPS 历史分位数（P5 ~ P95） |
| 错误 | 服务健康的核心告警源 | 错误率相对于总流量的比例基线（如 < 0.1%） |
| 饱和度 | 容量规划的决策依据 | CPU 利用率在相同流量级别下的回归基线 |
1.4 服务画像动态更新与 Golden Signals 的关系
下图展示了服务画像动态更新的核心流程，以及 Golden Signals 四指标如何作为输入驱动基线计算与异常检测：
实践提醒：不要试图一次性为所有指标建立动态基线。建议从 延迟 和 错误率 这两个最直接影响用户体验的信号开始，逐步扩展到流量和饱和度。先做精一个信号，再横向复制经验。
1.5 本章小结
- 服务画像是服务的多维数字化描述，包含标识、流量、性能、健康和行为五个层次。
- 动态更新是应对基础设施波动、流量漂移、依赖变化和季节性规律的必要手段，能显著降低误报。
- Golden Signals（延迟、流量、错误、饱和度）是构建动态基线的四大核心数据源，它们共同覆盖了用户体验、负载压力、系统健康和容量瓶颈四个关键视角。