2. 服务画像基础：静态画像 vs 动态画像、画像的构成要素
服务画像是可观测性体系中对目标服务进行全维度数字化描述的产物。它不仅是监控指标的集合，更是服务运行状态、行为模式与依赖关系的结构化快照。理解静态画像与动态画像的区别，以及画像的构成要素，是构建异常检测模型的前提。
2.1 静态画像 vs 动态画像
根据数据来源与更新频率，服务画像可分为两类：
| 维度 | 静态画像 | 动态画像 |
|---|---|---|
| 定义 | 服务部署时确定的、相对固定的元信息 | 运行时持续采集、随时间变化的指标与状态 |
| 数据来源 | CMDB、K8s Deployment、配置文件、服务注册中心 | Prometheus、APM Agent、日志流、Trace 数据 |
| 更新频率 | 小时级 / 天级（发布或扩缩容时触发） | 秒级 / 分钟级（持续采集） |
| 典型字段 | 服务名、版本号、实例数、所属团队、技术栈 | CPU 使用率、请求延迟 P99、错误率、吞吐量 |
| 用途 | 服务拓扑构建、变更影响分析、容量规划基线 | 实时异常检测、Golden Signals 告警、弹性伸缩 |
关键认知：静态画像提供“服务应该是什么样”的基线，动态画像反映“服务现在是什么样”的实时状态。两者结合才能形成完整的服务上下文。
2.2 画像的构成要素
一个完整的服务画像由三大核心要素组成：元数据、指标、依赖关系。三者共同构成服务的“数字孪生”。
2.2.1 元数据（Metadata）
元数据是服务的“身份证”与“户口本”，描述服务是谁、属于谁、运行在哪里。
- 身份信息：服务名称、服务 ID、版本号、Git Commit SHA
- 组织归属：所属团队、负责人、On-Call 值班组、Slack/钉钉群
- 部署信息：集群名称、命名空间、Pod 副本数、容器资源 Request/Limit
- 技术栈：编程语言、框架版本、中间件类型（MySQL / Redis / Kafka）
2.2.2 指标（Metrics）
指标是服务的“体检报告”，反映服务在运行时的健康状态与性能表现。通常按 Golden Signals 分类：
| Golden Signal | 典型指标 | 异常含义 |
|---|---|---|
| 延迟 | 请求平均延迟、P50/P95/P99 延迟 | 响应变慢，可能数据库慢查询或网络拥堵 |
| 流量 | QPS、RPS、并发连接数、带宽使用率 | 流量突增或突降，可能遭受攻击或上游故障 |
| 错误 | HTTP 5xx 率、异常堆栈数、超时次数 | 代码缺陷、依赖服务不可用、配置错误 |
| 饱和度 | CPU 使用率、内存使用率、磁盘 IOPS、连接池使用率 | 资源接近瓶颈，即将引发性能退化 |
2.2.3 依赖关系（Dependencies）
依赖关系是服务的“社交网络图”，描述服务与外部系统之间的调用链路与数据流向。
- 上游依赖：调用当前服务的客户端（如 API Gateway、前端、其他微服务）
- 下游依赖：当前服务调用的外部组件（数据库、缓存、消息队列、第三方 API）
- 对等依赖：同层级服务间的 gRPC / HTTP 调用
- 基础设施依赖：DNS、负载均衡器、Service Mesh Sidecar
实践建议：依赖关系应包含调用方向、协议类型（HTTP/gRPC/Thrift）、超时配置以及熔断阈值。这些信息在异常传播链分析中至关重要。
2.3 画像的动态更新机制
动态画像的核心在于持续更新。更新机制通常包含以下步骤：
- 数据采集：通过 Agent 或 Exporter 从服务实例拉取指标、日志、Trace。
- 特征提取：从原始数据中提取关键特征（如 P99 延迟、错误率趋势斜率）。
- 画像合并：将新数据与历史画像进行加权融合，生成最新快照。
- 基线更新：根据滑动窗口（如过去 7 天同一时段）重新计算动态基线。
- 依赖刷新：通过 Service Mesh 或 Trace 数据自动发现新增/移除的依赖关系。
注意：动态画像的更新频率需要与异常检测的灵敏度匹配。更新太慢（如 5 分钟一次）可能漏检突发故障；更新太快（如 1 秒一次）可能引入过多噪声。建议根据业务场景设置 10s~60s 的采集间隔。
2.4 画像在异常检测中的角色
服务画像为 Golden Signals 异常检测提供了上下文锚点：
- 静态画像提供“正常时服务应该长什么样”的参照系（如实例数、资源配额）。
- 动态画像提供“当前服务正在经历什么”的实时数据流。
- 依赖关系帮助定位异常是否由上游或下游传播引起，避免误报。