1. 课程导论与演进总览
1.1 多集群日志平台的定义
多集群日志平台是指能够跨多个 Kubernetes 集群（或物理/虚拟机组）统一采集、传输、存储、检索与分析日志的基础设施层。其核心目标在于：
- 全局可观测性：打破集群边界，提供单一视图查看所有业务日志。
- 运维效率：避免运维人员反复登录不同集群或跳板机。
- 数据合规与治理：在跨地域、跨部门场景下统一日志保留策略与访问控制。
关键认知：多集群日志平台不是多个单集群日志系统的简单叠加，而是需要解决数据路由、去重、排序、一致性校验等分布式系统难题的复杂平台。
1.2 核心挑战：数据孤岛、一致性、成本
在构建多集群日志平台时，团队通常会面临三大核心挑战：
| 挑战维度 | 具体表现 | 典型后果 |
|---|---|---|
| 数据孤岛 | 每个集群独立部署日志组件，日志分散在各自存储后端，缺乏全局索引。 | 故障排查需逐个集群查询，MTTR（平均修复时间）延长 3~5 倍。 |
| 一致性 | 跨集群日志存在时钟偏差、重复采集、乱序到达等问题。 | 链路追踪与根因分析结果不可信，告警误报率上升。 |
| 成本 | 日志数据量随集群数量线性增长，存储与网络带宽开销失控。 | 日志系统预算占比从 5% 飙升至 20% 以上，被迫降采样或丢弃数据。 |
避坑提示：很多团队在初期只关注“能否采集”，忽略了“能否跨集群关联”。当集群数超过 5 个时，数据孤岛问题会急剧放大，导致平台建设返工。
1.3 架构演进的四个阶段总览
本课程将多集群日志平台的架构演进划分为四个典型阶段。每个阶段都对应特定的业务规模、团队成熟度与技术约束：
- 单体阶段：每个集群独立部署一套日志栈（如 EFK/ELK），组件间无跨集群通信。
- 集中阶段：引入中心化存储或传输层，日志统一写入远端集群，但采集端仍各自为政。
- 联邦阶段：建立联邦查询层，各集群保留本地存储，通过统一网关实现跨集群检索。
- 统一阶段：全局统一的元数据管理、数据路由、去重与排序引擎，实现真正的“一次采集、全局可用”。
1.4 各阶段核心特征对比
下表从数据流、查询方式、一致性保障、运维复杂度四个维度对比四个阶段的差异：
| 维度 | 单体阶段 | 集中阶段 | 联邦阶段 | 统一阶段 |
|---|---|---|---|---|
| 数据流 | 集群内闭环 | 采集→中心存储 | 本地存储+按需拉取 | 全局路由+流式处理 |
| 查询方式 | 逐集群登录 | 中心化查询 | 联邦网关分发 | 统一查询接口 |
| 一致性 | 无跨集群保证 | 依赖中心时序 | 部分排序，有重复 | 全局去重+排序 |
| 运维复杂度 | 低（独立运维） | 中（中心组件高可用） | 中高（网关+本地存储） | 高（元数据+流引擎） |
课程路线图：本课程将按照上述四个阶段的顺序，逐章深入每个阶段的组件拓扑、选型依据、迁移策略与典型踩坑案例。第 2~5 章分别对应单体→集中→联邦→统一的详细设计，第 6 章开始进入高阶主题（如多租户、成本优化、混沌工程）。
1.5 本章小结
本章明确了多集群日志平台的定义与三大核心挑战，并给出了架构演进的四个阶段总览。从单体到统一，每一次演进都是在解决前一阶段遗留的痛点：
- 单体解决了“有日志”的问题，但带来了“查不到”的孤岛。
- 集中解决了“统一查”的问题，但引入了带宽与单点风险。
- 联邦解决了“灵活查”的问题，但留下了“不一致”的隐患。
- 统一通过全局元数据与流式处理，最终实现“可信查”。
接下来的章节将逐一拆解每个阶段的组件拓扑、选型对比与迁移路径，帮助你在实际业务中做出合理的架构决策。