2. 服务画像基础：概念、构成要素与建模方法
服务画像是容量压测与资源优化的第一道工序。它并非简单的“服务名称+实例数”罗列，而是对目标服务运行时行为、拓扑依赖与流量模式的结构化抽象。只有建立准确的服务画像，后续的压测水位设计、资源阈值校准才有可追溯的锚点。
核心认知： 服务画像 = 服务在正常/异常状态下对外呈现的可观测特征集合。它回答三个问题：
① 服务依赖谁？（拓扑）
② 服务如何被调用？（流量）
③ 服务内部如何响应？（行为）
① 服务依赖谁？（拓扑）
② 服务如何被调用？（流量）
③ 服务内部如何响应？（行为）
2.1 服务画像的概念
服务画像（Service Profiling）是指通过采集、聚合与分析服务的运行时指标、调用链路、日志与配置信息，形成对服务行为特征、资源消耗模式与依赖关系的数字化描述。它是容量规划、性能基线建立与异常检测的基础数据模型。
| 维度 | 定义 | 典型产出 |
|---|---|---|
| 静态画像 | 服务部署架构、实例规格、代码版本、中间件配置 | 部署拓扑图、配置清单 |
| 动态画像 | 运行时指标、调用链、流量特征、错误模式 | 性能基线、依赖矩阵、流量模型 |
| 依赖画像 | 上下游服务、中间件、数据库、外部API的调用关系 | 依赖拓扑图、调用深度统计 |
实践要点： 动态画像的时效性至关重要。建议以5分钟为粒度持续采集，保留至少30天的历史数据，用于识别周期性流量模式与异常漂移。
2.2 服务画像的构成要素
服务画像由三大核心要素构成：调用链（Trace）、依赖关系（Dependency）与流量特征（Traffic Pattern）。三者相互关联，共同描述服务的完整行为轮廓。
2.2.1 调用链（Trace）
调用链记录一次请求在分布式系统中的完整路径，包括各服务的处理时间、状态码与异常信息。它是服务画像中最精细的行为数据源。
| 调用链要素 | 说明 | 容量规划用途 |
|---|---|---|
| Span | 一次远程调用或本地操作的单元 | 识别慢调用、热点路径 |
| Trace ID | 全局唯一请求标识 | 关联全链路资源消耗 |
| Parent Span ID | 父子调用关系 | 构建调用树、计算调用深度 |
| Duration | Span 耗时（ms） | 计算服务延迟分布、P99/P95 |
| Status | 成功/错误/超时 | 统计错误率、熔断触发条件 |
常见陷阱： 仅采集成功调用的调用链，忽略超时与错误链，会导致画像失真。压测时错误链的资源消耗往往高于正常链（重试、回滚），必须纳入基线。
2.2.2 依赖关系（Dependency）
依赖关系描述服务与外部组件（其他服务、数据库、缓存、消息队列、外部API）之间的调用拓扑。依赖关系直接影响容量压测的边界条件设计与故障注入范围。
- 强依赖： 调用失败直接导致服务不可用（如用户服务依赖数据库）。压测时必须模拟依赖故障场景。
- 弱依赖： 调用失败可通过降级/缓存容忍（如推荐服务依赖个性化算法）。压测时可降级处理。
- 循环依赖： A→B→A 的调用环，极易引发死锁与级联故障。需在画像中标记并优先治理。
- 扇出/扇入： 扇出（一个服务调用多个下游）与扇入（多个上游调用同一服务）是容量瓶颈的常见位置。
2.2.3 流量特征（Traffic Pattern）
流量特征描述服务在时间维度上的请求模式，包括吞吐量、并发数、请求大小分布与时间序列规律。流量特征是设计压测模型与确定水位阈值的直接依据。
| 流量特征指标 | 定义 | 压测水位设计影响 |
|---|---|---|
| QPS / TPS | 每秒请求数 / 每秒事务数 | 确定压测目标吞吐量（如 2×峰值 QPS） |
| 并发连接数 | 同时处理的请求数量 | 评估线程池、连接池容量上限 |
| 请求体大小 | 请求 payload 的字节分布 | 影响网络带宽、序列化/反序列化开销 |
| 时间分布 | 日/周/月流量波峰波谷规律 | 确定压测时段、持续时长与阶梯模型 |
| 突发系数 | 峰值流量 / 平均流量 | 决定弹性伸缩策略与资源冗余度 |
实战经验： 某电商核心服务的流量特征显示，突发系数高达 8.3（大促秒杀场景）。若按平均流量设计压测水位，将严重低估资源需求。建议将突发系数 ≥ 3 的服务标记为“高弹性需求”，压测水位至少按 3×峰值设计。
2.3 服务画像的建模流程
建立服务画像通常遵循以下步骤，每一步的输出作为下一步的输入，形成可迭代的画像模型：
- 数据采集： 通过 APM（如 SkyWalking、Jaeger）、指标系统（Prometheus）、日志平台（ELK）采集调用链、指标与日志。
- 拓扑构建： 基于调用链数据自动生成服务依赖拓扑图，识别扇出/扇入节点与循环依赖。
- 基线提取： 计算各服务在正常时段（非大促、无故障）的延迟、吞吐量、错误率等指标的 P50/P95/P99 基线。
- 流量建模： 对历史流量数据进行时间序列分解，提取趋势、周期与突发模式，生成流量模型。
- 画像输出： 将上述结果汇总为服务画像文档，包含拓扑图、基线表、流量模型与依赖矩阵。
迭代提醒： 服务画像不是一次性工作。每次代码发布、配置变更、基础设施调整后，都应重新验证画像的准确性。建议将画像更新纳入 CI/CD 门禁，变更触发自动重画像。
2.4 服务画像与容量压测的关联
服务画像直接决定容量压测的水位口径与阈值设计：
- 压测目标： 基于画像中的峰值 QPS 与突发系数，确定压测目标吞吐量（如 1.5×峰值、2×峰值）。
- 压测场景： 依赖拓扑中的扇出节点需设计独立压测场景，评估下游依赖的容量上限。
- 阈值校准： 调用链中的 P99 延迟基线作为压测通过/失败判定标准（如压测期间 P99 不超过基线的 1.2 倍）。
- 资源水位： 动态画像中的 CPU/内存基线作为资源阈值的参考锚点（如 CPU 使用率不超过基线的 1.5 倍）。
一句话总结： 没有服务画像的压测是盲人摸象；有了服务画像，压测才能做到“知彼知己，百战不殆”。