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

在构建可量化的SLA运营体系之前，必须首先回答一个根本问题：我们到底在运营什么？ 服务画像（Service Profiling）正是回答这一问题的核心工具。它并非简单的服务列表或拓扑图，而是一种多维度的、结构化的、可量化的服务特征描述模型，用于将运维对象的复杂运行状态抽象为可观测、可比较、可决策的数字化标签。

2.1 服务画像的定义

服务画像借鉴了用户画像（User Profile）的思想，但面向的是微服务、中间件、数据库等IT服务实体。它通过持续采集和聚合可观测性数据（Metrics、Logs、Traces），为每一个服务实例或服务组建立一份“数字身份证”。

这份画像具有三个关键特性：

• 多维性： 单一指标无法定义服务健康，必须从资源、流量、依赖、状态四个正交维度综合描述。
• 动态性： 画像随时间窗口滑动而实时更新，反映服务的瞬态与稳态特征。
• 可量化性： 每个维度下的特征都必须有明确的量化口径，而非模糊的“正常”或“异常”。

2.2 服务画像的构成要素

我们将服务画像拆解为四个核心构成要素：资源（Resource）、流量（Traffic）、依赖（Dependency）、状态（State）。这四个要素共同构成了服务健康度的“四维坐标系”。

以下SVG图展示了服务画像的四维构成及其与可观测性数据源的关系：

2.3 各要素深度解析

2.3.1 资源维度

资源是服务运行的物理基础。在弹性伸缩场景中，资源画像决定了扩缩容的触发阈值和容量规划的上限。资源维度的量化需要区分“静态资源”与“动态资源”。

• 静态资源： CPU核数、内存大小、磁盘容量、网络带宽上限。这些决定了服务的最大理论容量。
• 动态资源： CPU使用率、内存使用率、磁盘IO等待、网络出入流量。这些反映了服务的实时负载。

2.3.2 流量维度

流量是服务画像中最具动态性的要素。它直接驱动弹性伸缩决策。流量画像需要从量和质两个层面刻画。

2.3.3 依赖维度

现代微服务架构中，几乎没有服务是孤岛。依赖维度的健康度直接决定了服务自身的可用性。依赖画像需要建立依赖拓扑图和依赖强度矩阵。

• 强依赖： 下游不可用则本服务直接不可用（如数据库、认证中心）。
• 弱依赖： 下游不可用本服务仍可降级运行（如推荐服务、日志收集）。
• 依赖健康度： 通过调用成功率、超时率、熔断器状态综合计算。

2.3.4 状态维度

状态维度是服务画像的“快照”层，反映服务在时间轴上的当前阶段。它不同于前三个维度的连续数值，更多是离散的、枚举型的特征。

以下SVG图展示了服务画像四维要素如何共同驱动弹性伸缩决策：

2.4 服务画像的构建原则

在实际落地过程中，构建服务画像需要遵循以下原则，以确保画像的准确性和可操作性：

1. 最小完备原则： 每个服务至少采集资源、流量、依赖、状态四个维度各一个核心指标，避免过度采集导致信噪比下降。
2. 时间窗口对齐： 所有维度的数据必须使用相同的时间窗口（如1分钟、5分钟）进行聚合，避免因时间错位导致画像失真。
3. 基线动态更新： 画像的“正常范围”应基于历史数据自动计算（如过去7天同时间段的P50-P95区间），而非人工设定固定阈值。
4. 标签化存储： 将画像结果以标签（Tag）形式写入时序数据库，便于后续的查询、聚合和告警关联。

# 服务画像综合健康度评分示例
- record: service:health_score:avg5m
  expr: |
    (1 - (cpu_usage_avg / 100)) * 0.3 +
    (1 - (memory_usage_avg / 100)) * 0.3 +
    (dependency_success_rate) * 0.2 +
    (1 - error_rate) * 0.2

2.5 本章小结