3 顶层架构分层：采集层、传输层、处理层、存储层、分析层
本章将定义 Agent 埋点体系的边界与五层逻辑架构——采集层、传输层、处理层、存储层、分析层。每层有明确的职责边界、输入输出契约，并通过 数据流、控制流 和 信任链路 形成完整拓扑。理解这五层是后续选型、容灾、审计设计的基础。
3.1 边界与分层职责
五层架构的核心理念是职责单一和契约解耦。每层只处理特定类型的问题，并向上层暴露明确的接口，从而降低变更影响面。
| 层级 | 职责边界 | 输入 | 输出 | 典型组件 |
|---|---|---|---|---|
| 采集层 | 负责从 Agent Runtime、SDK、Hook 中抓取原始埋点事件，完成基础格式化和本地缓存 | Agent 内部日志、指标、链路数据 | 标准化 Event 包（Proto/JSON） | Collector Agent、Filebeat、Fluent Bit |
| 传输层 | 保障数据从 Agent 节点到后端处理集群的可靠、低延迟、加密传输 | Event 包 | 确认写入的 ACK 日志 | Kafka / Pulsar / gRPC Stream |
| 处理层 | 对原始 Event 进行清洗、富化、过滤、会话拼接、实体关联，产出 Reach/Impact 特征 | 原始 Event 流 | 清洗后 Event 及特征表增量 | Flink / Spark Structured Streaming |
| 存储层 | 按查询模式设计多级存储（实时、近实时、离线），保留完整审计轨迹与快照 | 处理后的 Feature 数据 | OLAP / 时序 / 对象存储视图 | ClickHouse / StarRocks / S3 |
| 分析层 | 对外暴露查询 API、看板、报警规则，支撑 Reach 建模与 Impact 归因计算 | 预聚合数据、维度表 | 分析结果、仪表盘、异步报表 | Apache Superset / Grafana / Spark SQL |
3.2 层间依赖关系与数据流/控制流/信任链路
层间关系不只是数据的上下传递，还包含控制信令和信任校验。理解这三条链路是架构设计的关键。
数据流（Data Flow）： 自底向上，采集→传输→处理→存储→分析。每层对数据做增强或转换，数据流是单向的、异步的、以批量或微批方式流动。
控制流（Control Flow）： 自顶向下，分析层可向处理层下发策略更新（如采样阈值），处理层向传输层回执背压信号，传输层可要求采集层减速或重试。
信任链路（Trust Chain）： 贯穿五层。采集层负责签名原始事件，传输层校验签名，处理层校核数据完整性，存储层记录签发哈希，分析层审计血缘。任何一层破坏签名都会导致数据标记为不可信。
控制流（Control Flow）： 自顶向下，分析层可向处理层下发策略更新（如采样阈值），处理层向传输层回执背压信号，传输层可要求采集层减速或重试。
信任链路（Trust Chain）： 贯穿五层。采集层负责签名原始事件，传输层校验签名，处理层校核数据完整性，存储层记录签发哈希，分析层审计血缘。任何一层破坏签名都会导致数据标记为不可信。
常见陷阱： 很多团队在初期只设计数据流，忽略控制流。当处理层发生拥堵时，传输层仍无限制地推数据，导致内存溢出或数据丢失。必须为每层定义明确的“背压契约”：传输层应支持 TTL 与死信队列，处理层应能返回背压状态码（如 HTTP 429 / Kafka 限速参数）。
3.3 关键选型权衡
每层都有多个主流选型，选型需结合数据规模、延迟容忍度、运维成本：
| 场景 / 约束 | 推荐方案 | 备选方案 | 淘汰理由 |
|---|---|---|---|
| 采集端资源紧张（容器化 Agent） | Fluent Bit（C 实现，低内存） | Vector | Filebeat 依赖 Java，内存高 |
| 传输层需要强事务保障 | Kafka（min.insync.replicas=2） | Pulsar（无 ack 积压风险） | RabbitMQ 吞吐不足 |
| 处理层需要精确一次语义 | Flink（Checkpoint + 幂等sink） | Spark Structured Streaming | Storm 已过时 |
| 存储层要求实时多维查询 | ClickHouse（MergeTree 表引擎） | Doris / StarRocks | MySQL + 搜索方案不可扩展 |
| 分析层需要自助分析 | Apache Superset（SQL 原生） | Metabase | Tableau 许可成本高 |
3.4 风险点
- 跨层限流缺失：采集层无限推送到传输层，导致 Kafka Topic 膨胀 10 倍，消费者 Lag 飙升。解决：在传输层入口设置 rate limiter（如 20,000 msg/s/partition），并返回背压信号。
- 传输层背压未反馈：Kafka 默认配置下，生产者会直接丢弃超限消息。必须设置
max.in.flight.requests.per.connection=1和retries=Long.MAX_VALUE配合重试。 - 处理层 late data 失控：Flink 默认只处理 within watermark 的数据，未配置 allowed lateness 会导致后期抵事件被丢弃。需根据业务容忍度设置
allowedLateness(60s)并打回侧输出。 - 存储层 Schema 演化不兼容：多版本 Agent 可能输出不同字段，直接写入 ClickHouse 会抛异常。需在处理层统一用
ALTER TABLE在低峰期加列，或使用 Map 类型兜底。 - 分析层查询穿透：用户自定义 SQL 直接扫描存储层全表，IO 打满。必须前置 Query Rouger 或查询网关（如 Trino），并限制扫描行数。
3.5 落地步骤
- 定义层间契约：确定每层的数据格式（Proto 文件）、必填字段、签名规则和超时阈值。
- 先实现单层最小闭环：从采集层开始，使之能在本地 Kafka 正常写入并验证签名。
- 逐层串联，启动数据流测试：依次连接传输层、处理层、存储层，用模拟 Agent 数据验证每个环节的输出格式和延迟。
- 注入控制流与信任检测：为处理层增加背压响应，为存储层添加哈希校验字段，部署校验探针。
- 灰度接入真实 Agent 流量：从 1% 流量开始，逐步拉伸至全量，观测每层的吞吐延迟和错误率。
- 建立层级监控仪表盘：每层暴露 Health / Lag / Error Rate / Trust Drop Rate 四个黄金信号。
3.6 验收标准
验收清单（每层至少满足 3 项）：
✅ 数据流：端到端延迟 P99 ≤ 10s（从 Agent emit 到分析层可见）；
✅ 控制流：当处理层 CPU > 80% 时，传输层有效拉低入流量 ≥ 50%；
✅ 信任链路：任意篡改事件在传输层被标记，且在 5 分钟内进入死信表；
✅ 架构扩展性：单层水平扩展不影响其他层数据完整性；
✅ 运维标准：每层配置审计日志，变更记录可追溯至变更工单。
✅ 数据流：端到端延迟 P99 ≤ 10s（从 Agent emit 到分析层可见）；
✅ 控制流：当处理层 CPU > 80% 时，传输层有效拉低入流量 ≥ 50%；
✅ 信任链路：任意篡改事件在传输层被标记，且在 5 分钟内进入死信表；
✅ 架构扩展性：单层水平扩展不影响其他层数据完整性；
✅ 运维标准：每层配置审计日志，变更记录可追溯至变更工单。