2. 服务画像基础：服务画像的定义、构成要素

服务画像是容量压测与稳定性保障的“数字孪生”基础。它并非简单的监控指标堆砌，而是对单个微服务在特定时间窗口内资源消耗、外部依赖、流量特征、性能基线四维属性的结构化建模。只有建立精确的服务画像，才能判断压测水位是否合理、异常检测是否灵敏、容量调整是否有效。

2.1 服务画像的定义

服务画像（Service Profiling）是指通过采集、聚合、关联服务运行时的多维数据，形成一组可量化、可对比、可预测的特征向量集合。其核心目标是将“服务运行状态”从离散的指标点转化为连续的行为轮廓，从而支撑异常检测、容量评估与压测水位校准。

2.2 构成要素总览

服务画像由四大核心要素构成，缺一不可。下表列出各要素的定义、典型指标与在容量压测中的作用：

2.3 四要素详解

2.3.1 资源（Resource）

资源是服务运行的物理基础，也是最直观的容量边界。在容器化与云原生环境下，资源画像需要区分请求资源（CPU、内存）与系统资源（文件句柄、线程池、连接池）。

• CPU 画像： 记录用户态、内核态、I/O 等待占比，识别 CPU 密集型 vs I/O 密集型服务。
• 内存画像： 区分堆内/堆外、常驻集（RSS）与虚拟内存，关注 GC 行为对内存抖动的影响。
• 网络与磁盘： 网卡入/出带宽、磁盘读写延迟与 IOPS，这些在压测中常被忽略但极易成为瓶颈。

2.3.2 依赖（Dependency）

现代微服务架构中，单个服务的稳定性高度依赖其上下游。依赖画像的核心是拓扑关系与调用量级。

• 强依赖 vs 弱依赖： 强依赖（如数据库、配置中心）故障会直接导致服务不可用；弱依赖（如日志、监控）故障可降级。
• 依赖容量： 每个依赖的并发连接数、超时时间、重试策略，这些参数直接影响压测时的“雪崩”风险。
• 依赖延迟分布： 记录每个下游调用的 P50/P99 延迟，用于计算服务自身的端到端延迟预算。

2.3.3 流量（Traffic）

流量画像描述的是“请求如何到达服务”。压测场景必须与真实流量画像对齐，否则压测结果毫无意义。

• 流量规模： 平均 QPS、峰值 QPS、日请求总量。
• 流量模式： 平稳型、突发型、潮汐型（如早晚高峰）、脉冲型（如秒杀）。
• 流量特征： 请求体大小分布、URL 分布、Header 分布、用户 ID 分布（用于缓存亲和性）。
• 错误流量： 4xx/5xx 比例、超时比例、熔断触发次数。

2.3.4 性能基线（Performance Baseline）

性能基线是服务画像的“参考坐标系”。没有基线，异常检测就无从谈起。基线通常以时间窗口滑动统计的方式维护。

• 短期基线： 过去 1 小时/24 小时的指标分布，用于实时异常检测。
• 长期基线： 过去 7 天/30 天的指标趋势，用于容量规划与水位调整。
• 版本基线： 每次发布后重新建立基线，用于对比新版本性能退化。

基线通常包含均值、标准差、P50/P95/P99 分位数，以及动态阈值（如均值 ± 3σ）。

2.4 服务画像四要素关系图

下图展示四大要素之间的数据流与依赖关系：资源与依赖构成服务运行的基础设施层，流量是输入层，性能基线是度量层，三者共同输出用于异常检测与压测水位调整的画像特征。

2.5 画像数据采集与存储

服务画像的构建依赖高质量的数据采集。以下是推荐的采集策略与存储方案：

2.6 画像与压测水位的关联

服务画像的最终目的是指导容量压测的水位调整。以下是一个典型的关联流程：

1. 基线建立： 基于过去 7 天的服务画像，生成每个服务的“正常水位区间”（如 CPU 使用率 20%~60%，P99 延迟 50ms~200ms）。
2. 异常检测触发： 当实时画像偏离基线超过阈值（如 CPU 突增 50% 或 P99 延迟翻倍），触发异常事件。
3. 压测水位修正： 根据异常类型调整压测目标：如果是资源瓶颈，降低压测 QPS 目标；如果是依赖故障，增加熔断降级策略后再压测。
4. 画像更新： 压测完成后，将压测数据合并入历史画像，更新基线，形成闭环。

通过上述流程，服务画像从“静态描述”进化为“动态决策依据”，真正实现容量压测水位的智能调整。