2. 服务画像基础：什么是服务画像、画像的构成要素与采集方式
2.1 服务画像的定义
服务画像（Service Profiling）是对一个在线服务系统在特定时间窗口内的运行特征、行为模式与资源消耗进行结构化建模的过程。它不是简单的监控指标罗列，而是将服务视为一个“活体”，通过多维度数据抽象出其在正常与异常状态下的数字孪生轮廓。
在 Error Budget 量化容量水位的语境下，服务画像承担着“基准锚点”的角色——只有准确刻画了服务的常态行为，才能科学地定义“预算”的消耗速率与剩余水位。
核心认知： 服务画像 ≠ 监控大盘。监控回答“现在怎么样”，画像回答“它是什么样、依赖什么、如何消耗资源、在压力下如何反应”。
2.2 画像的四大构成要素
服务画像由四个相互关联的维度构成，缺一不可。下表总结了每个维度的核心关注点与典型指标：
| 维度 | 定义 | 核心关注点 | 典型指标示例 |
|---|---|---|---|
| 流量 | 服务入口与出口的请求特征 | 吞吐量、并发数、请求类型分布、峰值模式 | QPS、RPS、活跃连接数、请求体大小 P50/P99 |
| 依赖 | 服务运行时调用的外部组件与上下游关系 | 依赖拓扑、调用深度、超时与重试策略、熔断状态 | 依赖数、P99 延迟、错误率、熔断器状态 |
| 资源 | 服务运行所消耗的物理或虚拟资源 | CPU、内存、磁盘、网络 IO 的消耗曲线与瓶颈 | CPU 利用率、内存 RSS、磁盘 IOPS、网络带宽 |
| 行为 | 服务在特定条件下的内部执行逻辑与状态变迁 | GC 行为、线程池状态、缓存命中率、慢查询模式 | GC 暂停时间、活跃线程数、缓存命中率、慢 SQL 次数 |
画像构建原则： 流量是“输入”，依赖是“路径”，资源是“消耗”，行为是“效率”。四个维度必须联合分析，单一维度的数据无法支撑容量决策。
2.3 画像的采集方式
采集服务画像数据需要覆盖代码层、运行时层、基础设施层三个层面。以下是主流的采集方式与工具矩阵：
- 埋点与日志（代码层）：
- 结构化日志（JSON 格式）：记录请求 ID、耗时、状态码、业务字段。
- 业务指标埋点：通过 Micrometer / Prometheus Client 手动上报计数器、直方图。
- 调用链 ID 注入：通过 OpenTelemetry SDK 自动注入 Trace Context。
- 指标与链路（运行时层）：
- Prometheus 指标暴露：/metrics 端点输出 JVM、线程池、连接池等运行时指标。
- 分布式追踪：Jaeger / Zipkin 采集 Span 数据，构建依赖拓扑。
- 事件采样：基于 Head-Based 或 Tail-Based 采样策略，控制存储成本。
- 基础设施与网络（基础设施层）：
- Node Exporter / cAdvisor：采集容器与宿主机的 CPU、内存、网络 IO。
- eBPF 技术：无侵入采集网络流量、系统调用、TCP 重传等内核级数据。
- 云厂商 API：获取实例规格、弹性伸缩事件、网络带宽上限。
采集避坑： 避免全量采集所有指标。画像数据应遵循“先宽后窄”策略——初期宽采集探索特征，稳定后窄采集保留关键维度，否则存储与计算成本会迅速失控。
2.4 服务画像数据流架构
下图展示了从采集到画像生成的完整数据流，帮助理解各组件之间的协作关系：
2.5 画像采集的采样策略对比
不同采集方式对存储与精度的权衡不同，以下是三种主流策略的对比：
| 策略 | 原理 | 存储成本 | 画像精度 | 适用场景 |
|---|---|---|---|---|
| 全量采集 | 记录每一次请求的完整指标与链路 | 极高 | 100% | 核心支付链路、合规审计 |
| 固定比率采样 | 按固定概率（如 1%）随机保留请求 | 低 | 统计近似 | 高吞吐非关键服务、长期趋势分析 |
| 自适应采样 | 低负载时全采，高负载时降采样；异常时提升采样率 | 中 | 动态平衡 | 容量规划、异常检测、Error Budget 计算 |
推荐实践： 在 Error Budget 量化场景下，建议采用自适应采样策略。正常水位时保持 1%~5% 采样率，当错误率或延迟触发阈值时自动提升至 50%~100%，确保画像数据在关键窗口期的精度。