4. 日志架构演进：从单体日志到分布式日志，再到多租户日志平台的架构演进路线
日志系统是后端可观测性的基石。随着业务规模从单机走向分布式、从单一团队走向多租户平台，日志架构也经历了三次关键演进。理解这条演进路线，是设计多租户隔离日志平台的前提。
4.1 第一阶段：单体日志架构
在单体应用时代，日志通常直接写入本地文件系统。应用进程通过日志框架（如 Log4j、Logback）将日志输出到磁盘文件，运维人员通过 SSH 登录服务器，使用 tail、grep 等命令排查问题。
核心特征： 本地文件存储、无集中采集、无租户概念、依赖人工登录排查。
| 维度 | 单体日志架构 |
|---|---|
| 存储 | 本地磁盘文件 |
| 采集 | 无，直接写入文件 |
| 检索 | tail / grep / less |
| 租户隔离 | 不适用 |
| 典型问题 | 磁盘写满、日志丢失、无法跨主机关联 |
架构局限： 单体日志无法应对微服务拆分后的跨服务调用链追踪，也无法满足多团队共享基础设施时的数据隔离需求。
4.2 第二阶段：分布式日志架构
当应用拆分为微服务，日志分散在成百上千个容器或虚拟机中。分布式日志架构应运而生，核心模式为：采集 → 缓冲 → 传输 → 存储 → 检索。
典型技术栈包括：
- 采集端： Filebeat、Fluentd、Logstash
- 缓冲层： Kafka、Redis
- 存储与检索： Elasticsearch、OpenSearch
- 可视化： Kibana、Grafana
这一阶段解决了日志集中化的问题，但租户隔离仍停留在粗粒度层面：通常通过 Elasticsearch 的 Index 或 Index Pattern 做逻辑区分，缺乏资源隔离和访问控制。
常见陷阱： 多个业务线共享同一个 Elasticsearch 集群时，一个租户的异常查询（如大范围通配符搜索）可能拖垮整个集群，影响所有租户的日志写入与检索。
4.3 第三阶段：多租户日志平台架构
多租户日志平台在分布式日志架构的基础上，增加了租户身份注入、资源隔离、配额管理、访问控制四大核心能力。每个租户拥有逻辑或物理上独立的日志管道，互不干扰。
下图展示了从单体到多租户的完整演进路线：
4.4 多租户日志平台架构详解
一个成熟的多租户日志平台，在分布式日志管道的基础上，增加了以下关键设计：
- 租户身份贯穿全链路： 从应用日志框架的 MDC（Mapped Diagnostic Context）注入租户 ID，到采集端、缓冲层、存储层，租户标识始终保留。
- 写入隔离： 每个租户拥有独立的 Kafka Topic 或 Partition，避免租户 A 的日志洪峰阻塞租户 B 的写入。
- 存储隔离： 每个租户使用独立的 Elasticsearch Index 或 Index Alias，配合 Shard 分配策略实现资源隔离。
- 查询隔离： 查询时强制附加租户 ID 过滤条件，防止跨租户数据泄露。
- 配额与限流： 对每个租户的日志写入速率、存储总量、查询并发进行配额控制。
架构原则： 多租户日志平台的设计核心是“身份不丢失、资源不争抢、数据不泄露”。所有组件必须感知租户上下文。
4.5 三种架构对比总结
| 对比维度 | 单体日志 | 分布式日志 | 多租户日志平台 |
|---|---|---|---|
| 适用规模 | 单机 / 小团队 | 微服务 / 中大型团队 | 多业务线 / SaaS 平台 |
| 租户隔离 | 无 | 逻辑隔离（Index） | 物理 + 逻辑隔离 |
| 资源管控 | 无 | 无或弱 | 配额 + 限流 + 熔断 |
| 访问控制 | 文件权限 | Index 级别 | 字段级 + 行级 |
| 运维复杂度 | 低 | 中 | 高（需平台化支撑） |
| 典型技术 | Logback + 本地文件 | ELK / EFK | 自定义采集 + Kafka + ES 多 Index + RBAC |
4.6 演进启示：从工具到平台
日志架构的演进本质上是从“工具思维”向“平台思维”的转变。单体日志是工具，解决“能看日志”的问题；分布式日志是系统，解决“能查日志”的问题；多租户日志平台是服务，解决“安全、可控、可计量地使用日志”的问题。
设计建议： 如果你的团队正在从分布式日志向多租户平台演进，优先解决租户身份注入和写入隔离两个基础问题，再逐步完善配额与访问控制。