2. 服务画像核心概念:服务元数据、运行时特征、依赖关系、健康指标的定义与建模

服务画像是将分布式系统中每个服务的静态属性、动态行为、外部联系与健康状态进行结构化建模的过程。它是质量门禁策略的“数据底座”,也是排查发布环境差异的“对照基准”。本章定义四个核心维度:服务元数据、运行时特征、依赖关系与健康指标,并给出各自的建模方法。

2.1 服务元数据(Service Metadata)

服务元数据是服务的“身份证”,描述服务在组织、代码、部署层面的静态属性。它不随运行状态变化,是环境差异排查的第一对照层。

元数据字段 定义 建模示例
服务名称 全局唯一的服务标识符 order-service
所属域 业务域或子域归属 trade.domain
Git 仓库地址 源码托管位置 git@gitlab.com/backend/order.git
技术栈 编程语言、框架版本 Java 17 / Spring Boot 3.2
负责人 团队或个人 POC sre-team@company.com
部署单元 K8s Deployment / VM 实例名 order-deployment-v2
建模要点:元数据应存储在 CMDB 或服务目录中,并通过 CI/CD 流水线自动同步。环境差异排查时,优先比对元数据中的“部署单元”与“技术栈”字段。

2.2 运行时特征(Runtime Characteristics)

运行时特征描述服务在特定环境下的动态行为参数,包括资源配置、启动参数、日志级别与 JVM/OS 参数。这些特征在不同环境(开发、测试、预发、生产)之间极易产生差异,是质量门禁的“高频检查点”。

  • 资源配置:CPU 核数、内存限制(requests / limits)、磁盘挂载。
  • 启动参数:JVM -Xmx、-Xms、GC 策略、Spring Profile 激活。
  • 日志配置:日志级别(DEBUG / INFO / WARN / ERROR)、日志轮转策略。
  • 网络参数:监听端口、连接超时、最大连接数。
# 运行时特征建模示例(YAML 片段)
runtime:
  cpu: "2"
  memory: "4Gi"
  jvm_args: "-Xms2g -Xmx2g -XX:+UseG1GC"
  active_profile: "production"
  log_level: "INFO"
  port: 8080
  max_connections: 200
常见差异陷阱:预发环境使用 -Xmx4g 而生产环境使用 -Xmx2g,会导致预发压测通过但生产 OOM。运行时特征必须通过门禁逐字段比对。

2.3 依赖关系(Dependency Graph)

依赖关系建模服务之间的调用链路、中间件依赖与外部 API 依赖。它是环境差异排查中最复杂的维度,因为依赖拓扑在不同环境可能完全不同(例如:测试环境连接 Mock 服务,生产环境连接真实下游)。

依赖关系分为三类:

  1. 内部服务依赖:通过 RPC / HTTP 调用的其他微服务。
  2. 中间件依赖:MySQL、Redis、Kafka、Elasticsearch 等。
  3. 外部依赖:第三方 API、SaaS 服务、DNS 解析。
服务依赖关系拓扑图 order-service api-gateway user-service payment-service inventory-service MySQL (主) Redis Cluster Kafka Topic 上游调用方 下游依赖方 中间件 当前服务
依赖建模方法:使用 Service Mesh(如 Istio)或 APM 工具(如 SkyWalking)自动采集调用拓扑,生成有向无环图(DAG)。每个依赖节点应记录:host:port、超时时间、熔断阈值、环境标签。

2.4 健康指标(Health Indicators)

健康指标是服务运行时状态的量化度量,用于判断服务是否“健康”以及是否符合质量门禁的准入/准出标准。健康指标分为三个层级:

层级 指标示例 门禁阈值(生产环境)
L1 存活 进程存活、端口监听、健康检查端点 /health 3 次连续失败则判定为不健康
L2 性能 P99 延迟 < 500ms、错误率 < 1%、QPS 波动 < 20% 任一指标超阈值持续 5 分钟则触发告警
L3 容量 CPU 使用率 < 80%、内存使用率 < 85%、连接池使用率 < 70% 超阈值则禁止新版本发布

健康指标的建模应遵循 RED 方法(Rate, Errors, Duration)与 USE 方法(Utilization, Saturation, Errors)的组合:

# 健康指标建模示例(Prometheus 风格)
metrics:
  - name: request_duration_seconds
    type: histogram
    threshold_p99: 0.5
  - name: errors_total
    type: counter
    threshold_rate: 0.01
  - name: cpu_utilization
    type: gauge
    threshold: 0.8
  - name: db_connection_pool_usage
    type: gauge
    threshold: 0.7
健康指标分层模型 L3 容量健康 CPU / 内存 / 连接池 / 磁盘 L2 性能健康 P99 延迟 / 错误率 / QPS 波动 L1 存活健康 进程存活 / 端口监听 / /health 端点 门禁规则:L1 不通过则直接阻断发布;L2/L3 超阈值则触发人工审批

2.5 四维建模总览

将上述四个维度整合为统一的服务画像模型,形成可被质量门禁引擎消费的 JSON Schema:

{
  "service_metadata": {
    "name": "order-service",
    "domain": "trade",
    "repo": "git@gitlab.com/backend/order.git",
    "tech_stack": "Java 17",
    "owner": "sre-team"
  },
  "runtime_characteristics": {
    "cpu": "2",
    "memory": "4Gi",
    "jvm_args": "-Xms2g -Xmx2g",
    "log_level": "INFO"
  },
  "dependency_graph": {
    "upstream": ["api-gateway", "user-service"],
    "downstream": ["payment-service", "inventory-service"],
    "middleware": ["mysql-master", "redis-cluster", "kafka-order-topic"]
  },
  "health_indicators": {
    "liveness": {"endpoint": "/health", "interval_sec": 15},
    "performance": {"p99_ms": 500, "error_rate": 0.01},
    "capacity": {"cpu_max": 0.8, "mem_max": 0.85}
  }
}
门禁集成:在发布流水线中,门禁引擎读取目标环境的服务画像,与基准环境(如预发)的画像进行四维逐字段比对。任何维度出现差异(如依赖地址不同、JVM 参数不同、健康阈值不同),均生成差异报告并决定是否阻断发布。