2. 日志平台核心组件：采集器、缓冲层、流处理器、存储引擎的拓扑关系
日志平台从数据产生到最终可查询，需要经过四个核心阶段：采集、缓冲、处理、存储。这四个阶段分别由 Agent、Kafka、Stream Processor、Elasticsearch 承担。理解它们之间的拓扑关系，是设计控制平面调度策略的前提。
2.1 四层拓扑总览
下图展示了日志平台的标准四层拓扑结构。数据从左至右单向流动，每一层都承担明确的职责，并通过网络协议与相邻层交互。
拓扑要点：四层之间通过 TCP/HTTP 协议连接，每一层都可以水平扩展。控制平面的调度策略主要作用于 Stream Processor 和 Elasticsearch 两层，因为这两层对资源消耗和延迟最敏感。
2.2 各组件职责与交互关系
| 层级 | 核心组件 | 主要职责 | 与上下游交互方式 |
|---|---|---|---|
| 采集器 | Filebeat / Fluentd | 从服务器、容器、应用日志文件中读取数据，进行简单过滤后发送 | 通过 Kafka Producer API 写入 Topic |
| 缓冲层 | Kafka | 持久化存储日志流，解耦生产者和消费者，提供高吞吐缓冲 | Producer → Broker → Consumer Group |
| 流处理器 | Logstash / Flink | 解析、过滤、转换、富化日志数据，按规则路由到不同索引 | 通过 Kafka Consumer API 消费，通过 ES Bulk API 写入 |
| 存储引擎 | Elasticsearch | 索引存储、全文检索、聚合分析，对外提供查询接口 | 接收 HTTP/REST 请求，返回 JSON 响应 |
2.3 拓扑中的关键数据流
日志数据在四层拓扑中流转时，会经历以下关键阶段：
- 采集阶段：Agent 监听日志文件变化，按行读取并封装为 JSON 事件，通过异步批量发送到 Kafka。
- 缓冲阶段：Kafka 按 Topic 和 Partition 存储日志，每个 Partition 内部保证顺序，通过副本机制保证数据不丢。
- 处理阶段：Stream Processor 从 Kafka 拉取数据，执行解析（如 Grok）、过滤（如丢弃 debug 日志）、转换（如添加时间戳字段），然后批量写入 ES。
- 存储阶段：Elasticsearch 将数据按索引分片存储，每个分片是一个 Lucene 实例，支持近实时搜索。
性能关键点：整个拓扑的吞吐瓶颈通常出现在 Stream Processor → ES 的写入链路。控制平面调度策略需要动态调整 Stream Processor 的并行度和 ES 的写入队列深度，以匹配 Kafka 的消费速率。
2.4 拓扑中的调度决策点
控制平面调度策略在四层拓扑中主要关注以下决策点：
- Agent 端：是否需要限速？是否需要根据日志级别分流到不同 Topic？
- Kafka 端：Partition 数量如何与 Stream Processor 的并行度匹配？是否需要调整副本因子？
- Stream Processor 端：Worker 数量、Batch Size、Flush Interval 如何动态调整？
- ES 端：Shard 数量、Refresh Interval、Bulk Queue 大小如何随负载变化？
下图展示了控制平面调度策略在拓扑中的具体作用位置：
常见误区：很多团队只关注 ES 的写入优化，忽略了 Stream Processor 的并行度与 Kafka Partition 的匹配关系。如果 Stream Processor 的消费者数大于 Partition 数，多余的消费者会闲置，造成资源浪费。
2.5 拓扑关系总结
日志平台的四层拓扑是一个典型的生产者-缓冲-消费者-存储模型。每一层都承担明确的职责，并通过标准协议解耦。控制平面调度策略的核心目标，就是在这四层之间找到最优的吞吐-延迟-成本平衡点。
| 层级 | 调度目标 | 主要可调参数 | 性能指标 |
|---|---|---|---|
| Agent | 避免发送过快导致背压 | 采集速率、批量大小 | 发送延迟、丢包率 |
| Kafka | 保证吞吐与持久性 | Partition 数、副本数 | 写入吞吐、磁盘使用率 |
| Stream Processor | 匹配消费与写入速率 | 并行度、Batch Size、Flush Interval | 处理延迟、CPU 使用率 |
| Elasticsearch | 保证写入与查询性能 | Shard 数、Refresh Interval、Bulk Queue | 写入延迟、查询 QPS |