4. 自助目录架构总览：分层架构设计与核心组件
本章是整门课程的技术骨架。我们将从采集、处理、存储、目录、消费五个层面，拆解一个由可靠性评审驱动的 OpenTelemetry 自助目录系统。每一层都承担明确的职责，并通过标准化接口与上下游协作。理解分层架构，是后续设计评审规则、目录模型、自助 API 的基础。
4.1 五层架构总览
自助目录架构采用经典的“采集 → 处理 → 存储 → 目录 → 消费”流水线模型。每一层内部包含若干核心组件，组件之间通过 OpenTelemetry 协议（OTLP）或内部 gRPC/HTTP 接口通信。
| 层级 | 核心职责 | 关键组件 | 输出产物 |
|---|---|---|---|
| 采集层 | 从各类数据源（应用、基础设施、第三方）收集遥测数据 | OTel Collector、Instrumentation SDK、Receiver | OTLP 格式的 Span/Metric/Log |
| 处理层 | 数据清洗、采样、增强、路由、可靠性校验 | Processor Pipeline、Batch Processor、Reliability Validator | 清洗后的结构化遥测数据 |
| 存储层 | 持久化遥测数据与目录元数据 | 时序数据库、对象存储、元数据库 | 可查询的存储记录 |
| 目录层 | 管理数据资产目录、Schema 注册、血缘关系 | Catalog Service、Schema Registry、Lineage Engine | 目录索引、Schema 定义、血缘图 |
| 消费层 | 提供查询、可视化、告警、自助 API | Query Service、Dashboard、Alert Manager、Self-Service API | API 响应、图表、告警通知 |
下图展示了五层架构的整体拓扑与数据流向。注意，目录层并非数据流的终点，而是作为元数据中枢，为消费层提供数据发现与 Schema 校验能力。
4.2 采集层：数据入口的标准化
采集层是遥测数据的第一个接触点。它必须解决三个核心问题：数据源多样性、协议标准化、低开销采集。
- OTel Collector：作为统一网关，接收来自各种 SDK 和 exporter 的数据。支持 receiver（接收）、processor（处理）、exporter（导出）三种组件。
- Instrumentation SDK：嵌入应用代码，自动或手动生成 Span、Metric、Log。推荐使用自动注入（Java Agent、Python SDK）减少侵入。
- Receiver 适配器：将非 OTLP 协议（如 Prometheus Remote Write、Zipkin、Jaeger）转换为内部统一格式。
4.3 处理层：数据清洗与可靠性校验
处理层是架构中最复杂的环节。它不仅要完成数据格式转换、采样、属性增强，还要执行可靠性校验——这是本课程的核心创新点。
| 处理器类型 | 功能 | 可靠性相关 |
|---|---|---|
| Batch Processor | 合并小数据包，减少存储写入次数 | 防止写入风暴 |
| Attributes Processor | 添加、删除、修改 Span/Metric 属性 | 确保必填字段存在 |
| Sampling Processor | 基于规则或概率采样 | 保证关键链路不丢失 |
| Reliability Validator | 校验数据完整性、Schema 合规性、血缘连续性 | 核心：拒绝脏数据进入目录 |
Reliability Validator 是处理层的“守门员”。它根据目录层下发的 Schema 规则，逐条校验遥测数据：
- Span 是否包含 trace_id、span_id、parent_span_id？
- Metric 的 label 是否与注册的 Schema 一致？
- Log 的 severity 字段是否在允许范围内？
校验失败的数据会被路由到死信队列（Dead Letter Queue），并触发告警。这种设计防止了脏数据污染目录层和存储层。
4.4 存储层：时序数据与元数据分离
存储层采用混合存储架构：时序数据库（如 VictoriaMetrics、ClickHouse）存储高吞吐的遥测数据；对象存储（如 S3、MinIO）存储原始日志和长周期归档；元数据库（如 PostgreSQL、TiDB）存储目录元数据。
这种分离设计带来三个好处：
- 性能隔离：时序数据库专注于高写入吞吐，元数据库专注于强一致性查询。
- 成本优化：原始日志和低频数据存入对象存储，降低热存储成本。
- 目录独立性：目录层只依赖元数据库，不直接访问时序数据，避免查询放大。
4.5 目录层：数据资产的中枢
目录层是自助目录架构的“大脑”。它管理三类核心信息：
- 数据资产目录：记录每个数据源、服务、接口的元信息（名称、版本、负责人、标签）。
- Schema 注册表：存储每个数据资产的字段定义、类型、约束、可靠性规则。
- 血缘关系：记录数据从采集到消费的完整链路，包括上下游依赖、转换逻辑。
目录层通过 gRPC 接口向处理层提供 Schema 校验规则，向消费层提供数据发现和血缘查询能力。它是可靠性评审的“规则下发中心”。
4.6 消费层：自助能力的外化
消费层面向最终用户（SRE、开发、运维）提供四种能力：
| 能力 | 接口形式 | 典型场景 |
|---|---|---|
| 数据查询 | REST / GraphQL | 查询某服务过去 1 小时的 P99 延迟 |
| 可视化 | Grafana / 自定义 Dashboard | 展示服务拓扑与调用链火焰图 |
| 告警 | Alert Manager + Webhook | 当错误率超过阈值时通知 On-Call |
| 自助 API | gRPC / REST | 开发者自助注册新数据源、更新 Schema、查询血缘 |
自助 API 是消费层的核心。它允许用户不经过人工审批，直接通过 API 完成数据资产注册、Schema 更新、可靠性规则配置。这些操作会触发目录层的版本变更，并同步到处理层的 Reliability Validator。
4.7 层间契约与数据流
五层架构的稳定性依赖于清晰的层间契约。我们定义了三种契约类型：
- 数据契约：OTLP 协议 + Protobuf Schema。采集层到处理层、处理层到存储层均使用 OTLP。
- 元数据契约：目录层定义的 Schema 注册表格式。处理层通过 gRPC 拉取校验规则。
- 查询契约：消费层与存储层之间的查询语言（PromQL、SQL、TraceQL）。
任何层间接口变更都必须经过可靠性评审，确保向后兼容。这是本课程后续章节会深入展开的评审流程。