3. 服务画像维度：调用链维度、接口维度、业务维度、实例维度

服务画像是容量压测与水位基线制定的基础。一个完整的服务画像需要从四个核心维度进行刻画，每个维度揭示服务在不同层面的行为特征与资源消耗模式。只有将这四个维度的数据融合分析，才能形成准确的服务容量模型。

3.1 四维画像总览

下表对比了四个维度的关注焦点、核心指标与典型应用场景：

3.2 调用链维度

调用链维度刻画服务在分布式系统中的位置与依赖关系。核心目标是理解服务的上下游拓扑、调用深度以及依赖的强弱程度。

• 调用拓扑：服务调用了哪些下游服务？被哪些上游服务调用？是否存在循环依赖？
• 扇入/扇出：扇入数（被多少上游调用）反映服务的核心程度；扇出数（调用多少下游）反映服务的聚合复杂度。
• 依赖延迟：下游服务的响应时间直接影响本服务的RT，需识别慢依赖与超时配置。
• 错误传播：下游错误是否被正确熔断或降级？错误率是否随调用链逐级放大？

3.3 接口维度

接口维度聚焦于服务对外暴露的每个API端点的独立行为。不同接口的资源消耗与性能特征可能差异巨大，必须逐接口进行画像。

• 请求特征：QPS（每秒请求数）、请求体大小分布、请求参数复杂度。
• 响应特征：RT（响应时间）分布、TP50/TP90/TP99、响应体大小、错误率。
• 资源消耗：每个接口的CPU耗时、内存分配量、数据库查询次数、外部调用次数。
• 并发特征：接口的并发连接数、线程池使用率、等待队列深度。

3.4 业务维度

业务维度将技术指标映射到业务语义，使容量规划能够与业务目标对齐。脱离业务的技术指标无法指导真实的容量决策。

3.5 实例维度

实例维度关注单个服务进程或容器的资源使用情况。这是制定资源水位基线的直接数据来源，也是容量压测的最终落脚点。

• CPU：用户态/内核态使用率、平均负载、上下文切换频率。
• 内存：堆内存使用、GC频率与停顿时间、非堆内存、RSS（常驻内存集）。
• 网络IO：入站/出站带宽、连接数、连接建立速率、重传率。
• 磁盘IO：读写IOPS、吞吐量、延迟、队列深度。
• 线程/协程：活跃线程数、等待线程数、线程池拒绝率。

3.6 四维融合：服务画像矩阵

在实际容量工程中，四个维度并非孤立存在，而是相互关联、共同构成服务的完整画像。以下矩阵展示了维度间的典型关联关系：