3. 服务画像元数据设计
服务画像元数据是构建可观测性体系的基石。它定义了“谁在运行什么、应该达到什么水平、依赖谁”。本节将围绕服务名称、服务ID、服务Owner、服务等级（SLA/SLO/SLI）和服务依赖关系五个核心维度，给出标准化设计规范与实战落地方法。
3.1 元数据五要素总览
服务画像元数据并非简单的标签集合，而是支撑告警降噪、故障定位、容量规划和成本分摊的上下文信息。下表对比了五个要素的核心用途与数据来源：
| 元数据字段 | 核心用途 | 推荐数据来源 | 变更频率 |
|---|---|---|---|
| 服务名称 | 全局唯一标识，用于日志/指标/链路关联 | CMDB / 服务注册中心 | 低（仅新建或重命名时） |
| 服务ID | 系统内部主键，用于API调用和数据库关联 | 自动生成（UUID / 雪花ID） | 永不改变 |
| 服务Owner | 明确责任边界，用于告警认领和On-Call排班 | 人员管理系统 / 值班表 | 中（人员变动时） |
| 服务等级 | 定义可用性与性能目标，指导SLO告警策略 | 服务等级协议文档 | 低（季度/年度评审） |
| 服务依赖关系 | 故障影响范围分析，用于根因定位和变更风险评估 | 服务拓扑扫描 / 链路追踪数据 | 中（架构迭代时） |
实战建议：元数据应存储在统一的服务注册中心或CMDB中，并通过API供可观测性平台实时拉取。避免在日志采集Agent或告警规则中硬编码元数据，否则会导致维护成本指数级上升。
3.2 服务名称与服务ID设计规范
服务名称是面向人的标识，服务ID是面向机器的标识。两者必须保持一一映射关系，且在整个组织内唯一。
- 服务名称命名规则：采用三段式结构：
团队名-业务域-服务名。例如：pay-core-payment、infra-gateway-edge。禁止使用缩写或拼音。 - 服务ID生成规则：推荐使用UUID v4或雪花算法（Snowflake ID）。ID长度固定，不包含业务含义，避免因业务重构导致ID语义失效。
- 元数据同步机制：服务启动时向注册中心上报名称和ID，可观测性平台通过监听注册中心事件自动更新画像。
# 服务元数据注册示例（JSON格式）
{
"service_name": "pay-core-payment",
"service_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"owner": "payment-team",
"sla": "99.99",
"dependencies": ["infra-gateway-edge", "pay-db-cluster"]
}
3.3 服务Owner与责任域
服务Owner是故障响应和变更审批的第一责任人。设计时需区分“技术Owner”和“业务Owner”，并支持多级备份。
| 角色 | 职责 | 告警通知方式 |
|---|---|---|
| Primary Owner | 日常运维、故障处理、SLO达成 | 电话 + 即时消息（强提醒） |
| Secondary Owner | Primary不可用时的备份 | 即时消息（普通提醒） |
| Business Owner | 服务等级目标审批、预算决策 | 邮件（非紧急） |
常见陷阱：Owner信息过期是元数据腐化的首要原因。建议每季度通过自动化脚本扫描Owner是否仍在职，并触发确认流程。无人认领的服务应自动进入“孤儿服务”列表，由平台团队接管。
3.4 服务等级：SLA / SLO / SLI 定义与关联
服务等级是画像中最具技术深度的元数据。三者的关系可以概括为：SLI是测量指标，SLO是目标阈值，SLA是业务承诺。
- SLI（Service Level Indicator）：直接反映服务质量的原始指标。例如：请求延迟P99、错误率、吞吐量。
- SLO（Service Level Objective）：SLI的目标值。例如：P99延迟 ≤ 200ms，错误率 ≤ 0.1%。
- SLA（Service Level Agreement）：对外承诺的等级，通常比SLO更宽松。例如：月度可用性 ≥ 99.9%。
在服务画像中，每个服务应至少定义3个核心SLI及其对应的SLO。以下是一个支付服务的等级定义示例：
# 服务等级定义示例（YAML格式）
service_level:
sli:
- name: "请求延迟P99"
measurement: "http_request_duration_seconds"
aggregation: "p99"
- name: "错误率"
measurement: "http_requests_total"
aggregation: "rate(error)"
- name: "可用性"
measurement: "probe_success"
aggregation: "avg"
slo:
- sli: "请求延迟P99"
target: "<= 0.2"
window: "28d"
- sli: "错误率"
target: "<= 0.001"
window: "28d"
- sli: "可用性"
target: ">= 0.9999"
window: "28d"
sla:
availability: "99.99"
penalty: "月度费用减免10%"
关键原则：SLO必须可测量、可告警、可追溯。不要定义无法采集的SLI，也不要设置永远达不到的SLO。建议从“用户感知”角度选择SLI，而非从“系统内部”角度。
3.5 服务依赖关系建模
服务依赖关系是故障影响分析的核心输入。依赖关系分为三类：强依赖（调用失败直接导致本服务不可用）、弱依赖（调用失败导致功能降级）、数据依赖（共享数据库或消息队列）。
以下SVG图展示了一个典型微服务架构的依赖关系建模，包含核心支付服务及其上下游依赖：
3.6 依赖关系数据采集与维护
依赖关系不能仅靠手工维护，必须结合自动化手段持续更新。推荐采用以下三种方式互补：
| 采集方式 | 原理 | 优势 | 局限性 |
|---|---|---|---|
| 链路追踪自动发现 | 从分布式追踪数据中提取调用关系 | 实时、准确、覆盖全量调用 | 需要全链路接入追踪SDK |
| 服务网格Sidecar上报 | 通过Envoy/Istio的访问日志解析依赖 | 无侵入、支持异构协议 | 仅覆盖网格内流量 |
| CMDB手工配置 | 架构师在变更时手动录入 | 可表达业务语义（如“弱依赖”） | 容易过期，需定期审计 |
最佳实践：以链路追踪自动发现为主数据源，CMDB手工配置作为补充（用于标记依赖类型和SLA影响）。每周运行一次依赖一致性校验任务，将自动发现结果与CMDB配置进行差异对比，生成变更工单。
3.7 元数据在Golden Signals中的应用
服务画像元数据最终要服务于日志Golden Signals指标设计。以下SVG图展示了元数据如何嵌入到告警规则和日志聚合中：
通过将服务画像元数据注入到指标采集和告警规则中，可以实现以下能力：
- 动态告警路由：根据Owner字段自动将告警发送到对应值班组。
- SLO燃烧率计算：基于SLO目标值计算剩余错误预算，触发不同级别的告警。
- 依赖影响分析：当下游依赖故障时，自动标记所有上游服务为“受影响”，并抑制非根因告警。
- 日志上下文增强：在日志采集时自动注入服务名称和ID，便于跨服务关联分析。