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 服务,生产环境连接真实下游)。
依赖关系分为三类:
- 内部服务依赖:通过 RPC / HTTP 调用的其他微服务。
- 中间件依赖:MySQL、Redis、Kafka、Elasticsearch 等。
- 外部依赖:第三方 API、SaaS 服务、DNS 解析。
依赖建模方法:使用 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
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 参数不同、健康阈值不同),均生成差异报告并决定是否阻断发布。