2. 服务画像定义：什么是服务画像，包含哪些核心元数据
服务画像是可观测性体系中用于描述一个微服务在某一时刻运行态全貌的元数据快照。它不同于静态的 CMDB 或部署清单，而是从实例、版本、配置、依赖四个维度实时聚合而成的动态数字孪生。当服务画像发生变更时，原有的 SLI 口径可能不再适用，需要触发重算。
2.1 服务画像的核心作用
- 基线锚定：为 SLI/SLO 提供“当前服务是什么状态”的上下文，避免口径漂移。
- 变更感知：通过对比前后画像差异，自动识别实例扩缩、版本升级、配置修改、依赖切换等事件。
- 口径重算触发器：只有画像变更达到阈值时，才启动 SLI 口径重算，避免无效计算。
关键认知：服务画像不是一次性的静态文档，而是随服务生命周期持续更新的运行时元数据集合。每次部署、扩缩容、配置变更都会产生一个新的画像版本。
2.2 服务画像核心元数据
服务画像由以下四类元数据构成，每一类都直接影响 SLI 口径的适用性：
| 元数据类别 | 核心字段 | 对 SLI 口径的影响 |
|---|---|---|
| 实例数 | 实例 ID、Pod IP、可用区、健康状态、启动时间 | 实例数变化导致请求分布变化，影响成功率、延迟分位数口径 |
| 版本 | 代码版本号、镜像 Tag、Git Commit、构建时间 | 版本升级可能引入新逻辑，原有错误码/延迟阈值口径需重新校准 |
| 配置 | 配置项 Key-Value、配置版本、生效范围、灰度比例 | 配置变更（如超时时间、熔断阈值）直接改变 SLI 采集逻辑 |
| 依赖 | 上游服务名、下游服务名、中间件地址、调用协议 | 依赖拓扑变化导致链路追踪口径失效，需重新定义依赖 SLI |
2.3 服务画像结构图
下图展示了服务画像的四个核心元数据层及其与 SLI 口径的关系：
2.4 元数据变更场景与 SLI 口径影响
以下列举四种典型变更场景，说明画像变更如何触发 SLI 口径重算：
| 变更类型 | 画像变化 | SLI 口径调整示例 |
|---|---|---|
| 实例扩缩容 | 实例数从 3 变为 5 | 延迟 P99 口径需按新实例数重新分桶，避免冷启动实例拉高延迟 |
| 版本升级 | v1.2.3 → v2.0.0 | 错误码映射表变更，原有 5xx 口径需重新定义错误边界 |
| 配置变更 | 超时时间 5s → 10s | 超时 SLI 阈值从 5s 调整为 10s，否则大量请求被误判为超时 |
| 依赖切换 | 数据库从 MySQL 切到 TiDB | 依赖延迟口径需重新采集新存储的响应时间分布 |
2.5 服务画像的版本化与快照
每次画像变更都会生成一个带时间戳的画像快照，用于后续对比和回滚：
{
"service": "order-service",
"snapshot_id": "snap-20250321-001",
"timestamp": "2025-03-21T10:30:00Z",
"instances": {
"count": 5,
"list": ["pod-a", "pod-b", "pod-c", "pod-d", "pod-e"]
},
"version": {
"code": "v2.0.0",
"commit": "a1b2c3d4",
"image": "order-service:2.0.0"
},
"config": {
"timeout_ms": 10000,
"retry_count": 3
},
"dependencies": {
"upstream": ["api-gateway"],
"downstream": ["user-service", "payment-service", "inventory-service"]
}
}
实践要点：服务画像快照应存储在时序数据库或对象存储中，保留至少 30 天历史。当 SLI 口径重算后出现异常时，可通过回退到历史画像快照来恢复原有口径。
2.6 画像变更检测的触发条件
并非所有元数据变化都需要触发 SLI 口径重算。以下条件用于过滤无效变更：
- 实例数变化 ≥ 20%：小幅度波动（如 3→4）可忽略，避免频繁重算。
- 版本号 Major 或 Minor 变更：Patch 版本（如 v1.0.0→v1.0.1）通常不触发重算。
- 配置项涉及 SLI 相关参数：如超时、重试、熔断阈值变更才触发。
- 依赖拓扑新增或删除：仅依赖地址变更不触发，新增/删除服务才触发。
注意：过度触发 SLI 口径重算会导致系统震荡。建议为每类变更设置独立的触发阈值，并在重算前进行画像差异预检，确认变更确实影响 SLI 口径后再执行重算。