服务画像建模驱动基础设施即代码SLI口径映射方法 - 第2节
2.1 服务画像的定义
服务画像（Service Profile）是对一个微服务或应用组件在运行态的完整数字化描述。它并非静态的配置清单，而是将服务的元数据、依赖关系、拓扑结构、运行时特征四类信息聚合为一个可查询、可演化的模型。服务画像的核心价值在于：为基础设施即代码（IaC）的 SLI 口径映射提供唯一的、语义一致的“锚点”。
2.2 组成要素
服务画像由四个核心要素构成，缺一不可。下表总结了每个要素的定义、典型内容及其在 SLI 口径映射中的作用。
| 要素 | 定义 | 典型内容 | SLI 口径映射作用 |
|---|---|---|---|
| 元数据 | 服务的静态身份与属性信息 | 服务名、版本、owner、Git 仓库、语言栈、框架版本 | 确定 SLI 标签（如 service.name, version） |
| 依赖 | 服务运行所依赖的外部资源 | 数据库、消息队列、缓存、第三方 API、配置中心 | 定义依赖型 SLI（如 DB 延迟、MQ 堆积） |
| 拓扑 | 服务在分布式系统中的连接关系 | 上游调用方、下游被调方、网络协议、端口、负载均衡 | 映射调用链 SLI（如 P99 延迟、错误率） |
| 运行时特征 | 服务在特定环境下的动态行为数据 | CPU/内存/IO 画像、QPS 基线、GC 模式、连接池水位 | 校准资源型 SLI（如 CPU 饱和度、内存使用率） |
2.2.1 元数据（Metadata）
元数据是服务画像的“身份层”。在 IaC 场景中，元数据直接决定了 SLI 的标签体系。例如，同一个服务部署在 staging 和 production 环境，其元数据中的 environment 字段不同，SLI 口径会自动映射到对应的监控视图。
# 服务元数据示例（YAML 格式）
service:
name: "order-service"
version: "2.1.0"
owner: "team-payment"
repository: "git@gitlab.internal:backend/order-service.git"
language: "java"
framework: "spring-boot 2.7"
environment: "production"2.2.2 依赖（Dependencies）
依赖刻画了服务的“生存条件”。每个依赖项都应包含资源类型、连接方式、健康检查端点。依赖信息直接驱动 IaC 生成对应的依赖健康 SLI，例如：mysql:3306 的连通性 SLI、redis:6379 的缓存命中率 SLI。
- 基础设施依赖：MySQL、PostgreSQL、Redis、Kafka、Elasticsearch
- 应用依赖：内部 gRPC 服务、REST API、配置中心（Consul/Nacos）
- 外部依赖：第三方支付网关、CDN、DNS
2.2.3 拓扑（Topology）
拓扑是服务的“社交网络图”。它记录了服务之间的调用关系和数据流向。拓扑信息是构建调用链 SLI（如上游请求量、下游错误率）的基础。在 IaC 中，拓扑通常通过 Service Mesh 或注册中心自动发现，并同步到服务画像。
2.2.4 运行时特征（Runtime Characteristics）
运行时特征是服务的“健康基线”。它描述了服务在正常负载下的资源消耗和行为模式。这些特征用于设定 SLI 的阈值和告警基线。例如，如果画像显示某服务的 CPU 基线是 20%，那么当 CPU 持续超过 60% 时，IaC 会自动标记为“饱和度异常”。
- 资源基线：CPU 平均使用率、内存 RSS、磁盘 IOPS、网络带宽
- 流量基线：QPS 均值、P99 延迟、并发连接数
- 行为特征：JVM GC 频率与耗时、连接池活跃数、线程池队列深度
2.3 画像的粒度
服务画像的粒度决定了 SLI 口径的精细程度。粒度过粗会导致口径模糊，粒度过细则增加维护成本。通常分为三个层级：
| 粒度层级 | 描述 | 适用场景 | SLI 口径示例 |
|---|---|---|---|
| 服务级 | 整个微服务作为一个画像单元 | 小型服务、无状态服务、边缘服务 | order-service:http_latency_p99 |
| 实例级 | 每个 Pod/容器/VM 实例独立画像 | 有状态服务、金丝雀发布、A/B 测试 | order-service-v2:pod-abc:cpu_usage |
| 接口级 | 按 API 端点或 gRPC 方法细分 | 核心链路、高流量接口、SLA 敏感接口 | order-service:POST /api/orders:error_rate |
2.4 画像的生命周期
服务画像不是一成不变的，它伴随服务的整个生命周期持续演化。理解生命周期有助于设计 IaC 的自动同步策略。
- 创建（Create）：服务首次部署时，由 IaC 流水线自动生成初始画像，包含元数据和基础依赖。
- 同步（Sync）：运行时特征和拓扑通过可观测性平台（如 Prometheus、Jaeger）定期更新，保持画像与真实运行状态一致。
- 变更（Change）：当服务版本升级、依赖变更、拓扑调整时，画像触发更新事件，IaC 重新计算 SLI 口径。
- 归档（Archive）：服务下线后，画像保留一定周期（如 90 天）用于历史回溯，之后自动归档。
2.5 画像与 IaC SLI 口径的映射关系
服务画像的每个要素都直接对应 IaC 中 SLI 口径的某个维度。理解这种映射关系是课程的核心。
- 元数据 → 标签：服务名、版本、环境直接作为 Prometheus 或 OpenTelemetry 的 label。
- 依赖 → 资源 SLI：每个依赖项生成一个独立的 SLI 定义，如
mysql_query_duration_seconds。 - 拓扑 → 调用链 SLI：上下游关系决定 SLI 的 source 和 target 标签。
- 运行时特征 → 阈值：基线数据用于设定 SLI 的告警阈值和饱和度计算。