2. 服务画像基础：服务画像的构成要素
服务画像是制品供应链误差预算模型的核心数据底座。它并非简单的服务元数据清单，而是对服务在供应链中身份、行为、关系与性能边界的结构化数字映射。本章聚焦画像的三大构成要素及其采集存储方案。
2.1 画像构成三要素
服务画像由元数据、依赖关系和性能基线三个维度构成，三者共同支撑误差预算的分配与异常检测。
| 维度 | 定义 | 核心字段示例 | 在误差预算中的作用 |
|---|---|---|---|
| 元数据 | 服务的静态身份与属性信息 | 服务名、版本、Owner、Git仓库、部署环境、制品类型 | 确定预算归属、制品溯源、变更影响域 |
| 依赖关系 | 服务间的调用、数据流与部署依赖 | 上游服务、下游服务、中间件、数据库、配置中心 | 计算级联预算消耗、定位误差传播路径 |
| 性能基线 | 服务在稳态下的关键指标分布 | P99延迟、吞吐量、错误率、CPU/内存利用率 | 设定预算阈值、识别异常偏移、量化误差幅度 |
关键认知：元数据回答“我是谁”，依赖关系回答“我和谁相连”，性能基线回答“我正常时什么样”。三者缺一不可，共同构成误差预算台账的“服务指纹”。
2.2 元数据：服务的数字身份证
元数据是服务画像中最稳定、最基础的部分。在制品供应链场景下，元数据不仅包含传统CMDB信息，还需纳入制品构建与交付的上下文。
- 基础身份：service_id、service_name、cluster、namespace、owner_team、oncall_pager。
- 制品溯源：artifact_repo、artifact_name、artifact_version、commit_sha、build_job_id。
- 部署属性：deployment_strategy（蓝绿/金丝雀/滚动）、replicas、container_image、config_version。
- 治理标签：criticality（P0/P1/P2）、data_sensitivity、compliance_zone、cost_center。
采集方式：元数据通常通过Kubernetes API、CMDB接口、CI/CD流水线事件（如Jenkins/GitLab Webhook）以及服务注册中心（Consul/Eureka）自动采集，辅以人工录入的治理标签。
2.3 依赖关系：供应链的拓扑骨架
依赖关系决定了误差预算的传播路径。一个下游服务的延迟抖动，可能通过调用链放大为上游的预算超支。依赖关系分为静态依赖与动态依赖。
- 静态依赖：通过代码分析、配置清单、服务网格（Service Mesh）声明获取。例如：
service-a调用service-b的 gRPC接口，依赖redis-cluster和mysql-shard-0。 - 动态依赖：通过分布式追踪（如Jaeger/Zipkin）和调用链分析实时发现。例如：某次流量高峰时
service-a临时调用了service-c的降级接口。
依赖关系的数据模型通常采用有向图结构，节点为服务或中间件，边为调用关系，边上可附加延迟、QPS、错误率等运行时指标。
避坑提示：仅依赖静态配置会遗漏临时调用、故障转移路径和动态路由。建议以静态依赖为骨架，以动态追踪为血液，定期（如每15分钟）合并更新依赖图。
2.4 性能基线：误差预算的度量标尺
性能基线是服务在无故障、无变更、正常负载下的指标分布。误差预算的“误差”正是相对于基线而言的偏移量。
基线通常包含以下指标维度：
| 指标类别 | 典型指标 | 聚合方式 | 基线更新频率 |
|---|---|---|---|
| 延迟 | P50/P90/P99 latency (ms) | 滑动窗口分位数 | 每小时 |
| 吞吐 | RPS、TPS、连接数 | 均值 + 标准差 | 每小时 |
| 错误 | HTTP 5xx率、gRPC错误率、超时率 | EWMA（指数加权移动平均） | 每5分钟 |
| 资源 | CPU使用率、内存使用率、GC暂停时间 | P95 + 趋势斜率 | 每10分钟 |
基线计算要点：基线应剔除已知故障窗口、大版本发布窗口和压测窗口的数据。推荐使用周期性季节性分解（如STL算法）提取趋势与周期成分，避免将业务峰谷误判为异常。
2.5 画像数据的采集与存储架构
服务画像的采集与存储需要支持多源异构数据的实时摄取与高效查询。下图展示了推荐的采集与存储架构。
架构要点：
- 采集层采用统一管道，避免每个数据源独立对接，降低运维复杂度。
- 处理层区分流处理（实时依赖发现、指标聚合）与批处理（基线计算、历史画像重建）。
- 存储层按数据类型选择专用引擎：关系库存元数据，图库存依赖，列式库存基线时序数据，对象存储存全量快照。
- 查询层提供统一API，屏蔽底层存储差异，支持按服务名、时间范围、依赖路径等维度检索画像。
2.6 画像数据的生命周期管理
服务画像数据具有时效性。一个服务的依赖关系和性能基线会随版本发布、架构调整、流量特征变化而演变。建议采用以下策略：
- 版本化快照：每次部署或重大变更时，生成一份完整的画像快照，存储在对象存储中，用于历史回溯与误差预算复盘。
- 增量更新：元数据变更通过事件驱动实时更新；依赖关系每5分钟增量合并；基线每10~60分钟滑动更新。
- 数据保留：基线时序数据保留30天用于短期趋势分析；快照保留90天用于审计；聚合后的画像摘要保留1年。
实践建议：在制品供应链误差预算模型中，画像数据应作为一等公民纳入数据治理体系。建议为每个服务维护一个
service_profile 的 Protobuf 或 Avro schema，统一序列化格式，方便跨团队消费。