4. 服务画像概念：服务拓扑、依赖关系、运行时特征、资源画像

服务画像是将微服务系统中每个服务实例的静态结构与动态行为进行数字化建模的过程。在日志 Golden Signals 查询调优场景中，服务画像决定了 查询范围、聚合粒度 和 异常检测基线。一个完整的服务画像由四个核心维度构成：服务拓扑、依赖关系、运行时特征和资源画像。

4.1 服务拓扑

服务拓扑描述服务实例之间的网络连接与调用路径。它是日志查询的 第一层过滤条件：当某个 Golden Signal 出现异常时，拓扑图能快速定位影响范围是“上游调用方”还是“下游依赖方”。

拓扑数据通常来源于：

• 服务注册中心（Consul / Nacos / Eureka）—— 实例 IP、端口、健康状态。
• 分布式追踪系统（Jaeger / Zipkin）—— 调用链中的 parent-child 关系。
• 网络流量元数据（eBPF / Cilium）—— 四层到七层的连接矩阵。

下表对比了三种拓扑数据源的适用场景：

4.2 依赖关系

依赖关系是服务拓扑的 深化层，它不仅记录“谁调用了谁”，还记录调用类型、超时配置、重试策略、熔断状态。在日志查询调优中，依赖关系直接影响 查询的 JOIN 策略 和 上下文关联效率。

依赖关系分为三类：

1. 强依赖（Synchronous RPC / DB）：调用失败直接导致当前服务错误。日志查询需同时拉取两端日志做因果分析。
2. 弱依赖（Async MQ / Cache）：调用失败可降级。日志查询可独立分析，无需强关联。
3. 可选依赖（Feature Flag / A/B Test）：仅在特定条件下触发。日志查询需携带实验标签过滤。

4.3 运行时特征

运行时特征描述服务在特定时间窗口内的 行为模式，包括请求速率、错误率、延迟分布、并发数。这些特征是日志查询 动态调整采样率 和 预聚合窗口 的依据。

核心运行时指标与日志查询策略的对应关系：

4.4 资源画像

资源画像描述服务实例所消耗的 基础设施资源：CPU、内存、磁盘 I/O、网络带宽、文件句柄数。在日志查询场景中，资源画像直接决定 日志写入吞吐上限 和 查询并发度。

资源画像与日志系统瓶颈的对应关系：

4.5 四维画像的整合查询策略

当四个维度的数据汇聚后，日志查询系统可以构建一个 服务画像矩阵，用于自动生成 Golden Signals 查询计划：

// 服务画像矩阵示例（JSON 结构）
{
  "service": "order-service",
  "topology": {
    "upstream": ["api-gateway", "user-service"],
    "downstream": ["payment-service", "inventory-service"]
  },
  "dependencies": {
    "payment-service": { "type": "sync_rpc", "timeout_ms": 3000, "circuit_breaker": true },
    "inventory-service": { "type": "async_mq", "retry": 3 }
  },
  "runtime": {
    "qps": 12500,
    "error_rate": 0.02,
    "p99_latency_ms": 450,
    "concurrency": 320
  },
  "resources": {
    "cpu_usage_percent": 72,
    "memory_usage_mb": 4096,
    "disk_iops": 850,
    "network_throughput_mbps": 120
  }
}

基于上述画像，日志查询系统可以自动推导出：

• 索引分片策略：按 service + upstream 组合键分片，减少跨分片查询。
• 采样率调整：QPS > 10k 且错误率正常 → 采样率降至 10%；错误率突增 → 自动提升至 100%。
• 查询超时设置：根据下游依赖的超时配置，设置日志查询的超时时间为依赖超时的 1.5 倍。
• 资源限流：当磁盘 IOPS 超过 800 时，日志写入从同步改为异步批处理，避免影响业务主流程。