4. 数据采集层架构：从CMDB、监控系统、APM、日志平台采集数据的管道设计
服务画像的底层依赖是高质量、低延迟、结构化的多源数据。数据采集层作为整个画像系统的“神经末梢”，需要从CMDB、监控系统、APM、日志平台等异构数据源中抽取原始数据，经过清洗、标准化、关联后，统一写入画像存储层。本章详细阐述采集管道的架构设计、核心组件与关键实现策略。
4.1 数据源全景与采集挑战
服务画像需要覆盖静态属性、动态指标、调用链路与事件日志四类数据。不同数据源在协议、粒度、实时性上差异巨大，采集层必须统一抽象。
| 数据源类型 | 典型系统 | 数据内容 | 采集协议 | 实时性要求 |
|---|---|---|---|---|
| CMDB | 配置管理数据库 | 服务实例、主机、网络、中间件、应用配置 | REST API / GraphQL | 分钟级（变更驱动） |
| 监控系统 | Prometheus / Zabbix / CloudWatch | CPU、内存、磁盘、网络、业务指标 | HTTP Pull / Push Gateway | 秒级～分钟级 |
| APM | SkyWalking / Jaeger / Datadog | 调用链、服务拓扑、Span 详情、错误追踪 | gRPC / HTTP / Kafka | 秒级（实时追踪） |
| 日志平台 | ELK / Loki / Splunk | 应用日志、访问日志、系统日志、审计日志 | Filebeat / Fluentd / HTTP | 秒级～分钟级 |
常见陷阱：直接使用各数据源的原生API进行实时查询，会导致源系统负载过高，甚至引发生产故障。采集层必须引入缓冲、限流与异步化机制。
4.2 采集管道总体架构
采用“采集器 → 缓冲队列 → 流处理引擎 → 画像存储”的分层管道设计，确保数据不丢失、不重复、可回溯。
4.3 核心组件设计
4.3.1 采集器（Collector）
采集器是贴近数据源的轻量级进程，负责执行实际的数据拉取或接收任务。根据数据源类型，采集器分为三类：
- Pull 型采集器：定期调用 CMDB API、Prometheus HTTP API 获取全量或增量数据。适用于静态配置和周期性指标。
- Push 型采集器：接收 APM Agent、日志 Agent 主动上报的数据流。适用于高吞吐、低延迟的链路和日志数据。
- 事件驱动型采集器：监听 CMDB 变更事件、Kubernetes Watch API，实现准实时配置同步。
最佳实践：采集器应内置健康检查、重试退避、限流熔断。推荐使用 Go 或 Rust 编写，以降低资源开销。每个采集器实例负责不超过 200 个数据源端点。
4.3.2 缓冲队列（Message Queue）
缓冲层是管道的“蓄水池”，解决生产端与消费端速率不匹配问题。推荐使用 Apache Kafka 或 Apache Pulsar。
| 特性 | Kafka | Pulsar |
|---|---|---|
| 吞吐量 | 极高（百万级 msg/s） | 高（十万级 msg/s） |
| 消息持久化 | 基于磁盘顺序读写 | 基于 BookKeeper 分层存储 |
| 多租户 | 需 Topic 命名空间隔离 | 原生支持 |
| 消息顺序 | 分区内严格有序 | 分区内严格有序 |
| 运维复杂度 | 中等（依赖 Zookeeper） | 较高（依赖 BookKeeper） |
建议按数据源类型划分 Topic：cmdb-service、monitor-metric、apm-span、log-event。每个 Topic 设置合理的分区数（通常为 6～12），以支持并行消费。
4.3.3 流处理引擎（Stream Processor）
流处理引擎是管道的“大脑”，负责执行数据清洗、字段映射、多源关联、去重与画像模型转换。核心处理逻辑包括：
- 数据标准化：将不同来源的时间戳、IP 格式、标签命名统一为画像内部规范。
- 实体关联：通过 service_id、instance_id、host_id 将 CMDB 的静态属性与监控指标、APM 链路、日志事件关联到同一服务实例。
- 去重与乱序处理：利用事件时间（Event Time）与 Watermark 机制，处理延迟到达或重复上报的数据。
- 画像模型转换：将原始数据转换为画像存储层所需的宽表结构或图结构。
4.4 数据质量保障策略
采集管道必须内置数据质量监控，避免“垃圾进，垃圾出”。关键策略包括：
- Schema 校验：在采集器或流处理阶段，对每条数据执行 JSON Schema / Protobuf 校验，拒绝格式错误的数据。
- 完整性检查：统计每个时间窗口内各数据源的数据条数、字段缺失率，低于阈值时触发告警。
- 延迟监控：记录每条数据从产生到进入画像存储的端到端延迟（E2E Latency），P99 延迟应小于 30 秒。
- 数据血缘追踪：在每条数据中注入 source、collector_id、processing_timestamp 等元数据，便于问题回溯。
实施建议：在 Kafka 消费者端启用“死信队列”（DLQ），将解析失败或关联失败的数据单独存储，供人工排查，避免阻塞主流程。
4.5 采集管道部署与高可用
采集管道本身必须高可用，不能成为单点故障。部署架构应满足：
- 采集器多副本：每个采集器至少部署 2 个副本，分布在不同可用区。使用一致性哈希或轮询策略分配数据源。
- Kafka 集群：至少 3 个 Broker，副本因子设为 3，确保单节点故障不影响数据写入。
- 流处理引擎容错：Flink 开启 Checkpoint，间隔 60 秒；发生故障时自动从最近 Checkpoint 恢复，保证 Exactly-Once 语义。
- 幂等写入：画像存储层支持幂等写入（基于主键去重），防止流处理重放导致数据重复。
4.6 本章小结
数据采集层是服务画像的基石。通过“采集器 + 缓冲队列 + 流处理引擎”的三层管道设计，能够高效、可靠地从 CMDB、监控、APM、日志平台汇聚数据。核心要点包括：
- 针对不同数据源选择合适的采集协议与采集器类型。
- 利用 Kafka/Pulsar 实现削峰填谷与数据持久化。
- 流处理引擎负责数据标准化、实体关联与画像模型转换。
- 内置 Schema 校验、延迟监控、死信队列等质量保障机制。
- 采集管道自身必须高可用，支持多副本、容错恢复与幂等写入。