2. 服务画像基础：服务画像的构成要素与数据采集

服务画像是可观测性体系中用于描述单个服务运行时全貌的数字化快照。它并非静态的配置文件，而是由元数据、依赖关系、性能基线和动态拓扑四个核心要素构成的动态数据模型。在MTTR复盘口径重算场景中，服务画像的变更检测是触发分布式追踪与重新计算的根本依据。

2.1 服务画像的四大构成要素

2.2 画像数据的采集策略

服务画像的数据来源多样，采集方式需根据要素类型差异化设计：

• 元数据采集： 通过CMDB、容器编排平台(K8s API)、CI/CD流水线事件驱动采集。推荐使用变更事件订阅模式，避免全量轮询。
• 依赖关系采集： 基于分布式追踪系统(SkyWalking、Jaeger)的调用链数据，结合服务网格(istio)的流量规则，通过时间窗口聚合生成依赖图谱。
• 性能基线采集： 由指标监控系统(Prometheus、VictoriaMetrics)以固定频率(如10s/30s)拉取，存储为时序窗口聚合数据，用于后续基线计算。
• 动态拓扑采集： 通过eBPF、网络探针或服务网格Sidecar实时捕获连接信息，以事件流方式上报至画像存储层。

# 伪代码：服务画像变更检测的采集与判断逻辑
def collect_service_portrait(service_id):
    # 1. 采集元数据（事件驱动）
    metadata = cmdb.get_service_metadata(service_id)
    
    # 2. 采集依赖关系（时间窗口聚合）
    dependencies = trace_analyzer.get_dependencies(service_id, window='5m')
    
    # 3. 采集性能基线（时序聚合）
    baseline = metrics_store.get_baseline(service_id, window='1h')
    
    # 4. 采集动态拓扑（实时流）
    topology = network_probe.get_live_topology(service_id)
    
    # 5. 构建画像快照并与上一版本对比
    current_snapshot = ServicePortrait(metadata, dependencies, baseline, topology)
    diff_result = portrait_diff(current_snapshot, last_snapshot)
    
    if diff_result.has_changes:
        trigger_mttr_recalculation(service_id, diff_result)
    
    return current_snapshot

2.3 画像数据的存储模型

服务画像数据具有多模态和时间序列化的双重特征，单一存储引擎难以满足所有需求。推荐采用混合存储架构：

2.4 服务画像构成与采集架构

下图展示了服务画像的四大要素及其数据采集、存储与变更检测的整体架构：

2.5 变更检测的触发条件与数据流

服务画像变更检测并非简单的字段比对，而是需要结合时间窗口和阈值策略的智能判断。以下流程图展示了从数据采集到触发MTTR重算的完整数据流：

2.6 画像数据质量保障

服务画像的准确性直接影响变更检测的可靠性。以下是保障数据质量的三个关键实践：

• 数据完整性校验： 每次画像快照构建后，执行完整性检查（四个要素是否齐全、时间戳是否合理、必填字段是否为空）。不完整的快照标记为“脏数据”，不参与变更检测。
• 血缘追踪： 记录每个画像字段的数据来源（采集器ID、采集时间、原始数据指纹），便于在复盘时追溯数据质量问题。
• 定期全量校准： 每24小时执行一次全量画像重建，与增量变更检测结果进行交叉验证，防止增量数据累积误差。