4. 组件拓扑图设计原则：节点定义、边关系、分层架构、依赖关系在拓扑图中的表达
在 Log Label 接入云原生日志平台后，组件拓扑图不再是静态的架构展示，而是承载租户配额计量路径的核心模型。拓扑图中的每一个节点、每一条边，都必须精确映射到实际的数据流与资源消耗链路。本节将围绕节点定义、边关系、分层架构与依赖关系四个维度，阐述拓扑图的设计原则。
4.1 节点定义：从物理组件到逻辑计量单元
拓扑图中的节点不应仅代表“服务进程”或“容器”，而应抽象为具备配额计量属性的逻辑单元。每个节点需包含以下元数据：
- 节点类型：标识该节点在日志链路中的角色（采集、缓冲、索引、存储、查询）。
- 资源消耗因子：单位日志量在该节点产生的计算/存储开销（如 CPU 毫核/GB、内存 MB/GB、存储 GB/天）。
- 租户归属：该节点处理的日志流所对应的租户 ID 或标签组。
- 状态：活跃、降级、熔断，直接影响配额是否被计入。
设计要点：节点定义应遵循“一个节点一个计量职责”原则。避免将采集与过滤合并为一个节点，否则无法区分“原始日志摄入量”与“有效日志存储量”的配额差异。
| 节点类型 | 计量职责 | 典型配额指标 | 示例节点名称 |
|---|---|---|---|
| 采集节点 | 日志原始摄入量 | 每秒日志条数、入流量 MB/s | filebeat-agent |
| 缓冲节点 | 临时存储与重试 | 缓冲队列深度、磁盘占用 | kafka-broker |
| 索引节点 | 日志解析与建索引 | 索引吞吐量、CPU 消耗 | log-indexer |
| 存储节点 | 日志持久化 | 存储容量、IOPS | hot-tier-storage |
| 查询节点 | 日志检索与聚合 | 查询并发数、扫描数据量 | query-frontend |
4.2 边关系：数据流与配额传递路径
拓扑图中的边代表日志数据的流动方向，同时也是配额计量的传递路径。每条边应携带以下属性：
- 数据量：单位时间内经过该边的日志体积（GB/h）或条数。
- 压缩比：数据经过该边后体积变化系数（如采集到缓冲压缩比为 0.3）。
- 过滤率：经过该边时被丢弃或降采样的日志比例。
- 租户标签：该边传输的日志流所属的租户标识。
边关系核心公式：
拓扑图通过边属性实现配额消耗的逐级传递与校准。
下游节点配额消耗 = 上游节点输出量 × 压缩比 × (1 - 过滤率)拓扑图通过边属性实现配额消耗的逐级传递与校准。
4.3 分层架构：四层拓扑模型
云原生日志平台的组件拓扑图采用四层分层架构，每层聚焦不同的计量粒度：
- 接入层：包含采集 Agent、负载均衡器、日志网关。负责日志的接收与初步校验。
- 传输层：包含消息队列、流处理引擎。负责日志的缓冲、路由与分发。
- 处理层：包含索引器、转换器、聚合器。负责日志的解析、结构化与索引构建。
- 存储层：包含热存储、温存储、冷存储。负责日志的持久化与生命周期管理。
4.4 依赖关系：显式与隐式依赖的拓扑表达
组件间的依赖关系决定了配额校准的先后顺序与级联影响。在拓扑图中，依赖关系分为两类：
| 依赖类型 | 表达方式 | 示例 | 对配额的影响 |
|---|---|---|---|
| 显式依赖 | 实线箭头 + 依赖标签 | 索引器 → 存储节点 | 上游配额消耗未完成时，下游不计费 |
| 隐式依赖 | 虚线箭头 + 条件标签 | 采集 Agent → 租户元数据服务 | 元数据不可用时，配额归属无法确定 |
常见陷阱：隐式依赖容易被忽略。例如，采集 Agent 依赖 DNS 解析服务，若 DNS 故障导致日志路由错误，配额可能被错误计入其他租户。拓扑图中必须显式标注此类隐式依赖。
4.5 依赖关系拓扑图示例
以下拓扑图展示了 Log Label 组件间的显式与隐式依赖关系，以及配额计量路径：
4.6 设计原则总结
核心原则速查：
• 节点原子化：每个节点只承担一种计量职责，避免职责混叠导致配额计算偏差。
• 边属性完整：每条边必须携带数据量、压缩比、过滤率、租户标签，缺一不可。
• 分层清晰：接入、传输、处理、存储四层严格分离，层间通过标准接口传递计量上下文。
• 依赖显式化：所有隐式依赖必须用虚线箭头标注，并在元数据中记录依赖条件与故障影响范围。
• 节点原子化：每个节点只承担一种计量职责，避免职责混叠导致配额计算偏差。
• 边属性完整：每条边必须携带数据量、压缩比、过滤率、租户标签，缺一不可。
• 分层清晰：接入、传输、处理、存储四层严格分离，层间通过标准接口传递计量上下文。
• 依赖显式化：所有隐式依赖必须用虚线箭头标注，并在元数据中记录依赖条件与故障影响范围。